Why does this always happen when you don’t have the time for it. Receiving backscatter bombs.

One of the big issues, I still have to deal with is what to do about the endless stream of backscatter bounce messages.

First of all… What is backscatter, you might ask.

What is backscatter?

Backscatter is the effect you get when you have a mail server, that starts to receive bounces of mails you didn’t send. Like the following example:

A spammer decides to send a spam to all kinds of addresses all over the world, with your e-mail address in the From. And those messages are bounced by the receiver.

Normally, what would happen is, the sender would get a nice MTA generated e-mail stating the mail could not be delivered. This is exactly the problem. Instead of the sender (the spammer), the mail gets send to you, due to the fact your domain was abused… This is hard to filter, as the MTA’s that are sending the messages to you, are actually following all the relevant RFC’s. So it’s hard to figure out what to accept and what to deny. But it gets even worse, when you have a fallback mailserver .

You can’t just refuse everything that doesn’t feel or sound like something you should accept. For example, in a new setup I’m working on, I required all mail that had a from which matched a local domain, to be authenticated, works nice in theory (although this doesn’t solve this issue), however… If you have someone that uses the SMTP server of his or hers provider and cc the messages to you, your local MTA will just refuse the mail. Which is bad…

To make it even more complicated, some people use a secundairy or fallback mailserver, you can just use greylisting, stuff like Sanesecurity addons for ClamAV, but you will still get more than enough crap mail to handle.

One thing that will help against backscatter in Exim, is a nice and ugly (RFC breaking) solution. You add something like this to your config:

BOUNCE_ID = <some kine of unique ID>
BOUNCE_SECRET = <some kind of md5 or sha1 key>

And later on, in your config, you add something like this to your ACL:

deny  senders = :
! condition = ${if match \
{$message_body $message_body_end} \
{[xX]-bounce-key:\\s*BOUNCE_ID;${rxquote:${lc:$recipients}};(\\d+);(\\w+)} \
{${if eq {$2} \
{${length_8:${md5:BOUNCE_ID;${lc:$recipients};$1;BOUNCE_SECRET}}} \
{${if <{${sg{${eval:$tod_epoch-$1}}{-}{}}}{864000}{1}}}}}}
message = Bounce does not contain a valid X-bounce-key signature so not accepting message

And to your remote smtp router, you add:

headers_add = ${if eq{$return_path}{}{}{X-bounce-key: BOUNCE_ID;${lc:$return_path};$tod_epoch;${length_8:${md5:BOUNCE_ID;${lc:$return_path};$tod_epoch;BOUNCE_SECRET}};}}

This will probably work really well, but it will also block certain stuff you do want to receive.

Like reading confirmations from Outlook.

To avoid that, you can add something to your ACL’s like:

accept
regex = [dD]isposition.*disposition-notification.*
accept
regex = [dD]isposition.*MDN-sent.*displayed.*

But this can also be used by spammers .

So far I have to admit, I disabled the ‘solution’ again, and just abuse SpamAssassin as much as possible, together with ClamAV / Sanesecurity and RBL checking.

If you don’t accept the message, it’s not your problem .

And still, you will receive loads and loads of spam, from the secundairy mailserver. Greylisting, SA on SMTP time, ClamAV on SMTP time is just not enough…

However, if you combine it with stuff like http://wiki.apache.org/spamassassin/WrongMXPlugin, it might be enough.

If anyone has better idea’s (that don’t involve shutting down the MTA entirely, I’m all ears!)