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
