Dealing with backscatter, revisited
Back in January, I wrote about how I deal with email backscatter nowadays. Since then, I’ve made a notable tweak.
This is that I no longer reject “null-sender” traffic during the SMTP transaction. It turned out that it broke Exim’s implementation of Sender Address Verification, which performs the SAV check using a MAIL FROM of <>, rendering it indistinguishable from a bounce during the SMTP transaction.
Now, I’ve complained about SAV, but I have to be pragmatic anyway (Postel’s law and all that!) — so it was better to just allow other sites to perform SAV lookups against our server, and fix the anti-bounce stuff some other way.
The new method (below) does this, by allowing null-sender SMTP traffic just fine; it detects bounces in Postfix if they arrive via SMTP in RFC-3464 format, and bounces that slip past are then dealt with in a more CPU-intensive manner using the SpamAssassin “VBounce” ruleset (which is part of the now-released SpamAssassin 3.2.0, btw).
This increases the load, since some bounces cannot be rejected at MAIL FROM time now, and instead we have to wait ’til DATA — but CPU hasn’t been a problem recently, so this is ok.
Here are the updated instructions:
In Postfix
In my Postfix configuration, on the machine that acts as MX for my domains – edit ‘/etc/postfix/header_checks’, and add these lines:
/^Content-Type: multipart\/report; report-type=delivery-status\;/ REJECT no third-party DSNs /^Content-Type: message\/delivery-status; / REJECT no third-party DSNs
Edit ‘/etc/postfix/main.cf’, and ensure it contains:
header_checks = regexp:/etc/postfix/header_checks
Then run:
sudo /etc/init.d/postfix restart
This catches most of the bounces — RFC-3464-format Delivery-Status-Notification messages from other mail servers.
In SpamAssassin
As before, install the Virus-bounce ruleset and set it up. This will catch challenge-response mails, “out of office” noise, “virus scanner detected blah” crap, and bounce mails generated by really broken groupware MTAs — the stuff that gets past the Postfix front-line.
Tags: anti-spam, backscatter, bounces, email, howto, smtp, spamassassin, virus-bounces, viruses
Colm MacCarthaigh said,
May 30, 2007 @ 8:26 pm
If you want to totally avoid the processing, you can put hashed cookies in the envelope from (rewrite it like VERP) , if you get a bounce to an address which doesn’t contain a valid cookie, reject it at SMTP time. Of course you have spend a little CPU computing the hash and doing rewrites (in both directions), but it works, and is not RFC ignorant ;-P
I still use exim call-backs, but I use Tony’s recipe for avoiding callbacks to people in rfc-ignorant.org’s DSN blacklist (which in effect becomes a whitelist). It still cuts out quite a bit of dictionary spam for me (100s a week).
Justin said,
May 30, 2007 @ 10:42 pm
yeah — maybe someday Postfix will make it easy to use BATV or similar in my envelope sender addresses, and I can ditch half of this. (The other half will still be necessary to combat the more brain-dead bounce generators, the ones that mail the From: header address anyway.)
Jonas said,
August 28, 2007 @ 2:49 pm
Can’t you use Postfix’ internal VERP module to encode all addresses? I do something similar with qpsmtpd.
Justin said,
September 23, 2007 @ 1:32 pm
sorry for not replying, Jonas.
yes, I probably could — but I run my domains on a shared server, and modifying all users’ outbound MAIL FROMs would be a big change — I don’t think everyone on the server would be happy with that.
There are still sites that can’t deal with BATV-style changing MAIL FROM addresses — apache.org, for one.