My mail server overhaul -- exim

[invalid at pizzashack.org (Derek Martin)]

On Tue, May 17, 2005 at 11:31:04PM -0400, Rich Braun wrote:
> Out with sendmail, in with exim.  I'm posting to BLU because I am absolutely
> THRILLED with the results of my efforts.  The last discussion about MTA
> programs (email servers) in the BLU archives appears to date back to November
> 2003.  The topic's worth revisiting now, with the improved freeware available.

Exim's a fine MTA/MDA.  It does most of the things that sendmail does
(even if it does IIRC break a few RFC's along the way... ;-), and few
things that it can't.  The main advantage is that it's generally a lot
easier to configure.

> If you start to look under the hood at the SMTP protocol, though,
> and read up on spam control techniques--WOW.  This is hot stuff.  I
> still have spamassassin installed on my machine--it was formerly
> knocking out about 98.5% of the 10,000 messages (just under
> 100Mbytes) I get per month.  But with a bit of tuning, you can get
> exim to block nearly 95% of email even before it gets to
> spamassassin.  

There are methods to do this with any MTA/MDA.  You don't say what
mechanism by which you can do this, but odds are sendmail can do it
too.

> But that's not all.  When you tinker with the SMTP protocol at this
> level, you get the satisfaction of gumming up the works of spammers'
> outbound servers.  Throw a few timeouts in there at each step of the
> protocol, and picture hundreds of your friends doing the same
> thing--you get the feeling you could actually make a dent in their
> ability to reach millions of mailboxes daily.

Of course, if you're wrong, then you're potentially negatively
impacting the service of the sender (process tables are limited, file
descriptor tables are limited, etc.).  That there are entities who
don't play nice on the Internet is not a reason not to play nice
yourself...

> This posting is turning out longer than I wanted so I'll just list a few of
> the techniques I threw into my configuration, to whet your appetite for a
> similar overhaul:
> 
> - Insert 20-second delays at the HELO, MAIL FROM, RCPT TO stages of any
> message that comes from a misconfigured or non-RFC-compliant server.  Spammers
> almost by definition have to use non-compliant servers in order to spew at a
> high rate.

There are a number of legitimate mailers that are also not
RFC-compliant.  These delays probably don't impact spammers too
significantly (since connections can be independent, and it's quite
possible to spawn individual processes or threads per connection
attempt), but might affect normal queue runners significantly if they
do serial connections.

> - Consult a couple of the more-conservative RBL block-lists to reject most
> spam even before accepting message DATA, which saves lots of overhead vs. the
> Spamassassin technique.

The conservative RBLs suck.  They block mail based on often arbitrary
critera, often affecting legitimate senders, without accountability and
with complete impunity.

And sendmail can do that too, BTW.

> - Reject binary MIME attachments, especially zip/pif/exe.

If sendmail can't do this natively, it can in concert with procmail.
Since most modern installations of sendmail use procmail as the MDA,
it's sort of hard to make a distinction...

> - Grey-list new correspondents for 1 hour (this blocks incoming spewage for
> that long no matter how hard they try).

I don't know what this means, but I do know that any kind of list can
block legitimate senders.  I also know that anyone who wants to
authenticate my e-mail address before receiving mail from me never
gets mail from me again...

> - Disable external access to certain system aliases that I use in monitoring
> scripts (these had leaked out to spammers' databases in the past because
> sendmail is so vulnerable to so-called 'dictionary' attacks).

I think you'll find it isn't if you configure it properly...

> All of this works automatically, without any user-level
> white-listing.  When I started this, I figured exim might block
> maybe 60% of the spam flow.  Reaching a rate above 95% was quite the
> pleasant surprise!

You've already said you don't mind occasionally losing legitimate mail
to save yourself from spam; people who think likewise will probably
find those features of exim quite handy.  Personally I find losing a
single legitimate mail (for some definition of legitimate that I get
to define for my purposes here) is unacceptable.

I'm not trying to put exim down, by any means.  But many people bash
sendmail unfairly.  It /is/ harder to configure than some of the newer
mta's, but that's mainly because it is designed to be a lot more
flexible and handle a lot more of the bizarre cases.  With added power
invariably comes added complexity...

If you're managing mail for a small site with a very simple
environment, then exim may well be a better choice for you.  As the
copmlexity of your site increases, the line begins to blur...  But
don't knock sendmail, cuz it's still the mac-daddy of e-mail.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20050518/47325eed/attachment.sig>