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.
9 Comments
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).
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.)
Can’t you use Postfix’ internal VERP module to encode all addresses? I do something similar with qpsmtpd.
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.
here is a nice article about how to protect yourself from backscatter spam.
i think it’s a good read…have a look: http://www.allspammedup.com/2009/04/protecting-yourself-and-others-from-backscatter-spam-with-exchange-server-2007/
Hi, the fact that you use REJECT in your header check doesn’t it make the whole mechanism useless? Because you bounce back to the supposed sender (who is forged) with the message “no third-party” and you end up with your mail queue getting full with “Connection timed out”. And even if the supposed sender is real, you end up bouncing back to him, and in this case, spamming him.
Shouldn’t you use DISCARD?
(please mail me back when you give an answers. 10x.)
This check gets applied to MIME annexed messages also. Doesn’t this prevents users/postmasters from using this postfix to forward email messages that contains such kind of messages as annexes ? (For example, if I try to forward a failed delivery report to anyone using alpine I get the SMTP error 550 5.7.1 no third-party DSNs).
Does disabling nested_header_checks (setting it to empty) solves the problem without compromising the original solution’s purpose ?
(Just asking if anyone with experience can give any feedback on this issue).
Hi, thanks for the helpful site. Just thought you’d like to know that although I didn’t find a solution that helped me here, I did eventually find one here: http://www.linuxquestions.org/questions/linux-server-73/disable-ndr-on-postfix-revisited-771231/