Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail

[Michael Orlitzky]

On 05/11/2015 04:08 PM, Robin H. Johnson wrote:
> By drop, I will clarify that they should ideally be rejected at SMTP
> time, not silently dropped.
>

I believe those logs show a rejection after the message has been
accepted initially (if I'm wrong, you can ignore the rest of this). This
is better in a way, but causes another problem.

Obviously it's better than a silent discard in that, in the case of a
false positive, the sender will be notified of the mistake. But, it
creates backscatter[1] which can get us blacklisted or be used as part
of a DDoS. It's also just plain rude to the innocent people we're
bombarding with rejections (for mail they never sent).

That happens because we,

  1. Accept the message (postfix)
  2. Queue the message (postfix)
  3. Client disconnects (postfix)
  4. Scan the message (amavis)
  5. Decide to reject the message (amavis)
  6. Alert the sender (postfix)

This saves resources because there's a queue waiting to get into amavis,
and scanning can take a while. As long as we scan at a decent *average*
speed, the queue will eventually empty.

But at step #4, the original client is long gone, so you can't just feed
him a 5xx error. There's another "pre-queue" mode for amavis which lets
us reject right away. If you configure e.g.

  smtpd_proxy_filter = localhost:10024   # amavis goes here

in Postfix's main.cf, then amavis will scan the message as its being
received. Then the D_REJECT will actually just say "5xx: get lost" to
the client while he's still sending the message. Real senders will get
an NDR from their mail server. And if a spammer uses a forged address,
it doesn't matter -- the spammer gets the rejection, not the poor guy
whose email he used. It looks something like,

  1. Client connects
  2. Postfix proxies the message through amavis
  3. Amavis scans the message and reports its verdict to postfix
  4. Postfix reports the good/bad news to the client
  5. Message is queued (or not)
  6. Client disconnects

The downside is that the "pre-queue" mode needs a lot more resources.
When there's no "going to amavis" queue, you need enough resources
(amavis processes, memory...) around to be able to scan all of your
incoming mail at once. Otherwise you'll run out of resources and clients
will start seeing 4xx errors (this isn't that bad if it only happens
under rare circumstances).

FWIW we do this for a few thousand accounts on a Proliant DL360 G5. I'm
happy to share any of the configuration.



[1] http://en.wikipedia.org/wiki/Backscatter_%28email%29