My mail server overhaul -- exim

[Rich Braun]

Seems that I opened some old wounds of religious arguments on whose MTA is
better than whose...that was not my intention, my apologies to those whose
favorite mail server software was slighted.  Rather, my intention was to
prompt those who know more than I about this topic to post critiques and
suggestions on whether/how to implement various spam-control techniques.

Derek suggested:
> Of course, if you're wrong, then you're potentially negatively
> impacting the service of the sender ...These delays probably don't
> impact spammers too significantly

The techniques that I used take advantage of the inherent desire for anonymity
that spammers have.  Misconfigured mailers deserve to be delayed a bit. 
Properly configured mailers won't see any delay at all until the last step of
my checks, the greylist.  And if a mere several hundred recipients did the
same thing that I (and those who have read exim spam-control articles online)
have, the impact on spammers adds up quickly.

He then suggested:
> The conservative RBLs suck.

Perhaps we're using the word "conservative" in opposite sense.  What I did was
look through my hundreds of thousands of archived spam messages, along with my
legitimate messages, to see how spamassassin had tagged them over the past
couple of years.  The "conservative" RBLs were those which didn't register any
false-positives that I could find.  Spamhaus.org, for example, with the
return-value of 127.0.0.2.

Question on this topic:  what configuration options (for the benefit of those
who run sendmail and postfix) are needed to do an RBL check prior to the
message DATA directive?  In exim, you put these directives into the rcpt-to
ACL:

  drop        (<- or deny)
    message     = Your email server $sender_host_address is listed \
                  at $dnslist_domain: POLICY_MSG
    log_message = [RR18] listed at $dnslist_domain
    dnslists    = sbl-xbl.spamhaus.org=127.0.0.2 : \
                  ...
    delay       = 40s

I defined my POLICY_MSG macro to give instructions to anyone who might have
gotten a false-positive, and a URL reference for more info on reaching me.

The nice thing about this is that a rejection causes less collateral spam
(misdirected bounce messages) than a bounce.  If your filtering technique
waits until after the message data is accepted, you have to either
circular-file the spam or send a bounce message.  If you circular-file it, you
might miss valid messages amid the sea of junk (and that's what I've endured
for years).  If you bounce it, you're probably going to wind up on an RBL list
yourself quickly, among other problems.  This technique provides feedback to
the correspondent without those issues.

> You've already said you don't mind occasionally losing legitimate
> mail to save yourself from spam

Sometimes your commentary here is unnecessarily combative.  That is not what I
said.  I said:  "I just had to assume that an occasional important message
would get dev-nulled".  This is not something I, or anyone else installing
spam-control software, wanted to have happen.  Rather than argue about this,
let's devote our mutual efforts toward educating the lurkers on the BLU list
about what the most useful features of <name your favorite MTA> are.  For
example, instead of declaring (accurately, I'll concede) that my old sendmail
configuration was inadequate--post a specific suggestion on a helpful addition
to that configuration for anyone else who might be wondering how to restrict
outsiders from accessing a mailbox like "backup-reports at site.name", or from
sending to more than 3 invalid-recipients per hour?

Tom Metro gave some good clarifying comments about greylisting, which is not
one of those annoying challenge/response agents which requires the
correspondent to confirm an email to get on a whitelist.  (I agree with Derek
on those, people who require me to respond to one of those are less likely to
hear from me by email again!)

He says this:
> The real problem with grey-listing is that it teaches spammers that
> sending more spam (iterating over their mailing list multiple times)

Without a doubt, spammers will eventually regain the upper hand over any
software configuration that I install on my system.  What exim, and the
techniques that I have now learned, does is give me the upper hand in a much
bigger way than spamassassin did when I first installed it 2 years ago.  I
have greater confidence that my next overhaul will be more than 2 years from
now.

The specific response that a spammer must take to get around grey-listing is
more complex and nuanced than simply repeat-sending to a big mailing list. 
For example, I also do a Razor2 check prior to my grey-list check.  If their
first attempt to send a message reached me early (before Razor2 recorded their
message contents), then repeating it an hour later will likely trigger the
Razor2 check because many others will have gotten the message by then.  But
yeah, some spammer will figure out some way to stay out of the Razor2
system--I'll have to adapt to whatever solution they find.  My hope is that my
email address will get pruned out of many of the spammers' lists because they
know my machine causes transmission delays.

It's sort of like putting a cheap lock on your cheap bicycle.  If the bike
isn't all that worthwhile, it won't get stolen if the other bikes parked next
to it are nicer or are left unlocked.  Most people's email boxes are
essentially still unlocked.

If we want to do a BLU meeting on message-transfer agents:  I'll contribute to
the forum.

-rich