Backscatter defense

· by Steve · Read in about 6 min · (1231 Words)

Bah, it never rains, but it pours. I was poised last night for the Google Summer of Code 2008 accepted students announcement (we knew already for OGRE of course, since we picked them), since I had a bunch of things to do once that happened, such as welcoming the students to the project. Unfortunately, the announcement was quite late and I had a bunch of friends coming around so I wasn’t that great a host to begin with, as I’m there hitting F5 on the Summer of Code page waiting to fire everything off (in the end I just had to give up and wait until after they’d gone to finish up). Worse though was that spammers decided to pick that particular time to use my email as a return address in a fairly major spam offensive, giving me something else to curse about when I had no time to deal with it properly. I’m no stranger to spam, having a number of very publicly visible email addresses, and my several layers of defenses normally deal with it, however in this case the sheer volume of specifically targetted backscatter was a problem. *sigh*

Backscatter is where a spammer uses your email address as a return address for all the spam they’re sending, so that when it can’t be delivered, you get the Non-Delivery Report (NDR). The problem with backscatter is that it often doesn’t register highly on content based spam detectors because the initial chunk of the mail is a perfectly valid set of content (the report from the server). I’ve had backscatter before, but it’s usually directed at random addresses in domains that I control and therefore easy to deal with - it’s rare to get backscatters directed at one of my valid addresses, and not in any great number. However this time I had literally thousands of backscatters specifically targetted at one of my valid email addresses in the space of a few hours. Many got chewed up by my filters anyway, but many didn’t, enough to really piss me off.

If you have a more recent version of SpamAssassin than I have, there’s a handy rule already defined to handle backscatter - another reason for me to upgrade my mailserver to Etch soon. Sometimes the problem with Linux servers is that they’re so damn stable & unobtrusive you tend to forget about them - beyond security patches, I haven’t messed with this server in any significant way for at least 3 years. 😕 Hence I tend to put off the upgrade as a ‘sometime when I’ve got nothing better to do’ - which usually means never! I have a list of things that aren’t essential but would be quite nice now though, so I guess I’ll have to get around to it.

Anyway, I certainly didn’t have time to start upgrading anything last night, I was already on borrowed time, so after some head scratching and experimentation I added this to my .forward rules:

`Bah, it never rains, but it pours. I was poised last night for the Google Summer of Code 2008 accepted students announcement (we knew already for OGRE of course, since we picked them), since I had a bunch of things to do once that happened, such as welcoming the students to the project. Unfortunately, the announcement was quite late and I had a bunch of friends coming around so I wasn’t that great a host to begin with, as I’m there hitting F5 on the Summer of Code page waiting to fire everything off (in the end I just had to give up and wait until after they’d gone to finish up). Worse though was that spammers decided to pick that particular time to use my email as a return address in a fairly major spam offensive, giving me something else to curse about when I had no time to deal with it properly. I’m no stranger to spam, having a number of very publicly visible email addresses, and my several layers of defenses normally deal with it, however in this case the sheer volume of specifically targetted backscatter was a problem. *sigh*

Backscatter is where a spammer uses your email address as a return address for all the spam they’re sending, so that when it can’t be delivered, you get the Non-Delivery Report (NDR). The problem with backscatter is that it often doesn’t register highly on content based spam detectors because the initial chunk of the mail is a perfectly valid set of content (the report from the server). I’ve had backscatter before, but it’s usually directed at random addresses in domains that I control and therefore easy to deal with - it’s rare to get backscatters directed at one of my valid addresses, and not in any great number. However this time I had literally thousands of backscatters specifically targetted at one of my valid email addresses in the space of a few hours. Many got chewed up by my filters anyway, but many didn’t, enough to really piss me off.

If you have a more recent version of SpamAssassin than I have, there’s a handy rule already defined to handle backscatter - another reason for me to upgrade my mailserver to Etch soon. Sometimes the problem with Linux servers is that they’re so damn stable & unobtrusive you tend to forget about them - beyond security patches, I haven’t messed with this server in any significant way for at least 3 years. 😕 Hence I tend to put off the upgrade as a ‘sometime when I’ve got nothing better to do’ - which usually means never! I have a list of things that aren’t essential but would be quite nice now though, so I guess I’ll have to get around to it.

Anyway, I certainly didn’t have time to start upgrading anything last night, I was already on borrowed time, so after some head scratching and experimentation I added this to my .forward rules:

`

That seems to have done the trick, and has the advantage of allowing through NDRs for emails that I actually sent, which just dropping all NDRs would lose. Basically, any NDR that was generated from a message that I actually sent should have been relayed via either my ISP’s mail server, or Google’s (if I happen to send a mail from GMail - since I use both my own mailservers and GMail). The ‘from’ part is important, because obviously any mail I pull down from my mailservers will mention their fully qualified names in the route trace, therefore just looking for the name on its own wouldn’t help. But the key is that if the mail has just ended up there and was pullled down via POP (rather than being relayed by SMTP), it will only have an entry saying ‘by mailserver.myispsservers.com’, not ‘from mailserver.myispsservers.com’. Thus this rule rejects NDRs that were not a result of mails that went out through my known mailservers in the first place. I’ve used a wildcard match just in case my provider or Google change their email server names.

Maybe that will help someone else who ends up in the same unfortunate position. I refuse to give in to the spammers and hide my email address from the public - like it or not I need to be easily contacted via the web, and I refuse to let them win.