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

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

Summary: Two stories in one here (trying to economize).If you haven't noticed, I'm on one of my anti-spam kicks (again).


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: instead of cryptic numerical addresses (IP addresses) to reach some intended target. When "" is used for addressing an e-mail recipient or reaching the 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.

Topics: Browser, Collaboration, Networking, Security, Servers

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • SenderID and SPF works a lot better since not everyone controls their own

    SenderID and SPF works a lot better since not everyone controls their own reverse DNS. Setting up a regular forward DNS is trivial; setting up reverse DNS isn't and that's why rDNS isn't a reliable metric. SenderID and SPF are also targeted to email applications but all three methods break forwarding if the forwarder is outside of your domain.

    DomainKeys is a superior solution because the digitally signed messages can be relayed through any number of mail servers. DomainKeys also offer non-repudiation which makes it easier to tally reputation services.
    • Agreed. (NT)

      none none
    • Only spammers use them

      And since they are so effective why is it that over 90% of the spammer machines that hit our server have SPF records now? Because they will invest the time to look legit.

      DomainKeys is another joke. Only Yahoo really supports it, and almost no one validates it. So you add a DomainKey to your server? Does nothing for the other 9 million zombies out there.

      There is NO magic bullet in spam.
      • Magic bullets

        There is a magic bullet. Spam wants to sell something, widgets, marbles or chalk. Fine the person who is the "order from" in the spam.

        I'm not saying 'slap his wrist', FINE the turkey, someone pays the spammers to send this crap. Break the payer and the spammers dry up,they ain't doin it fer a hobby. No money, no spam. Simple.

        Break a couple publicly, there won't be companies hiring bot herders to advertise their crap.

        Bob J
  • rDNS is actually used by real mail servers, alas

    "Today, nothing critical on the Internet depends on [rDNS]. [...] If they
    don???t bother [or can't!], 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."

    Mail delivery often depends on rDNS. There's a surprisingly large
    number of sites that require rDNS match forward DNS for your
    outgoing mail servers, as I found out when I was stuck with an ISP that
    refused to let me provide my own rDNS... several times I had to call
    up some customer or vendor and get them to either turn off the rDNS
    check or to make us an exception.

    You SHOULD be able to set up an SPF record for your mail server, and
    recipients should let that override rDNS checks, but that requires a lot
    of ab-initio reasoning that's beyond the capabilities of folks who just
    set up servers by using a wizard.
    • There is another step that has been forgotten

      Reverse DNS is only half the picture. In many MTAs (Mail Transport Agent programs), there is an option available to only accept incoming mail from other MTA's with a properly registered MX record in DNS. Spammers generally don't have access to reverse DNS capabilities, nor to MX records.
  • RE: Phishing education eludes Net users; Can reverse DNS zap phishers and s

    rDNS is not even a part of the solution. It's like SPF, but with restrictions, like you have to own the IP address from where you send mail.

    I could see GAMY liking that. Along with all the other large ISP's/hosting companies. It kind of shut's out the diy'ers.
  • RE: Phishing education eludes Net users; Can reverse DNS zap phishers and s

    Take a look at the Santronics WinServer...They have been doing this since 2003
  • Already partially in place; what about 3rd party services

    Two issues with this.

    1. Yahoo,, et al. already require reverse DNS for SMTP mail servers, in a way. We've run into this several times when we've either changed ISPs or just because. My users start screaming when they get bounce messages from these big e-mail recipient domains. At this point my first check is to see if reverse DNS is correctly reporting the server (usually not). This has largely been mitigated by point 2.

    2. We have been using Postini as an inbound spam/virus filtering service. Recently, because the reverse DNS issue continued to be a problem, we have begun routing our outbound through Postini as well. Now our MX record reports Postini as inbound as well as the outbound source address, which was part of the problem before. Now that the MX and outbound source addresses are the same, everybody is happy. However, the outbound source IP address doesn't resolve to our domain, but only to the MX record. So the rDNS as mentioned in the article might not work, correlating the IP source strictly with a domain name. An NSLOOKUP to our domain name, no host, returns the www address.

    I agree that a specific authentication framework, whichever flavor might win, would be the better solution. A question that arises, though, is how would legitimate unsolicited mail be sent, i.e. updates from an ad agency retained by one of your active vendors? Just like the list doesn't include companies you already have accounts with, e.g. your phone company or long distance, would there also have to be some sort of exceptions within this framework?

    I agree something must be done. My quarantine list from Postini has grown over the last few weeks, as well as the number of e-mails that still make it through. The filtering service is deleting, not quarantining, fully 2/3 of our inbound mail. That's a LOT of crap!
    • Beyond authentication


      Your question regarding "legitimate unsolicited mail" is a great one that I've talked a lot about. Some people see unsolicited mail as spam no matter what. Others may want to see certain pieces of unsolicted mail. Personally, I think there's another layer of relationship management technology that can work in combination with whatever authentication approach ends up getting used.

      Start for example with the idea of unsubscribing. The can spam act has already legalized unsolicited mail as long as it isn't fraudulent and under the requirement that recipients can unsubscribe. However, unsubscribing is too non-standard of a process. There should be an unsubscribe protocol that works much the same way e-mail works, supporting a store-and-forward architecture and built-into that protocol are a series of return messages. For example,

      1. unsubscribe me from the list that resulted in me getting this e-mail.
      2. unsubscribe me from all lists on this server.
      3. unsubscribe me from the domain altogether

      I'm just scratching the surface, but this is really about managing your relationship with a domain than it is unsubscribing. Then, let's say I receive an e-mail from your list server... the first thing my email server does is a check (sort of like "FINGER") that asks, "Does the sender support the relationship management protocol?" If not, the e-mail is simply turned away. Instead of just being used as a convenient way of unsubscribing, REPORT SPAM buttons can be more about managing the reputation of some sending domain as respecting this protocol. It can't be hard to test and it'd be way better than subjective RBLs.

      End user systems could be configured to require a pre-established relationship. Perhaps the first time you want to blast me with unsolicited mail, you first must do an equivalent of a knock on my door. First, using the authentication protocol, I verify that you are who you say you are. OK, you past the first test. Next, I get an elevator pitch. So and so wants to enter your inbox to tell you about shoes. Then, I can pre-emptively decide to allow it (whitelisting on both sending and receiving servers). This is the equivalent of an "OK, I'll subscribe." The idea is that unsolicited senders of mail have to earn my trust. It's not assumed and when you give me the elevator pitch, it had better be honest or I'll turn your domain off altogether.

      I could keep going.. but some protocols for handling subscription and unsubscription would be another step in building a different e-mail system. RSS could also play a role. For example, any and all unsolicted mail must knock first. If I look through the peep hole and like what I see, I subscribe to your RSS feed through which you deliver your unsolicited mail. The minute you spam your feed, I turn you off. This way, solicitors never have unbridled access to your inbox.

      Does this need work? Absolutely. Is it perfect? No. Does something like this make sense given where we are today? I think so.

  • reverse DNS is privacy violation tech

    Reverse DNS look-up is primarily a privacy violation
    measure, and does little to fight spam, phishers,
    worms or viruses.
    • Re: reverse DNS is privacy violation tech

      [i]Reverse DNS look-up is primarily a privacy violation

      How so?

      none none
    • Possibly, but

      Then again, the very act of sending mail is a privacy invasion. So is the act of placing a telephone call.

      No one has the right to perform these acts of privacy invasion without giving up their own privacy. This should be compared to writing a check and signing someone else's name to keep your privacy.

      If you wish to invade someone's privacy, you have no right to retain your own. The street goes both ways.
      Update victim
  • RE: Phishing education eludes Net users; Can reverse DNS zap phishers and spam?

    This has been a very interesting and frustrating discussion. Phishing and the resultant identity theft issues are on the rise. Regular computer users hear about all this stuff and it frightens them to death. Then we have all these companies who claim they can stop this stuff with their "protection". If you have a router with a firewall people ask why do need a software firewall too. If there are all these technical options for helping to protect idententy theft then we should be ashamed of ourselves for not making them sop in our environments. Are we foolish or do we really not care?
  • RE: Phishing education eludes Net users; Can reverse DNS zap phishers and spam?

    Use Spamarrest. If the incoming email is from someone who is not in your address book, the email gets trashed. Turns it into a "slice" of spam that no one gets.
  • RE: Phishing education eludes Net users; Can reverse DNS zap phishers and spam?

    I had a bad experience with SPF. My hosting company (GoDaddy) was aggresively implementing it and quietly tossing email in the trash where I couln't see it. There was an issue with my brokerage that used a secondary mail forwarder to blast out end-of-day statements to millions of accounts. I ended up having to change hosting companies.
  • Reverse DNS does not work

    I have been running reverse DNS on my Exchange mail server. This marks the failures in the header.

    Recently I started using a rule to move them to a folder, so I could see what happened.

    I was stunned - about 20% of the reverse DNS failures were spam and the rest genuine. These include the UK government, Cisco and a lot of domains that should be configured OK.

    Now it could be that my ISP's DNS is stale or out of date, but this is unlikely for all the domains I have checked.
  • What of multi-domain servers ?

    There's one big problem with rDNS checking : what of servers that handle multiple domains ?

    You can only set up one rDNS per IP, which means you'll always be stuck if you want to set up such a server.

    One of the servers I manage is in this situation, and buying multiple IPs for the server would be too expensive.

    So this idea would only work if one also modifies the DNS protocol, if it's only technically possible.
  • Er...

    What about people like me? I have a legitimate server, hosted somewhere together with 10 000 others on the same machine? How do I set up reverse DNS?
  • RE: Phishing education eludes Net users; Can reverse DNS zap phishers and s

    I think the best way to solve the spam problem is to treat all incoming mail like an IMAP server. It works this way: I'll take a look at the header information for your message. If I want to read it, I'll download the message from your mail server. If you don't have a mail server to hold the message, I probably don't want to read the message anyway.