Mikkel L. Ellertson wrote:
Regardless of what kind of configuration is shipped, it is not going
to work for most people running a mail server without changes.
Why do you think that a mail server that works in one place could not
work with the same configuration in many places? Now that almost all
client programs speak authenticated smtps, a canned server that
authenticates with your system PAM setup would be as portable as sshd.
To start with, it does nothing to address how outgoing mail is
handled, and that is the biggest change in configurations form one
location to another.
Outgoing mail is already configured to follow internet standards.
It also fails on networks with separate servers
for incoming and outgoing mail servers.
Where you run it has nothing to do with the configuration, unless you
want one sendmail to always forward through another. In that case it's
a one-line change that could easily fit a redhat-program-config style
fill-in-the-form.
What I'm saying
is that someone else could have done it better - like they have done for
sshd, httpd, etc. and it would be easier to discuss and solve problems
if everyone started from the same working setup.
They have not done it for ssh, or most other daemons.
Did you really have to edit your own sshd config file to make it accept
network connections?
But don't say that Sendmail is being discriminated agenst
because it is harder to configure then ssh - each daemon has its own
configuration requirements. The more options, the more complicated
the configuration requirements. Sendmail has more options then most
daemons, and one of the most difficult configuration files I have
ever seen. Try making sense of the header re-writing rules some time.
I've never said it is harder to configure than ssh. I've said that ssh
comes configured to work as designed in the fedora package so you don't
have to edit the complicated config file yourself. If you want sendmail
to follow internet standards for receiving mail you must change the
supplied configuration.
I am not an expert in Sendmail configuration ether. There are not
too many of them out there. I can picture a half dozen base
configurations that would have to then be tweaked for local settings.
But they could all have an almost-identical sendmail.mc/cf. The other
local configuration files are straightforward.
Filtering incoming mail server - it runs on the firewall machine. It
rejects mail that matches filtering rules, and passes mail for the
local system to the local mail server.
For this one you'd probably want to do the filtering in a milter like
MimeDefang, so add one line to sendmail.mc to hook it in. If you want
to pretend that all bad guys are outside your firewall and all good guys
inside, you might forward in to a different server for delivery, but
that would be in a mailertable entry, or with virtual or normal aliases
and wouldn't require anything special in sendmail.mc/cf.
Local POP/SMTP server. It accepts incoming mail, and puts it in
local mail boxes. It process mail from the local network, and takes
care of delivering mail to other domains directly.
Local POP server. It accepts mail for the local network, putting it
in mail boxes. It does not process any outgoing mail. Basically a
relay host for the local network.
Local SMTP server. It only handles outgoing mail. It passes mail
from the local network that is for the local network to the POP
server. It delivers mail to other domains directly.
These are all the same from sendmail's perspective. Your middle example
probably really does need outbound support because it will need to
process error bounces and user-requested forwarding.
POP/SMTP server that uses a relay host for outgoing mail. This one
may get complicated depending on how you have to authenticate with
the relay host.
Local SMTP server using a relay host. This one is kind of rare,
because if you have enough traffic to justify a separate outgoing
mail server, you usually do not use a relay host.
It's a one line change to add a relay.
Local POP/SMTP server on a dialup connection. This requires longer
spooling of outgoing messages, and warning times. Incoming mail may
require the server to accept incoming network connections, or a
program like fetchmail may grab Internet mail.
Connectivity doesn't matter to sendmail, nor does it care whether you
ran fetchmail or the sending host delivered directly.
This does not cover using other transports,
If you aren't following internet standards, you should expect to roll
your own... The distribution can stick to standards.
or things like secondary
mail servers. It also doesn't cover things like scanning incoming or
outgoing mail or mail attachments, limiting message size or any of
the other tweaks that are common.
Covered above with a milter.
Then their are things like virtual
mail hosts that require different configurations.
There's no harm in including virtusertable support in all
configurations. Use it or not, no need to make a special case in
sendmail.mc or .cf.
You can also
handle some of the configuration differences by creative use of the
local mail dns server.
DNS follows internet standards and fedora ships a working named. No
problem there.
I am sure their are other common configurations that should be
covered, but these are the ones I have used in the past.
So, potentially you might need 2 extra lines in sendmail.mc for all of
your special cases (optional milter and relay). Maybe a couple more if
the relay wants authentication and ssl. Why would it be harder to
provide a way to create those than something like the authconfig gui?
Sure, I understand how things could be improved. But that does NOT
make the default installation broken, as you keep saying.
Does it follow any internet standard?
--
Les Mikesell
lesmikesell@xxxxxxxxx
