Sendmail replacements?

[Heather Stern]

> > Anyone have any suggestions?
> 
> Religious war #1092: The "better", "more secure" Mail Transport Agent.
> Not going there. :)
 
Too late :D

> In no particular order here are the four MTAs that leap to mind immediately.
> All of them could do your task.
 
I'll add some comments about some minor ones, and some impersonal
comments abotu the control file style of the ones which I have
configured.  It's so far been my experience that the control-file stuff
is what makes people think of one or the other as hard, easy, or only
suitable for mad scientists willing to cackle *ah haha ha* "It's Alive!"
when it accepts mail.

Rather like the "pine vs. elm" or "vi vs. emacs" arguments of old.

> 1) sendmail - the original. My personal preference. Yes, it's byzantine
> and maybe overly complicated, but I know it well, and "in general" it
> tends to "do the right thing." Since 8.9.3, there's been a huge focus on 
> security issues. My personal opinion is that the "buggy, security hole 
> ridden" claims are mostly religious screeds at this point. YMMV.

Regardless of claims to the contrary it is possible to configure it for
optimized queu handling; the fact that any given style of setup isn't
the default state is more a problem about whether the sysadmin wishes
to spend some time on it.

The config file format from the mailer's point of view is in the
sendmail.cf file - whose top third is composed of useful comments attached 
to one-liner options, and whose bottom two/thirds is line noise of the 
finest caliber.  However, most sysadmins use the sendmail.mc file to 
configure it, which takes weird little options without comments and
feeds them through m4 to autogenerate sendmail.cf, line noise and all.
Since some features ... errr, FEATURE()s require blobs of line noise,
it's considered easiest.  It's common for the options to take a "get
your data from a file" setting, so /etc/mail usually contains these
postmaster-readable data files.

The sendmail.org, sendmail.com, and sendmail.net addresses lead to
entirely different sets of *very* helpful information.  

There are a handful of ways to help protect systems from the fact that
sendmail is a monolithic program run by root.  Its primary needs for
root are (1) port 25, and (2) ability to become the right user for local
delivery purposes.

> 2) qmail - Requires a bit of mail spool and mailbox configuration. (i.e.,
> not a direct sendmail drop in replacement.) Widely used and enjoyed.
 
qmail, like postfix, splits its functions into parts which run at
different privileges, protecting them from a number of "hey one sploit
and the box is m1n3" troubles.

The config files come as a puddle of small parts, each designed to
control the aspect they are about.  And it's very often helped by
dotfiles in the users' directories;  the ezmlm mailing list depends 
on those heavily.  I don't like having these control bits scattered
so; YMMV.

qmail's mailbox format, called Maildirs, is also used by courier-imap;
however users of that mail layout aren't limited to qmail, because minor 
tweaks to local delivery agents allow anybody to deliver in that style.
It has been claimed that this style is less fragile about damaging mail
when there are storage and transmit problems.

> 3) postfix - Many of my friends use this MTA. They all seem to 
> like it. Conveniently, a drop in sendmail replacement.  Seems easier 
> to configure than sendmail, but that's a perception rather than an 
> empirical observation.

Under debian, its default queueing configuration seems much faster.
The comments in the config files were adequate and the side
documentation covered the rest verbosely.  It seems to me that setting 
up virtual mail-sites is much easier here, but I'm the sort who prefers
to avoid helper-UIs for these things - there are scads of such helper
UIs for configuring sendmail virtualhosts and at least one for
configuring qmail virtualhosts. 

This is the MTA which I use at my own site, and it serves me quite well.

> 4) exim - Don't know much about it. I've encountered it mostly in
> Debian based Linux boxen.  

Written by people who had a fondness for smail but knew that it had to 
die.  I've not found it particularly easy to grok, myself, so I cannot
comment further upon it, except to say how easy Debian makes it to pick
any of its smtp-servers as your mailerdaemon. 

> Find more opinion, source and HOW TOs by using your favorite
> Internet search method.

In the case of apps whose name you know, I'd start at
http://freshmeat.net, type their name into the engine, and pull up their
small description, then link through to their home pages.  Once
satisfied I'd come back to freshmeat and check other things in the SMTP 
server category (browsing the site index system).

I have had personal experience with one other MTA, the one that comes
with the Courier suite of features.  As of a few months ago it was
desperately underpowered and not particularly easy (though not
impossible) to configure.  I did not consider it ready for prime time,
and since the site was heavily dependent on its mail, we went for a
more prominent maildaemon, with local-delivery to maildirs set up.

I messed around a little with Masqmail, the MTA which goes with
masqdialer and is supposed to be optimized for sites which are often
disconnected or may move - in other words, allegedly ideal for laptops.
If you can figure out how to tweak it's notion of when you're connected
or not, it looks pretty slick.  Otherwise, postfix and sendmail at least
have means to deal with being disconnected.  Just about any MTA should
be able to handle "queue only" and have some command for "flush the
queue" - since flushing the queue is an important command for moving the
site to a new box.

I know someone who, deciding their antispam policy was not met by the current
local-deliveries, replaced the local delivery agents found with his MTA 
(qmail) and the ever popular external replacement (procmail) with his own,
"grandma".  grandma delivers to maildirs and is optimized for a whitelist/
blacklist view of the world.

A gentle reminder that these all work best if your DNS is in good
working order so your MX records are valid, is in order.  There's a
great resource "Ask Mr.DNS" about the best gory details in DNS setup.

And of course, a shameless plug;  I'm a consultant, so if you need
someone to come in from offsite and work on one of these, feel free
to contact me privately.

  . | .   Heather Stern                  |         star at starshine.org
--->*<--- Starshine Technical Services - * - consulting at starshine.org
  ' | `   Sysadmin Support and Training  |        (800) 938-4078