Loser: Microsoft to Spammers: Go Phish

Pity those few doctors and patients who have perfectly legitimate reasons to mention Viagra in the subject fields of their e-mails. Pity, also, the businesspeople who must speak of funds and the computer scientists who must attach executable files. All their messages are likely to be intercepted by software filters, identified as spam, and shunted into a trash folder.

This is the problem of false positives, and it fosters doubts about the reliability of e-mail. Further doubt comes from the threat of "phishing," in which con artists send e-mails purporting to be from legitimate organizations, such as banks, in order to inveigle recipients into revealing personal information.

In all its many guises, spam as an inescapable burden of modern life has waned slightly of late, or so the numbers suggest. According to the e-mail security firm MessageLabs Inc., in New York City, spam's share of all e-mail traffic fell from a spike of 94.5 percent in July 2004 to a mere 65.2 percent in July 2005, and it seems to have been treading water ever since. Still, that's nowhere near good enough for the IT industry.

So the industry's best and brightest keep looking for countermeasures. Two are now on offer, one from Microsoft, the other from Cisco and Yahoo. Each has its peculiar advantages, and they might well be complementary. Still, if you had to choose just one of them, you'd go with the Cisco/Yahoo idea. For our purposes, that makes Microsoft Corp. the loser. Which is not to say that the gnomes of Redmond, Wash., won't improve their method and make it the standard in our galaxy. They've done it before.

The Microsoft proposal, called Sender ID, tries to verify e-mail by comparing where it comes from with where it says it comes from. Say your system ran Sender ID and got an e-mail from someone at this magazine. First off, it would note the domain, "ieee.org"; then it would look up the message's Internet Protocol address on a vetted list maintained online by what is known as a reputation service. If it found that the IP address really belonged to ieee.org, Sender ID would validate the mail and lob it into your mailbox.

The competing proposal, called DomainKeys Identified Mail (DKIM) and put together by Cisco Systems Inc., in San Jose, Calif., and Yahoo Inc., in nearby Sunnyvale, checks an e-mail's bona fides differently. Say, again, that someone in the ieee.org domain sends you an e-mail. By the time the sender's Internet service provider hands it off, the DKIM system will have tacked on an encrypted digital signature to the e-mail's header. The header includes, along with the encryption, instructions on where to find the algorithm that calculated the signature and the public key that breaks the code. Your e-mail server would follow the instructions, discover that the message indeed came from ieee.org, and send it through to you.

So far, so equal. But now imagine that the message had been forwarded to you by a friend at the IEEE, who got it from someone at the Federal Communications Commission. Cisco/Yahoo's DKIM would find the signature on a list from fcc.gov and validate the e-mail. Microsoft's Sender ID, however, would see that the domain was fcc.gov whereas the IP address pointed to ieee.org, conclude that it was spam, and stick it in the junk folder.

This glitch with forwarding is important, because forwarding is one of the features that makes e-mail so useful for social networking. Forwarding makes it easy, sometimes too easy, to share jokes, articles, and photos--even actual work--with your colleagues. Of course, you can get around Sender ID by cutting text out of an incoming message and pasting it into a new one. But such complex forwarding takes time, and time is precisely what e-mail was meant to save. If you makeit harder to share, people will share less. Harry Katz, theprogram manager for Microsoft's technology care and safety group, acknowledges that DKIM is better than Sender ID for forwarded mail.

Jim Fenton, who holds the title of distinguished engineer in the security technology group at Cisco, says that his company and Yahoo came up with similar ideas (DomainKeys and Internet Identified Mail, respectively), and when they realized these systems were alike, they put them together. He freely admits that his system has a disadvantage compared with Microsoft's: it is more likely to be confused by changes made to an e-mail in transit.

"Say that a mail server changes the text from one character format, like ASCII, to another, like Unicode," he says. "It's not common, but it can happen, especially when you change from one language to another. That will change the header and invalidate the message."

Both Fenton and Katz say that their systems could be used together. E-mail that seemed bad to one might be funneled to the other, for one last look, before being consigned to the waste bin. That way, some false positives could be avoided, we'd answer more of the e-mails that were sent to us, and we'd be less likely to inadvertently ignore legitimate e-mail from friends.

This idea of using complementary filters can be expanded to create what military strategists call a defense in depth. It could begin with Sender ID, proceed to DKIM, and go on to a content analyzer that scans for words like "Viagra." You could try to set each filter liberally enough to keep false positives to a minimum (though measuring the rate of false positives can be very hard to do). You could add even more filters, but at some point the cost--in terms of calculations per second, bandwidth, spec creep, and administrative headaches--would become prohibitive.

In any case, no form of sender verification, not even DKIM, can counter all the tricks that spammers now have, let alone the ones they'll come up with for the next cycle of the arms race we're all in. For example, there are zombies--networks of PCs commandeered by hackers to spew spam from seemingly safe domains--that could be killed only by constantly and frequently vetting every last one of the Internet domains on Earth. Then there is "pharming," an improvement over phishing in that it doesn't require the naive cooperation of the victim. Instead, the fraudsters hack their way into a legitimate corporate site, install a software dodge that redirects visitors to their phony site, and there convince them to disgorge reams of personal information. None of these spamming methods would be counteracted by either Sender ID or DKIM.

Not everyone in the computer industry approves of the companies' antispam methods, even though both Sender ID and DKIM are being offered free of charge. There has been particular suspicion of Microsoft, which, true to form, is keeping a tight hold on the intellectual property behind Sender ID. Who knows what that control might portend, some critics ask. Someday Internet service providers will wake up, they suggest, to find themselves locked into a standard and forced to pay a fee for some follow-on product.

Microsoft already has Sender ID up and running on its Hotmail system, and in November it started flagging any message its servers couldn't authenticate. This may seem a rather high-handed way of getting others to sign on to the method, and indeed, a lot of IT companies have balked. They don't like being strong-armed, and they're worried about false positives--the very problem Sender ID was supposed to solve.

There's no doubting Microsoft's desire to squash spam. It has initiated or participated in more than 100 lawsuits against spammers in recent years and won or favorably settled about half the cases. The company works hard at refining the software that analyzes e-mail for suspect words, graphics, and other content. It thinks out loud about such radical (and hard-to-implement) antispam ideas as charging a small fee for each e-mail message. Still, though Microsoft's goals are good, its implementation needs work.

Sender ID

Goal: Squash spam.

Why It's a Loser: It can't tell whether forwarded mail is legitimate or spam.

Organization:

Microsoft Corp.

Center of Activity: Redmond, Wash.

Number of People on the Project: Not available.

Budget: Not available.