We need a new subject- bug fixes

Les Mikesell lesmikesell at gmail.com
Tue Mar 6 03:48:58 UTC 2007


Mikkel L. Ellertson wrote:

>>> That is because they use more rational configuration method.
>> No they don't.  Have you built a kernel from scratch that included
>> everything that fedora includes?  Or apache with all the modules built?
>> It isn't fun - or very rational. However, you don't have to do that if
>> you install fedora.  The point of the packaged distribution  is that the
>> work is already done and maintained.
>>
> What does this have to do with configuring a service? You are really
>  having to struggle to come up with something to justify your
> position. That should tell you something.

The point is that those things come preconfigured for typical uses. If 
we haven't established yet that email isn't very useful unless some 
machines accept mail over the network, let's do that now to make it 
clear that is a needed configuration choice.

>>> Maybe
>>> if Sendmail did as well, it could be treated the more like other
>>> services.
>> Sendmail does give you the opportunity to use a pre-built configuration.
>> Fedora just doesn't provide one that gives the upstream functionality.
>>
> And this relates to how easy it is to change the sendmail
> configuration how?

Anything is easy when yum/rpm installs what you need.


>>> This is the key - services with standard specifications. Sendmail is
>>> non-standard when compared to other services.
>> There are standard specifications for mail behavior.  None of the other
>> programs follow any standards for config files.  How you make it do it
>> doesn't matter.
>>
> Oh, now you are saying that having to make a change in sendmail.mc,
> and then generate a new sendmail.cf file doesn't matter. 

Of course it doesn't matter as long is it is done automatically.  A vast 
number of more complicated things are done automatically as the kernel 
boots, for example.


> If that is
> so, then what iis your problem with the current configuration?

The needed sendmail.mc is not provided.


>>> So why should it be
>>> treated like other services. Or are you saying that there should be
>>> a configuration program that directly modifies sendmail.cf?
>> To put it in line with the way other fedora configurations work,
>> sendmail.mc should include lines from a directory under /etc/sysconfig
>> that would control a few common options and allow milters to add
>> themselves independently. There might be a system-config-sendmail
>> utility that controlled the settings of those optional lines.  Like
>> other services, users should not need to edit the configs directly
>> unless they have non-standard environments.
>>
> Hmm - there is a file in /etc/sysconfig that controls how Sendmail
> starts - this is the same as other daemons have. Or are you saying
> that Sendmail should get special treatment here, but not other places?

That's a good start, but look what they do for iptables as a comparison.

> To make something like this work, the startup script for Sendmail
> check the time stamps  on sendmail.cf and /etc/sysconfig/sendmail
> and rebuild sendmail.cf before starting sendmail. This would require
> everyone that runs Sendmail to install M4 and the Sendmail
> configuration package even if they have no need to change the
> default configuration.

Yes, that all already happens by virtue of a makefile in /etc/mail, and 
it's a good thing. Edit sendmail.mc, restart sendmail and you are all 
set.  Oh wait, I left out reading the 900 page bat book for something 
you shouldn't have had to do.

> Now, as far as non-standard environments, needing Sendmail to accept
> connections from the Internet is a non-standard environment.

Beg your pardon? Email as we know it can't work unless this happens.

> Most
> machines are not going to be an Internet mail server. So why should
> the default configuration support it? From a security standpoint, it
> is better to not accept connections from outside the machine unless
> they are needed. This is why services like Apache, POP3, etc are not
> turned on by default. Because a local mail server is needed for
> proper operation of the system, Sendmail runs by default, but it
> runs locked down. This works just fine for most users, and for the
> ones it doesn't, there is a lot more configuration then just
> enabling it to listen to other interfaces then 127.0.0.1.

For every sender there must be a listener.  Should RH/fedora be 
inadequate for this role?

>>> If you
>>> want a mail program that can be configured like other services, then
>>> you need a mail server that is configured like other services.
>> No you don't.  You need the distribution to handle it the way it does
>> the gazillion other programs it includes.
>>
> And how is that? Be specific. Explain, in detail, how you want
> Sendmail to be handled.

There are about 4 common differences people would likely want.  The 
existing send-only version with delivery to the MX recipient is one.
A likely option would be forwarding through a relay host, so an
optional line of
define(`SMART_HOST', `smtp.your.provider')dnl
would make sense with a configuration tool permitting you to supply the 
relay host the way you configure other network settings.

Another machine might _be_ the relay host.  It will need to accept mail 
over the network, and you'll probably want it to handle roaming users 
with smtp auth, so you'd want:
define(`confAUTH_OPTIONS', `A p')dnl
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN 
PLAIN')dnl

I don't think those will hurt anything in any case, so they might as 
well be part of the default - and of course the ssl certificate should 
be generated automatically as it is for ssh.

If you have roaming users you would probably make your external/relay 
server also the delivery server and use pop3s/imaps from the internet 
side to retrieve mail.  If you are a little more paranoid and still 
think all the bad guys are outside your firewall you might have the 
relay forward to an 'inside' server.  In that case your non-delivering 
relay needs:
define(`MAIL_HUB', `esmtp:your_delivery_host')
again with the ability to specify the name here.

And you probably want to run a milter like MimeDefang on the 
internet-exposed server, so:
INPUT_MAIL_FILTER(`mimedefang', 
S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, T=S:60s;R:60s;E:5m')

> Not vague statements that do not tell us
> anything except that you don't the way things are done. Then explain
> how Sendmail can be configured this way, considering the way you
> have to configure Sendmail. 

I'm not a sendmail expert which is why I think someone else should be 
doing this stuff, but there's what - 3 optional lines there to make it 
perform all of the usual mail handling roles?  Do we really need to read 
that 900 page book for this?  I guess if we get this far it would make 
sense to add the option to send _to_ a relay with smtp auth as well 
which would be needed for certain ISPs and might do away with the need 
to permit any network-based access to your own relay.  I don't have an 
example handy but that's another line or 2.

 > After all, you can not configure
 > Sendmail by just editing a config file the way you can most other
 > packages.

Yes you can, given the makefile that takes care of the rest.


>>> You keep harping that Sendmail should accept incoming mail by
>>> default,
>> I'm not sure I've ever said exactly that, but you keep saying I said it
>> for some reason.  I'm saying enabling or disabling its access to the
>> network should be handled the way the distribution handles other programs.
>>
> Explain this. Or are you saying that the only thing necessary to
> reconfigure Sendmail from a local machine only mail server to a
> network mail server is to enable it to listen to other interfaces?

Yes, after doing that it will accept addresses in the form of 
user at hostname and deliver to the user's local mailbox.  If you want it 
to accept other host/domain names you can add them to another config 
file that is just a list of names.  No need for the book there.

>> Email would not be useful if someone doesn't accept network connections.
>> So even if not everyone needs it, clearly some do.
>>
> So what? That is about as smart as Microsoft starting a web server
> on every server because some people might need it. That is very poor
> security.

The poor security didn't come from running "a" web server, it was from 
running a buggy web server. Do you think every web server has poor security?

> If you need it, you turn it on as part of the other
> configuration you need to do to turn a stand-alone mail server into
> a network mail server.

Listening on a port and being secure are two different concepts.  If you 
need to receive mail, you still need to be just as secure as if you 
don't. Listening on a port doesn't make your machine insecure.  Bugs in 
the software make it insecure and pushing the problem off on someone 
else doesn't help fix it.

>>> What you can't seam to grasp
>>> is that your setup will work for maybe 1% of the users.
>> OK, if those are the ones that are making email work for the rest of the
>> others, I'd consider them too important to ignore.
>>
> But they are not. So that argument falls flat too. The setup you
> talk about would work for a stand-alone mail server. A small network
> mail server requires more configuration. A large network requires a
> lot more. Are you trying to say that someone would use Fedora in a
> production environment and be able to use the stock configuration if
> it listened to other interfaces? I find that hard to believe.

If it's exposed to the internet you probably want a milter configured 
for virus and spam scanning.  MimeDefang lets you handle that part of 
the configuration in perl and comes with a good example setting.  Other 
than that, to whatever extent fedora is suitable for server use, a small 
fedora box can easily handle hundreds of users in either the hub or 
relay roles with a few changed lines in sendmail.mc.  Just add users...

-- 
   Les Mikesell
    lesmikesell at gmail.com




More information about the fedora-list mailing list