Best mail transfer agent ?
Lusercop
`the.lusercop' at lusercop.net
Fri Jun 30 12:28:31 BST 2006
On Thu, Jun 29, 2006 at 06:49:21PM +0100, Dirk Koopman wrote:
> On Thu, 2006-06-29 at 11:40 +0200, Thomas Busch wrote:
> Exim 4. Period.
> Use it everywhere. Postfix is fine if you want a drop in sendmail
> replacement (which is why you find it more and more as the default
> mailer in linux distros). It is not IMO (note no H) as scalable for
> virtual hosting as exim (and I have tried all of them in all sorts of
> sizes of job).
>
> I won't bother to mention qmail other than to say that claims about its
> speed and impact, particularly on networks when being loaded, do not
> stack up under benchmarks that I have done. Its configuration is IMO the
> most sysop hostile. It is not as flexible as the other two. And then
> there is DJB...
I'm assuming you want to run this on UNIX, so I won't add my comments about
exchange.
This roughly seconds everything I have to say.
Sendmail:
+ very very flexible mail routing policy
- configuration interface got so complicated that they now have to supply a
secondary configuration interface to generate the first.
- inflexible in certain areas - certain things are dealt with as special
cases, which really shouldn't be.
- history of security holes
+ split into msa, mta and mda for better security separation
- multiple mail queues, so mailq(8) doesn't do quite what you think it ought
to
- your best support comes from sendmail.com, the pay-for version
Postfix:
+ good security separation
+ low incidence of security bugs
- config file is a mess of special cases. you have to work out which of
the special cases your installation falls into, which requires something
of an understanding of Wietse's mind.
- multiple mail queues
Exim:
- monolithic (although drops privilege early on for most operations, and
regains by re-execing itself)
+ very flexible (but not in such a way that you have to run a config generator,
yet)
- doesn't insulate you well from the mechanics and limitations of SMTP, which
means you do have to understand these in order to get the most out of it
- a few security bugs (though none that have allowed a remote root, to my
knowledge)
+ very active development, and (mostly) supportive development team and
mailing lists
+ the few times I've needed to write my own code because I couldn't quite
do what I wanted within exim itself, it's been fairly easy to understand
how to write it to fit in
qmail:
- Serious lack of commenting in the source code and lots of magic
- reimplementation of the libc
- DJB
+ very good boundary separation
- completely arcane config files
+ lack of parsing in the config files (lots of different special-case files
with one-per-line elements)
- /var/qmail
- far too many little users that the interactions do become complex
- need source-patches to get it to any state approaching a modern MTA (things
like reject unknown at SMTP time are not included in the main distribution).
- build scripts are in C!
Overall, my choice is with exim. I've been using it for far too long, and I
can do some reasonably complex, but very powerful things with it, especially
involving delegation of responsibility in a fairly safe way. I spent time
tailoring my configuration so the actual day-to-day running is easy.
What you'll see is that MTAs all suck, though. Some of the essays on
http://fanf.livejournal.com/ are worth a read, too, if you can find them.
--
Lusercop.net - LARTing Lusers everywhere since 2002
More information about the london.pm
mailing list