taint.org: Justin Mason’s Weblog

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, vbounce, virus-bounces, viruses

As I’ve noted before, we still have a major problem with sites generating bounce/backscatter storms in response to forged mail — whether deliberately targeted, as a “Joe-Job”, or as a side-effect of attempts to evade over-simplistic sender address verification as seen in spam, viruses, and so on.

Sites sending these bounces have a broken mail configuration, but there are thousands remaining out there — it’s very hard to fix an old mail setup to avoid this issue. As a result, even if your mail server is set up correctly and can handle the incoming spam load just fine, a single spam run sent to other people can amplify the volume of response bounces in a Smurf-attack-style volume multiplication, acting as a denial of service. I’ve regularly had serious load problems and backlogs on my MX, due solely to these bounces.

However, I think I’ve now solved it, with only a little loss of functionality. Here’s how I did it, using Postfix and SpamAssassin.

(UPDATE: if you use the algorithm described below, you’ll block mail from people using Sender Address Verification! Use this updated version instead.)

Firstly, note that if you adopt this, you will lose functionality. Third party sites will not be able to generate bounces which are sent back to senders via your MX — except during the SMTP transaction.

However, if a message delivery attempt is run from your MX, and it is bounced by the host during that SMTP transaction, this bounce message will still be preserved. This is good, since this is basically the only bounce scenario that can be recommended, or expected to work, in modern SMTP.

Also, a small subset of third-party bounce messages will still get past, and be delivered — the ones that are not in the RFC-3464 bounce format generated by modern MTAs, but that include your outbound relays in the quoted header. The idea here is that “good bounces”, such as messages from mailing lists warning that your mails were moderated, will still be safe.

OK, the details:

In Postfix

Ideally, we could do this entirely outside Postfix — but in my experience, the volume (amplified by the Smurf attack effects) is such that these need to be rejected as soon as possible, during the SMTP transaction.

Update: I’ve now changed this technique: see this blog post for the current details, and skip this section entirely!

(If you’re curious, though, here’s what I used to recommend:)

In my Postfix configuration, on the machine that acts as MX for my domains – edit ‘/etc/postfix/header_checks’, and add these lines:

/^Return-Path: <>/                              REJECT no third-party DSNs
/^From:.*MAILER-DAEMON/                         REJECT no third-party DSNs

Edit ‘/etc/postfix/null_sender’, and add:

<>              550 no third-party DSNs

Edit ‘/etc/postfix/main.cf’, and ensure it contains these lines:

header_checks = regexp:/etc/postfix/header_checks
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/null_sender

(If you already have an ’smtpd_sender_restrictions’ line, just add ‘check_sender_access hash:/etc/postfix/null_sender’ to the end.) Finally, run:

sudo postmap /etc/postfix/null_sender
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

Install the Virus-bounce ruleset. 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.

Once you’ve done these two things, that deals with almost all the forged-bounce load, at what I think is a reasonable cost. Comments welcome…

Tags: anti-spam, backscatter, bounces, email, howto, smtp, spamassassin, vbounce, virus-bounces, viruses

As all right-thinking people know by now, Challenge-response spam filtering is broken and abusive, since it simply shifts the work of filtering spam out of your email, onto innocent third-parties — either your legitimate correspondents, people on mailing lists you read, or even random people you have never heard of (due to spam blowback).

I’ve ranted about this in the past, but I’m not alone in this opinion — and frequently find myself explaining it. To avoid repeating myself, here’s a canonical collection of postings from around the web on this topic.

• Spamcop FAQ: Why are auto responders bad?:

Description: This “selfish” method of spam filtering replies to all email with a “challenge” – a message only a living person can (theoretically) respond to. There are several problems with this method which have been well known for many years.

1. Does not scale: If everyone used this method, nobody would ever get any mail.
2. Annoying: Many users refuse to reply to the challenge emails, don’t know what they are or don’t trust them.
3. Ineffective: Because of confusion about these emails, many of them are confirmed by people who did not trigger them. This results in the original malicious email being delivered.
4. Selfish: This is the problem we are mainly concerned with. By using challenge/response filtering, you are asking innumerable third parties to receive your challenge emails just so that a relatively few legitimate ones get through to the intended recipient.

• Karsten M. Self: Challenge-Response Anti-Spam Systems Considered Harmful:

C-R systems in practice achieve an unacceptably high false-positive rate (non-spam treated as spam), and may in fact be highly susceptible to false-negatives (spam treated as non-spam) via spoofing.

Effective spam management tools should place the burden either on the spammer, or, at the very least, on the person receiving the benefits of the filtering (the mail recipient). Instead, challenge-response puts the burden on, at best, a person not directly benefitting, and quite likely (read on) a completely innocent party. The one party who should be inconvenienced by spam consequences ¿ the spammer ¿ isn’t affected at all.

Worse: C-R may place the burden on third parties either inadvertantly (via spoofed sender spam or virus mail), or deliberately (see Joe Job, below). Such intrusions may even result in subversion of the C-R system out of annoyance. Many recent e-mail viruses spoof the e-mail sender, including Klez, Sobig variants, and others.

• John Levine: Challenge-response systems are as harmful as spam:

The collateral damage from widely used C/R systems, even with implementations that avoid the stupid bugs, will destroy usable e-mail. [jm: in fairness, this was written in 2003.]

Challenge systems have effects a lot like spam. In both cases, if only a few people use them they’re annoying because they unfairly offload the perpetrator’s costs on other people, but in small quantities it’s not a big hassle to deal with. As the amount of each goes up, the hassle factor rapidly escalates and it becomes harder and harder for everyone else to use e-mail at all.

• Ed Felten: A Challenging Response to Challenge-Response:

I’m skeptical of CR as a response to email. If you’re the first on your block to adopt CR, and if nobody else uses anti-spam technology, then CR might provide you some modest benefit. But it¿s hard to see how CR can be widely successful in a world where most people use some kind of spam defense.

• Jeremy Zawodny: TMDA Users Can Blow Me (heh):

If these systems are so brain-dead as to not bother adding my address to the whitelist when the user sends me e-mail, I have serious trouble understanding why anyone is using them.

Is it just me? Is this too hard to figure out?

Anyway, there’s another 5 minutes I’ll never get back. It’s too bad there’s no mail header to warn me that “this message is from a TDMA user”, because then I’d be able to procmail ‘em right to /dev/null where they belong.

Ugh.

This bullshit is not going to “solve” the spam problem, people. If that’s your solution, please let me opt out. Forever.

• Michele Neylon: Why C/R is not a good idea:

C/R slows down and impedes communication by placing unwanted barriers between you and your clients/suppliers.

If you must insist on using some form of C/R please make sure that you whitelist my address before you contact me as I will not reply to challenges.

• TidBITS policy on Challenge-Response:

We will not answer any challenges generated in response to our mailing list postings. Thus, if you’re using a challenge-response system and not receiving TidBITS, you’ll need to figure that out on your own. Also, if you send us a personal note and we receive a challenge to our reply, we may or may not respond to it, depending on our workload at the time.

• Fedora Project policy on UOL — a Brazilian ISP that uses C-R extensively:

uol.com.br uses a very broken method of anti-spam. Everytime someone sends an email message to one of their members, they send back a verification message, asking the original sender to click a link before they will allow the message through. These messages are themselves a form of spam, and the resulting back-scatter of these messages is altogether bad for the Internet, the UOL member, and all of the UOL member’s contacts. UOL is aware of the complaints against them, and they refuse to correct the issue, claiming that their members love the service.

• Matt Sergeant: C-R spam solutions:

I hate C/R systems. With a passion. I absolutely will not respond to them. They go in the trash. I don’t get them very often but I get them more and more. I think they have the potential to seriously damage email communication as we know it. And I’m not alone in this opinion.

• Richi Jennings: ‘Challenge/Response makes you a spammer.’

• BusinessWeek: Stephen Wildstrom: A Spam-Fighter More Noxious Than Spam: ‘Challenge-response filtering systems are likely to wipe out e-mails you want, too.’

• and lots more at Spamlinks.net

Phew.

Tags: abuse, anti-spam, backscatter, blowback, bounces, c-r, challenge-response, email, filtering, rants, smtp

Yay! Kudos to Richi Jennings, who’s been trumpeting the dangers of backscatter to InformationWeek recently. It’s a great article. I particularly like how it digs up this impressively off-the-mark quote:

Tal Golan, CTO, president, and founder of Sendio, maker of a challenge/response e-mail appliance used by more than 150 enterprise consumers, disagrees strongly with Jennings’s assertion that challenge-based filtering has problems. “Without question, the benefit to the whole community at large drastically outweighs that FUD [fear, uncertainty, and doubt] that’s out there in the marketplace that somehow challenge/response makes the problem worse,” he says. “The real issue is that filters don’t work. From our perspective, challenge/response is the only solution. This whole concept of backscatter is just not true. Very, very rarely do spammers forge the e-mail addresses of legitimate companies anymore.”

hahahaha. Well, since last Thursday, “very very rarely” translates as “214 MB of backscatter in my inbox”. The facts aren’t on Tal Golan’s side here…

(PS: SpamAssassin 3.2.0 will include backscatter detection.)

Tags: anti-spam, backscatter, bounces, challenge-response, filtering, funny, richi-jennings, sendio, spam