Default-installed MTA (was Re: MTA virtual provides craziness)

[Chris Adams]

Once upon a time, Dan Mashal <dan.mashal at gmail.com> said:
> Sanity: Switching to postfix?

That's a long-time sore point, but the general idea is that "sanity" is
not switching desktops/non-mail-servers from one full-featured MTA to
another.  The right move is to either remove a local MTA from the
default install (which I think has been worked on), or switch to a
light-weight daemon that is a local queue-and-forward mail handler.

The downside of that would be that configuration of an upstream mail
server (possibly requiring SSL and/or authentication) would be required
for it to work, while sendmail/postfix/etc. can actually deliver
messages (modulo other servers' spam filtering) in the default config.

The core problem is that there's a general long-time Unix assumption
that piping something to /usr/sbin/sendmail and/or connecting a TCP
socket to localhost:smtp can send email, and so many things don't
explicitly specify that need.  The idea is that /usr/sbin/sendmail
handles connecting to the "right" host, aliasing, etc.

Just to pick an example: mdadm (for Linux software RAID) has a monitor
mode to notify somebody of disk failures.  Failures would already go in
the system log (from the kernel); running mdadm --monitor is for sending
a more active notice.  It is possible for mdadm to run an external alert
program; on a desktop, that could use the system bus to notify the
logged-in user.  How do you handle a headless system, a desktop with
nobody logged in, etc.?  The only standard way to notifiy somebody off
the box is SMTP (I suppose mdadm could use SNMP traps, but that's even
more work to configure correctly).

You could have mdadm implement a full SMTP client (and hope the network
isn't down), but that's what /usr/sbin/sendmail is for.

I'm not saying that these are insurmountable issues, just that that's
where things stand today (to my knowledge).
-- 
Chris Adams <linux at cmadams.net>