Sender Address Verification: Still a Bad Idea

By John Levine
John Levine

A lot of spam uses fake return addresses. So back around 2000 it occurred to someone that if there were a way to validate the return addresses in mail, they could reject the stuff with bad return addresses.

A straightforward way to do that is a callout, doing a partial mail transaction to see if the putative sender's mail server accepts mail to that address. This approach was popular for a few years, but due to its combination of ineffectiveness and abusiveness, it's now used only by small mail systems whose managers don't know any better.

What's wrong with it?

I was dismayed to hear just last week from an acquaintance who was trying to persuade his system manager not to use this brand new anti-spam silver bullet. I hope he succeeded.

See Related Topics: Spam

This has been a featured post from John Levine, Author, Consultant & Speaker. To stay updated with CircleID via Email, RSS, Mobile Handsets or Twitter, visit the CircleID Extras page.

Comments

Re: Sender Address Verification: Still a Bad Idea Tom Lowenhaupt  –  Apr 10, 2008 10:34 AM PST

John,

Perhaps you might advise. A quick review of recent bounced emails show the following messages:

- 550 5.1.1
- Sorry, I couldn't find a mail exchanger or IP address. (#5.4.4)
- 550 relay not permitted
- 554 5.7.1 <help@openplans.org>: Relay access denied
- 530 authentication required for relay (#5.7.1)

Are any of these the result of the "callout" practice you identify? If so, perhaps I'll get more specific as to a remedy the next time I bring attention to the bounce.

Thanks,

Tom Lowenhaupt

Re: Sender Address Verification: Still a Bad Idea Ale  –  Apr 13, 2008 1:06 AM PST

In addition to the five reasons that John points out, callouts are not scalable. A server issuing a callout would do so even in response to another callout, unless it is able to detect such circularity. Circularity cannot be detected if routing peculiarities are being deployed, e.g. multihoming or nat. Infinite recursive callouts are thus likely to occur. Dummy envelope senders, such as anonymous@example.com break SMTP semantics even further.