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.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld DOWNLOAD PDF Click here to download InfoWorld's special report Can e-mail be saved?

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.

DomainKeys focuses squarely on the From: header that purports to identify the author of the message. The domain owner responsible for the address in that header stores a public key in a DNS record and issues the corresponding private key to its outbound mail servers so they can sign outgoing messages. A receiving host looks up the public key in the DNS and uses it to verify signatures on inbound messages.

Of the three schemes, Sendmail CTO Eric Allman favors DomainKeys because it's the only one that doesn't "break e-mail's fundamental store-and-forward model." A signed message that travels through a forwarder can still be verified by the receiver with respect to the originating sender's domain. Since intermediaries sometimes rearrange headers, however the DomainKeys architects are currently having a lively debate about which headers to sign along with the message body.

One of those architects is the prolific open source developer Russell Nelson. He sees DomainKeys as a near-term fix with long-term growth potential. If corporate keys can be woven

into the DNS fabric, it might be possible -- using a Domain-Keys feature called selectors -- to extend support for individual keys as well.

But first things first. We'll soon find out whether any of these schemes -- or some combination of them -- will prove workable. If you run an e-mail system, you can best prepare for the anti-forgery experiments about to unfold by ensuring that your home and mobile users can securely contact the hosts you'd like to authorize. Now's the time to stop procrastinating about the virtual private network, and/or enable secure connections to your outbound mail hosts.