Experts clash over merits of anti-spam authentication

Experts clash over merits of anti-spam authentication

Summary: Weak user authentication may be worse than none at all, claims one security expert; others are backing SPF to make a difference

TOPICS: Security

User authentication for email "may be worse than useless" at preventing the spread of spam, according to Nick Fitzgerald, security consultant at Computer Virus Consulting.

"As an anti-spam measure, SPF is broken before it's implemented, as it's not just breakable, it's trivial to break," Fitzgerald told an audience at the Virus Bulletin conference in Dublin on Friday.

"Knowing a message arrived SPF compliantly tells us nothing about the actual sender and the 'spaminess' of the message," Fitzgerald added, claiming that SPF has been "widely hyped" as solving the problem of user authentication.

Fitzgerald's views were challenged by other conference attendees, who insisted that SPF would play a valuable role in fighting unsolicited junk email.

Authentication schemes such as SPF allow the owner of a domain to use DNS records to say which machines within the domain can transmit email. Recipients that use SPF can treat as suspect any email that claims to come from a certain domain but which does not actually match its SPF record.

Supporters say SPF can clamp down on the practice of 'spoofing', where spammers alter the appearance of messages so that they no longer appear to come from the domain that sent them, but another entirely.

There are no reports of spammers breaching SPF, yet Fitzgerald said SPF would be "trivial to break with just a few lines of malicious code".

"Spammers can beat off SPF trivially — they already have large botnets [networks of compromised computers]. 80 percent of spam is from compromised computers running SMTP relays and/or dedicated spam-bots," Fitzgerald claimed.

To do this, a spammer could manipulate a compromised machine and read the settings of its email program, such as its ISP's mail server settings, and use them itself. This would mean that spam could be sent tagged with the ISP's own SPF settings, making it look legitimate.

"A spam-bot could easily pull popular MUA client settings for its own use, use process injection to usurp the installed MUA, use similar techniques to usurp the network stack, and protect itself with a rootkit," Fitzgerald said.

Such behaviour from spammers was widely reported earlier this year, when SpamHaus and MessageLabs both warned of an increasingly fast torrent of spam seemingly coming from ISP's own mailservers, due to infected machines on their networks changing their behaviour to get around spam filtering techniques.

But this trick only works for ISPs that do not filter their own outgoing email. And, as Vesselin Bontchev from antivirus company FRISK pointed out, those who received such spam would be in a better position to take action as the SPF record could act as a paper trail back to the culprit.

"A user could contact the ISP and alert them to the problem, so they can fix the server," Bontchev said.

Fitzgerald, though, disagreed, saying ISPs would not blacklist compromised machines, as that would not be financially viable.

"You get almost no response from ISPs because they can't afford to cut off their customers," Fitzgerald said.

Topic: Security

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
  • Hi

    I manage the antispam ops at Outblaze, and we're a large ISP with over 40 million users.

    We were probably the first large ISP to discard SPF after publishing conservative SPF records for over a year, in late february 2005.

    Earthlink followed us in July, dropping their SPF record - and this was picked up by the press as well.

    Beginning of a trend I guess... and Nick Fitzgerald is right. Just like a lot of the other people cited in the article are just plain wrong.

    My rationale behind dropping spf is at - and was a reply to a previous ZDNET story by George Ou, which had similar ideas on how spf could stop the botnet problem

    A further overview by ASRG chair John Levine on how and why SPF Is losing mindshare, which has a pointer to a MAAWG whitepaper on SPF (MAAWG being the Messaging Anti Abuse Working Group, an association of antispam teams from different ISPs around the world.. i'd call it the nanog of antispam, as it is focused on operational issues as opposed to vendor product pitches). -

  • SPF was merely intended as an anti-forgery solution, not a solution to phishing or spam. Every now and then we get an "expert" who pops up and tells us that it won't work as an anti-spam solution. Amazing!

    SPF is just a single piece of the puzzle. The fact is that we, at some point, must agree on a way to authenticate email. If this means using SPF or Sender-ID or DKIM or some other solution - then we need to progress these technologies.

    SMTP is broken from a security point of view - and it'll take some pain to fix it. SPF has flaws as well - but it got us thinking in the right direction.
  • SPF is designed to stop email forgery. It is not designed to tell you if any given email is spam or not. While a lot of spam uses forged email addresses, and thus SPF failures are often a good indicator of spam, forged email is often undesirable, even if it is not explictly spam.

    Fitzgerald says that SPF is "breakable" by having bot nets no longer forge email addresses is kind of silly. The world would be a much better place if all spammers and phishers did exactly what Fitzgerald suggests. It would mean a large reduction in the amount of bounced spam going to the wrong person and having people blame you just because your email address was forged.

    I am sad that both Outblaze and Earthlink have removed their support of SPF. On the other hand, other major ISPs such as Roadrunner, have added support for SPF during that same time period. While it would be nice if there was a steady increase in SPF support, I am not surprised that various organizations have been adding and deleting SPF records, as they have since the beginning.

    SPF allows you to apply reputations to incoming email, so that known spamming domains can be blocked, and known good domains can be let through, even if the email uses a few spammy keywords. Many spammers are stupid and will publish SPF records even if it hurts them. Even more marketing departments think what they are doing isn't spamming, and so they publish SPF records too.

    I've never figured out why folks like CiperTrust are so worried when lots of email that is spam shows up with valid SPF records. This, again, is a good thing. It lets us block them easier.

    I don't believe any single system will stop spam. I think that DNSBLs, bayesian analysis, SPF, DKIM, DCC/Razor, detection of deceptive HTML, legal pursuit, ISPs kicking off spammers, etc. all can play an important part of reducing spam. Spam, like other forms of theft, will never go away, but to stop theft we don't *just* depend on the police. We also have locks on our doors, we have neighborhood watches, we keep doors well lit, etc.
  • I would be very happy to have viruses stop forging my email address. If SPF accomplishes that, then it has gone a long way toward fulfilling it's promise.

    If viruses are forced to use the legitimate identies of their hijacked machines, that makes them very much easier to trace and do something about. Suddenly all those worthless messages from brain dead antivirus programs become meaningful and useful. If I only got a message from a virus scanner on a remote machine when it really had detected a virus laden message coming from my machine, that would be quite useful instead of the meaningless waste of bandwidth it is now.
  • Mail authentication is wishful thinking because its symptom fighting. So speaking of all the benefits achieved once mail authentication is achieved are simply bogus.

    There are existing tools out there that could significantly cut into spam. Without overhauling currently established designs. Without opening up potentially new holes. Without putting additional requirements on currently installed software. So why not use that first before overhauling the lot? Or put in other words. Suppose mail authentication doesn't work out quite as expected. How easy would it be to rip it out again?

    Why is it that when something doesn't work out as expected it first gets ignored for years. To then be followed by a cry for updates and upgrades? Why not first see if the objective can be reached with existing means?