Ending e-mail forgery

All the experts interviewed for this article agree: fixing e-mail hinges on positive identification of the sender. And there are practical solutions on the horizon to drastically reduce forgeries that characterize some of the worst e-mail abuses.

But first, some background. There is a hole in SMTP big enough to drive a truck through and that's what spammers routinely do when they forge sender addresses. Today, it's trivial to send a message that seems to come from info@citibank.com or support@microsoft.com. Whether it's a phisher groping for access to a bank account or a cyberterrorist looking to compromise a PC, both the company whose identity is spoofed and the individual who is attacked suffer the damage.

Could cryptographic proof of identity help? Companies that run secure Web sites know how to acquire the server certificates that assert their identities and enable SSL connections. They could also use client certificates to sign e-mail messages and probably should. But individuals rarely have or use digital certificates, so e-mail culture has never evolved a security equivalent of the Web's ubiquitous SSL standard.

In our July 18 feature, "Canning Spam," we mentioned an Internet draft proposal from Hadmut Danisch, called RMX (Reverse Mail eXchange). The idea is elegantly simple: In addition to publishing the MX (Mail Exchange) DNS records that identify inbound mail hosts, an organization also publishes reverse MX records that identify outbound hosts. A receiving server queries the DNS to find out if the sending host is so authorized. The name yahoo.com is easy to forge, but the IP addresses of Yahoo's outbound servers are not.

The devil's always in the details, of course. It's remarkably difficult to define exactly what "sender" means in today's complex e-mail environment. Three current proposals -- pobox.com's SPF (Sender Policy Framework), Microsoft's Caller ID for E-Mail, and Yahoo's DomainKeys -- take different approaches. SPF, like RMX, focuses on the "envelope sender." That's the MAIL FROM address asserted by the sending host during setup of an SMTP connection, not the From: header contained in the body of the message. In various legitimate cases including mailing lists, mobile messaging services, and forwarders, the domains of the two addresses can differ. A companion proposal called SRS (Sender Rewriting Scheme) describes how to modify headers in transit so that intermediaries aren't seen as forgers by SPF-aware hosts.

Though significantly complicated by SRS, the SPF approach is arguably a good first line of defense. It's admirably lightweight. If a message fails the envelope sender test, it can be rejected without receipt or inspection of its contents. But messages that pass this test can still easily forge the From: header in the message itself, and that's the address that mail clients display to users. So Caller ID digs into the message itself in search of a purported responsible address whose domain will be queried for authorization. When multiple identities are involved, as with forwarding, the Caller ID spec recommends that mail clients display the addresses of intermediaries as well as originators. But as with SPF, the authorization check applies only the party "most immediately responsible for the transmission of a message," not to the originator.