Sender Address Verification: Still a Bad Idea

Home / Blogs

Sender Address Verification: Still a Bad Idea

	By John Levine Author, Consultant & Speaker
	April 07, 2008 Views: 58,349 Comments: 18

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.

By John Levine, Author, Consultant & Speaker

Filed Under

Spam

Comments

Tom Lowenhaupt – Apr 10, 2008 6:34 PM

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

: 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

Alessandro Vesely – Apr 13, 2008 9:06 AM

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 [email protected] break SMTP semantics even further.

# 2 Reply | Link | Report Problems

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

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

It doesnt work, period Suresh Ramasubramanian – Oct 6, 2009 1:50 PM

> 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. 50K a day is peanuts mail volume wise for mailserver farms of the size that'd have to block you so that you'd find out you're being blocked.

# 4 Reply | Link | Report Problems

Your second point contradicts your third point David Romerstein – Oct 8, 2009 5:17 PM

Your second point contradicts your third point that states 90% of sender addresses are forged. Wait, what? Point 2: most spam is sent using real end users' addresses Point 3: 90% of spam is sent with forged addresses How are these contradictory? If I send mail using your real, legitimate address, I've sent mail with a forged address, right? If most spam uses other victims' real, legitimate email addresses, that spam is still sent with a forged address, right? And those callouts are then going to go to real, legitimate email addresses that had absolutely nothing to do with the sending of the spam.

# 5 Reply | Link | Report Problems

I am the owner of Junk Email John Levine – Mar 1, 2009 10:14 AM

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.

# 6 Reply | Link | Report Problems

There's a famous quote from Upton Sinclair wayne – Mar 1, 2009 7:53 PM

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.

# 7 Reply | Link | Report Problems

Yes, apply to BATV too.By the way, Daniel Kamers – Mar 13, 2010 5:31 PM

Yes, apply to BATV too. By the way, SPF would work if used. A "~all" (instead off -all) that stays there FOR YEARS should be blacklisted! Its intended to be TEMPORARY (changing), but its used by some of the bulk mailers that agree with you, forever. I am not seller nor blabher, just a user. I like BATV, domain keys, SPF, or SAV, as long as any of it just works or _at least help_. What I really dont understand and really dont like is: have to pay (!) for beeing out of "backscatter.org", just because you are saying things like these on your note, and many users just "believe" it (because "are not able to understand"). Almost imoral.

# 8 Reply | Link | Report Problems

Any real reason? Daniel Kamers – Oct 5, 2009 8:25 PM

Hi! Are there any real reasons for not using SAV (along with other techniques)?

* “...it doesn’t work to verify addresses.”
It seems to me it works. This very post was subject to a valid email sender verification. Accept any RCPT TO and rejecting in DATA changes nothing, right?

* “...systems that implement techniques against [backscatter] can often reject callouts because they look just like blowback”...
Well, it should differentiate it…

* “Address verification is not an effective spam filter. These days most spam uses other people’s real addresses”
So? Well, SAV have worked anyway. SPF would help.

* “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.”
Spam is abusive, not callouts. And callouts are for systems, not people. The systems should just say “ok, it´s valid” (in RCPT TO, in DATA, does not matter). Won´t hurt.
Any valid end-point (IP, port, email, www, whatever) is subject to DoS. Nothing to do with SAV. The spoofing (and its system of origin) is the bad guy, not the one that is trying to verify it.

* “Callouts are likely to get you blacklisted, since…”: ?
It seems to me that blacklisting because of callout is abusive.
* “...the behavior of callouts is indistinguishable from spammers trying to do bulk listwashing of bad addresses.”
This is really a problem. BATV can help. SPF too. The problem again is not SAV (or NDRs).

* “Callouts are discredited. Every large ISP that used to do callouts, most notably Verizon, found it was counterproductive and stopped.”:
Well, i think callouts are in wide use…see this site, for example.

Please don´t take me as a “anti-anything”. I am a user, and I am just trying to understand it. Sure it has cons, but I am just trying to get why anyone should be “blacklisted” just because the blacklister couldn´t see the difference.
And, if it´s well done, won´t hurt. DDoS and dictionary attacks risk are there regardless SAV (it is inherent to endpoints, even if you do it at DATA commands).

Maybe its not SO a bad idea, is it?

# 9 Reply | Link | Report Problems

It's lame. The Famous Brett Watson – Oct 6, 2009 3:39 AM

This very post was subject to a valid email sender verification.

You're confusing SAV with challenge/response. You're not the only one to do this: Sendio.com markets a challenge/response system using the term "sender address verification". This is why I prefer the term "SMTP callback verification", since it is unambiguous as to the mechanics of the verification. Some even object to the use of the word "callback" in that context, because in most cases you aren't calling "back" the sender, but calling "out" to some unrelated third party. You're also confusing a web application with email. The two aren't comparable. For many reasons, email-based protection on a forum or blog does not (in general) produce the kind of undesirable side-effects that result when the same protection is applied to an email address. But let's ignore the problems of ambiguity and equivocation, drop the ideological issues, and just focus on effectiveness. SMTP-based verification has the following practical problems which make it a bad idea for most people most of the time. 1. It's relatively resource-intensive -- more so than simple DNS lookups, since you have to establish an SMTP session. For a personal-scale server this probably isn't a problem. Those who run large scale operations would need to factor in the added load and expense, and would not appreciate the additional load resulting from widespread use of the technique by others. 2. It's relatively lame. Whereas authorisation mechanisms like SPF can (in principle) assert a sender's authority to use a particular address, all this mechanism can do is assert that someone is authorised to use it. It doesn't even do that in practice, quite often: some sites will respond positively to any address because of catch-alls. 3. It's easily thwarted. Any spammer with half a brain uses "valid" addresses for the sender. It's not hard to do, and it renders all your expensive verification efforts worthless. 4. It's likely to have unintended consequences. Administrators of other mail systems may view such probing as hostile and take defensive action. This may result in serious loss of communication with desired parties. Pointing the finger at them and saying "they ought not to do that" does not change this fact. In summary, SMTP-based verification is relatively weak, relatively expensive, and likely to cause more problems than it solves. A simple DNS lookup on the domain part of the incoming address achieves the vast majority of the benefits without the expense or unwanted side-effects. If you absolutely insist on using this kind of mechanism, despite this evaluation, you should definitely use it as a last resort -- after all the cheaper, less harmful, and more reliable mechanisms have failed to produce a clear result. If you do that, measure your results and see what kind of "value for money" it delivers. I'll bet that the results won't be pretty. Lastly, note that challenge/response is an extension of SMTP-based verification, because the challenge email is delivered via SMTP. All the above issues therefore apply to challenge/response as well, but challenge/response also has additional considerations not addressed here.

# 10 Reply | Link | Report Problems

Its Lame doesnt count Daniel Kamers – Oct 8, 2009 3:53 AM

Thank you Mr.Watson. I am aware of some drawbacks (as any of the known technics), and it would certainly be lame consider IT to do ALL the job. But still didnt get a good feedback to why it should be SO terribly "BAD BAD dont do IT or go to hell"! My limitations maybe. Sorry about that and thanks for the tolerance. I wont reply to all those terrible reasons (there are already lots of this discussions around). Let me just focus on two points (take as complains): * "More or less good reason 4" - "suffer retaliation" (from the big sources of spam: the big providers): Well...I am a user as any other on Internet. Things should not work this way here. Anyway, you are right: all of this changes nothing, its still a real and serious risk (well, ok, got it: it´s not to understand it technically). * My mistakes: SAV and challenge/responde have a similar concepts but different implementations (as you noted): that´s my point, nothing wrong with the CONCEPT, but with many implementations. Sure, it should not be done ALONE or just with SPF, without caching, etc. Well, ok, I got it: "dont do it or go hell" its ok if you assume everyone is ignorant. I may accept this as a good point (really). The "value for money", if well done, is reasonable. One should consider be a siner, with discretion, and maybe we wont go hell after all. Regards.

# 11 Reply | Link | Report Problems

Nevermind... Daniel Kamers – Oct 8, 2009 4:33 AM

Sorry…Sudenly I see…you are talking about mass weapons and me about rocks. If I throw some of it I could get wiped. Its really a risk of the Wild Wild Web.
For a moment I thought it didnt work. :)
Best regards.

# 12 Reply | Link | Report Problems

Idea... Daniel Kamers – Mar 12, 2010 7:30 PM

Hi folks!
“You’re also confusing a web application with email. The two aren’t comparable. For many reasons, email-based protection on a forum or blog does not (in general) produce the kind of undesirable side-effects that result when the same protection is applied to an email address. “

I have just realized that its possible to do a DDoS to any poor email user, just putting a bot networks to register that poor user email in any (or many) websites that requires a valid email address… :) bingo…
It would be great to know about some of the “many reasons” that would avoid that…

# 13 Reply | Link | Report Problems

Forged subscriptions John Levine – Mar 12, 2010 7:51 PM

Yes, it's possible to mailbomb someone by forging subscriptions. It's happened to me, many times. But since that mailbomb is mail TO the victim, rather than mail pretending to be FROM the victim, non of this ywo year old message applies.

# 14 Reply | Link | Report Problems

Forged subscriptions just like SAV Daniel Kamers – Mar 13, 2010 5:15 PM

And for this victim, receiving site confirmations from 1.000.000 web-hosts is different from receiving callouts because… ... ...? ...captchas? Just like the one that CircleID dont have? Because its difficult to do? Harder than send 1.000.000 mails with forged return address? Well, you are right, I am not able to “get” it. My age, maybe.

# 15 Reply | Link | Report Problems

More forged subscriptions John Levine – Mar 13, 2010 5:25 PM

Getting a large number of COI confirmations for forged subscriptions is indeed very annoying, although unlike non-COI lists at least it's only one confirmation per list. If you have in mind some tweak to the mail system that will prevent bad guys from typing your address into a web form, I suspect I am not the only one who'd be intrigued to hear about it.

# 16 Reply | Link | Report Problems

tweak the mail system Alessandro Vesely – Mar 14, 2010 12:58 PM

COI forms are not standardized and can be abused in a number of ways. A simple tweak: users should tell or confirm to their servers the list they want to subscribe to. The servers connect to each other, exchange info, and end up with two specular COI data sets: a forwarding recipe at the list server, and a forwarding agreement at the user's server.

# 17 Reply | Link | Report Problems

Simple tweak? John Levine – Mar 14, 2010 2:12 PM

To abuse a famous quote, this must be a meaning of “simple tweak” with which I am not familiar.

# 18 Reply | Link | Report Problems

The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.