Phishing education eludes Net users; Can reverse DNS zap phishers and spam?

Two stories in one here (trying to economize).

If you haven't noticed, I'm on one of my anti-spam kicks (again). Last week, I published a video asking Google, AOL, Microsoft, and Yahoo! (GAMY!) to once and for all to set aside their differences, decide on some standard approaches to ridding the Internet of spam, and then embrace those approaches -- basically strong-arming the rest of the e-mail servers and services out there to follow along or they'll be "out of the loop" so to say (the e-mail loop, that is). The video is up on YouTube with a Creative Commons license and you can help apply pressure by posting it on your Web sites and blogs with whatever commentary you care to add.

Today's news from InfoWorld that Internet users still haven't fully grokked what phishing is and how to avoid phishers is a perfect example of why its imperative that GAMY! step up now. Reported IW's Elizabeth Montalbano:

Security researchers in Pittsburgh last week disagreed over how to educate Web users to prevent phishing attacks, but they agreed on one thing: Most current methods of user education are inadequate.....Aaron Emigh, executive vice president of technology at blog software and services provider Six Apart, said that people have been duped by miscreants for thousands of years and that technology has made it easier for people to fall for scams in an infinitely scalable way. He said that security researchers should focus more on creating user interfaces that can't be compromised rather than trying to train users to identify scam sites.

Amen Aaron. But replace the phrases "security researchers" and "user interfaces" with "GAMY!" and "standard anti-spam protocols" and now you're talking. That's because phishing is invariably discussed as though it isn't spam when it is. Phishers never want you to know who they really are and they use the same address spoofing techniques that spammers use to cover their tracks.

Speaking of covering tracks, one ZDNet reader, Paul Trader, wrote to me regarding an existing quasi-standard that if applied differently from the way it was originally intended, could go a long way towards authenticating the source of e-mail (in other words, making sure that an e-mail's tracks lead back to where they should). The technique is known as reverse Domain Name Service lookup (rDNS) and it works the opposite of the way the Internet's DNS works.

With the Internet's Domain Name Service, the basic idea is for people and machines to be able use domain names (eg: cnet.com) instead of cryptic numerical addresses (IP addresses) to reach some intended target. When "cnet.com" is used for addressing an e-mail recipient or reaching the CNET.com Web site, a DNS server steps in and coverts the domain name to an IP address for you. But can it work in reverse? When an e-mail arrives with some IP address as its source, can that be looked up and resolved to a domain name to see if it matches the domain the e-mail purports to come from? Although it's not a silver bullet to eliminating spam, rDNS could theoretically play a role. But the problem, and a very big problem at that, is not every site administrator is encoding their DNS records with the necessary information to enable an rDNS lookup. That's because adding that data is pretty much optional.

Today, nothing critical on the Internet depends on it. In particular, the standard for Internet e-mail (the Simple Mail Transfer Protocol, RFC 2821) doesn't require it. As a result, e-mail administrators are under no obligations to configure their servers to support rDNS. If they don't bother, then any attempts by a recipient's system to authenticate e-mails coming from those servers by way of an rDNS lookup would fail and the e-mail in question would likely get falsely classifed as spam.

In his e-mail to me, Paul Trader acknowledges that, as it stands today, it would be unfair to start authenticating mail on the basis of optional DNS data. Too many legitimate e-mails would end up as false-positives. But he also says something that few who understand e-mail protocols would disagree with: those standards were written at a time when spam wasn't an issue. Perhaps it's time to revisit them and make the optional rDNS data not optional anymore. Wrote Trader:

While I agree that the techniques I use violate the spirit of the RFC, i also believe the RFC was written so long ago (I think 1982 was the last revision), that the authors couldn't have possibly forseen the abuse the spammers would be doing. The RFC itself could be what allows the spammers to abuse it and get their crap through.

I used to get between 600 and 1000 spams per day. Now I get less than 30 per day, and routinely block 50,000-100,000 spam messages and servers per week.

So, in my opinion, we'll never get a leg up on the spammers unless the RFC is revised and rDNS information is required for every mail server that tries to connect and deliver mail....the large majority of spam I block is because of bad rDNS data.

Is rDNS a part of the cure? It's definitely not the complete cure and more diligence would have to be done before we could definitively say it might work. But just suppose it might. Or just suppose something else standard might work. This isn't about changing RFCs. This would be about GAMY! announcing that on some date -- perhaps a year from now (in order to give campaign and sink-in time) -- that they will no longer be accepting e-mail from servers missing rDNS data. It's that simple. GAMY! has so much collective muscle and practically every e-mail server has to interact with their servers that it wouldn't be long before the optional rDNS data would be supplied by everyone by default.

Or, maybe it's not rDNS. Maybe it's Sender Policy Framework (SPF) or some other method of authentication. But this is an example of the muscle that GAMY! has. Is it blackmail? I guess. Might there be side effects? Short-term (and nothing the collective intelligence at GAMY! can't resolves). Does it matter if it helps bring an end to spam? Not if you ask me.