Sender Address Verification: Still a Bad Idea

Home / Blogs

Sender Address Verification: Still a Bad Idea

Apr 07, 2008 9:00 AM PDT
Comments: 5
Views: 5,741

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?

The most obvious problem is that it doesn't work to verify addresses. There's lots of reasons why the naively implemented checks that callouts use can succeed for a non-existent address or fail for a good address. Many mail systems (including mine) accept all addresses at the RCPT TO, and reject the bad ones at the DATA command, giving the callout system the mistaken impression that bad addresses are good. Conversely, systems that implement techniques against spam blowback (bounces from spam forging their addresses) can often reject callouts because they look just like blowback, giving the callout system the mistaken impression that good addresses are bad.
Address verification is not an effective spam filter. These days most spam uses other people's real addresses taken from the spam target lists, so all you're verifying is that they stole someone's address.
Callouts are abusive. Since upwards of 90% of mail is spam with forged addresses, 90% of your callouts are to people who never sent you mail or otherwise bothered you.
Callouts are likely to get you blacklisted, since the behavior of callouts is indistinguishable from spammers trying to do bulk listwashing of bad addresses.
Callouts are discredited. Every large ISP that used to do callouts, most notably Verizon, found it was counterproductive and stopped.

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.

Written by John Levine, Author, Consultant & Speaker. Visit the blog maintained by John Levine here.

Related topics: Spam

Master Feed (more feeds)

Twitter

Mobile

Bookmark / Email This Post

Print Comment

Comments

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

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

# 1 Reply | Link | Report Problems

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

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.

# 2 Reply | Link | Report Problems

Your position is just plain dead wrong Marc Perkel – Mar 01, 2009 1:58 AM PDT

I am the owner of Junk Email Filter and we filter spam for about 4000 domains, and we actually use sender callout verification. I'll address each of your 5 points.

1) Just because it doesn't work on some systems doesn't mean it doesn't work at all. It is in fact very useful on the systems where it does work, which is most of the world. No one does a callout for every email address presented. My spam filtering system does less than 1/2 of one percent verifications and many of those are cached. You also ignore false failures by ignoring servers that reject all empty senders at the MAIL FROM phase. No one in the real world implements callback the way you are implying.

2) Your second point contradicts your third point that states 90% of sender addresses are forged.

3) Your third point is just a bare allegation of your opinion that callouts are abusive.

4) Your 4th point that callouts are likely to get you blacklisted is dead wrong. I personally am making 50k callouts a day and not getting blacklisted.

5) And finally that callouts are discredited is untrue because every major MTA has built in callout features or third party callout enhancements. My servers receive thousands of callouts a day and I use the data to white list servers. (Spammers don't do callouts - only spam filters do callouts)

You should do your homework and actually understand the technology before denouncing a technology that you haven't thought through.

# 3 Reply | Link | Report Problems

I am the owner of Junk Email John Levine – Mar 01, 2009 3:14 AM PDT

I am the owner of Junk Email Filter and we filter spam for about 4000 domains, and we actually use sender callout verification.

There's a famous quote from Upton Sinclair that applies here.

# 4 Reply | Link | Report Problems

There's a famous quote from Upton Sinclair wayne – Mar 01, 2009 12:53 PM PDT

There's a famous quote from Upton Sinclair that applies here.

Indeed, although in the case of Marc, I think it is not just difficult, but close to impossible. This has all come down from Marc's recent editing of the wikipedia "callback verification" article, I suggested it would be more productive to debate you here rather than there.

I'm still not sure why Marc claims that your second point contradicts your third. Maybe he is assuming that all foraged email addresses are also invalid, rather than valid ones.

# 5 Reply | Link | Report Problems

To post comments, please login or create an account.