Something to avoid in callback email address verification

December 21, 2006

Here's something I would like to grind into various people programming callback email address verification:

Don't do callback email address verification with a MAIL FROM of <> unless the address has actually sent you email.

Why? Because if an address never sends any email to start with, it may not be willing to receive bounces (the major source of email from <>). Blocking null MAIL FROMs from sending email to such addresses is a completely rational way to block bad bounces from forged spam runs.

The people doing this that make me really grind my teeth are SourceForge, who insist that both the origin address of the email and postmaster be willing to accept mail from <>. Our postmaster address is often forged on spam and never sends email, so we would really like to refuse bounces to it. Unfortunately mailing to SourceForge hosted mailing lists is somewhat more important, although we have been known to keep postmaster blocked most of the time and manually unblock it when necessary.

Not that callback email address verification is a good idea in general. But if people are going to implement a non-good idea, I'd like them to do it in a way that doesn't make me grind my teeth in their direction.

(Although every now and then I am tempted to hack something into our mailer configuration to auto-accept every address verification attempt from certain annoying places, like Earthlink and Verizon, no matter whether or not the address actually exists. (If they actually send email, we can refuse it at the DATA phase or something.))

Comments on this page:

From at 2006-12-21 23:56:39:

Wow, Sourceforge is nearly as incompetent as Verizon when it comes to their dictionary attacks, er, sender address verification callbacks.

There is an SMTP command for address verification. It's called VRFY. Many sites turn it off for privacy reasons, including because they don't want to make it trivial for spammers to find live addresses. Doing a MAIL FROM/RCPT TO hack to get around that is at best rude, and is often rightly seen by the victims as a deliberate attack by someone up to no good.

Beyond the "I'm trying to break into your system" issue, operations like Sourceforge and Verizon are insanely stupid when it comes to sender address verification callbacks. Verizon is particularly egregious. Let's list the ways.

First, Verizon calls back from a different IP range than the one containing the server the sender connected to. This neatly dodges the original mail server's whitelisting of IP ranges to which its users have sent mail. This means Verizon gets a false negative due to the more general blacklisting of Verizon's network because of their insane numbers of spambots.

Second, Verizon can't be arsed to provide proper reverse DNS on their callback source IP range. This makes them indistinguishable from any garden variety zombie net. This means Verizon gets a false negative due to wise sites not accepting mail from networks too incompetently managed to handle reverse DNS.

Third, Verizon calls back using a different envelope sender address than the one the original sender was trying to reach. This neatly dodges the original sender's whitelisting of his original correspondent. This means Verizon gets a false negative on any whitelist-only users, or on users that attempt to avoid Verizon's insane numbers of spambots by making Verizon's network whitelist-only.

The end result for Verizon is that they refuse a whole boatload of legitimate mail, causing us and others to recommend that our correspondents on Verizon leave and find a more reliable service. And of course Verizon's spam sending continues unabated, but that's another topic.

Anyway, I'll now add Sourceforge's stupid sins (using 'MAIL FROM <>' when there's no message that they're actually going to bounce, and bothering postmaster@ when postmaster@ didn't try to send them anything) to my general rant about just how bad sender address verification callbacks are. Bah, what 'tards they all are.

Written on 21 December 2006.
« How many root DNS servers are reachable over Internet II?
Another example of why Bourne shell quoting makes me grumpy »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Dec 21 23:22:43 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.