Spam Backscatter

Published: 2006-10-09
Last Updated: 2006-10-09 01:28:14 UTC
by Swa Frantzen (Version: 2)
0 comment(s)

Over the weekend I dealt with the rather massive after effects of a spam campaign spoofing a domainname in the From: address.

In a few minutes about 10,000 messages arrived on a "catch-all" email address. Those messages consisted of:

  • Non-Delivery Reports (NDR)
  • Delivery Status Notifications (DSN)
  • Out of Office messages
  • Automated responses indicating the target does not work anymore where (s)he was working
  • Questions to confirm the message is genuine
  • Automated reports informing it was considered spam
  • Automated reports informing it contained a virus
  • Automated reports informing it contained bad links
  • ...

These messages come in at an incredible rate. When they contain the original headers you can see they are spammed from all over the address space (so it's likely to be a botnet sending it out). The error messages are in at least half a dozen languages, some of which I don't speak at all.

The spams were spoofed to come from random names at a domain and all those responses from the victims only create more victims. Actually that victim is hit much harder than any of the other victims.

So in order to keep the Internet a place where we all can survive it is critical:

  • Your email servers know which messages can be accepted or not and refuse the message if it needs to bounce before letting the sender move on and eventually resulting in a NDR or DSN to be sent to another victim.
    • You do this by NOT having fallback MX records where these messages are dumped and then generate all the bounces. The fallback MX mechanism is only useful if you have a very unreliable link and actually use something like ETRN to fetch your email. But if you can surf the Internet reliably, the MTAs will work perfectly without a fallback MX. And should your server be down: the orginating MTA will store it till the next queue run. You won't loose any email due to not having a fallback MTA on today's Internet.
    • You do this by scanning for active mailboxes before accepting the email.
    • You do this by scanning for unwanted content before accepting the email.
  • Kill all vacation, out of office messages, does not work here anymore, .... automated replies: it's a risk as such of leaking information. And if you are on the receiving end of a few thousand of them while you didn't send those people anything, it's a real pain.
  • Stop trying to limit incoming spam by demanding an acknowledgement of the apparent sender: this is really the cheap egoistic solution. It is protecting yourself a bit while putting the burden on the rest of us, even those of us who don't even want to have anything to do with you in the first place.
  • Automated scanning; if you do need to send somebody something that a unwanted message got filtered: send it to the recipient. If (s)he wanted the message, it can be gotten out of quarantine, but don't bother others with it, you're sending it toward the wrong people. And those that did send it to you: they know they are sending you unwanted stuff. It's their business model.

How do you survive this onslaught? You stop accepting the catch-all email. You refuse all those incoming messages and/or -for those addresses you need to accept email- you start to drop all of those unwanted messages in a filter. Dropping MX records only works if you have no A record, but it might be an option. And no: you don't reply to any of them, there have been enough victims.

Next comes that you might not be able to send much email anymore as there will be enough people who are misguided in assuming you or your domain in fact did send that message (the header forgery was not that bad, so some might even believe you relayed the messages).

If you do think you absolutely need fallback MX records, need DSN, ... well I'm sure you might sing a slightly different tune when are the victim of 10K messages in the first few minutes, and still going strong after many hours.

Personally I feel it's long overdue to really start implementing a usable alternative to the current email system. One of the requirements would be sender authentication and inability to create just a new identity after you got blocklisted.

UPDATE: Vance stated: "A very valuable purpose for fallback records is to establish a point of attraction for SPAM and malicious message transmissions (a honeypot of sort)." While that is true if you're dealing with spam, it's not so true for the victims of the backscatter it creates in most real cases. That backscatter is many times worse than normal spam as the victim gets all (read many thousands) answers vs. the normal spam victims just getting a couple each. To solve it: make sure the fallback MX is refusing messages destined to nonexistant mailboxes, messages that it will consider spam etc. before accepting the email (and causing a bounce later)

--
Swa Frantzen -- Section 66
Keywords: spam
0 comment(s)

Comments


Diary Archives