A Question of Legitimacy
VARs who offer configuration and management services for their clients' e-mail needs are finding out that life isn't so easy anymore. A bombardment of spam, increasing viral attacks and other forms of forged messages have made e-mail a bigger job to operate and manage.
One bright ray of hope in this mess is a new series of sender-authorization technologies, with a dozen or so technologies currently being pitched. However, three proposals in particular have captured the industry's attention: Microsoft's Caller-ID, the community-driven Sender Policy Framework (SPF) and Yahoo's DomainKeys. Before we get to their differences, let's first describe why they are needed. The exploit most commonly used for malfeasant e-mail stems from the way the Simple Message Transfer Protocol (SMTP) allows anybody to claim to be anybody else whenever a message is sent, with recipients having no easy way of determining whether the sender is actually who he claims to be. This weakness is often exploited by spammers and virus writers to help camouflage their trash and is also commonly used to commit outright fraud, such as with e-mail messages that pretend to be from a bank or commerce site, but which direct the recipient to a hostile site.
Clearly, what is needed to prevent those types of abuses is for a recipient to be able to determine whether the sender of a particular e-mail is authorized to send a message on behalf of the purported sender. That is also the principal objective of the efforts described here; by allowing organizations to publicly declare the networks and hosts that are authorized to send e-mail messages on behalf of their domains, those organizations can reduce the fraudulent use of their property, and recipients can also use that same information to detect and eliminate obvious junk more efficiently. These same areas are also opportunities for VARs who offer antispam or other kinds of e-mail-configuration services.
Microsoft's Caller-ID
Microsoft's Caller-ID system is part of the company's multipronged "Coordinated Spam Reduction Initiative," which includes sibling technologies for policy statements, certificate systems, payment schemes and so forth. The Caller-ID technology, in particular, is merely the first of these to be publicly described in a form that is suitable for implementation. And while Microsoft should be applauded for both its comprehensive approach to the spam problem and for pursuing a sender-authorization tactic within that strategy, there is much to dislike about the technology.
Specifically, the Caller-ID model uses full-fledged XML documents to describe sender policy, with these documents being published in TXT resource records within the Domain Name System (DNS). However, storing this kind of data in DNS is not an acceptable practice because DNS is optimized for small and fast transactions, while the XML documents that Microsoft uses are very large. As a result, the typical lookup for Caller-ID records will fail, and this failure will be nonrecoverable in several common scenarios.
Furthermore, Microsoft is also claiming intellectual-property rights over some parts of the Caller-ID technology, going so far as to include a licensing agreement along with the protocol documentation. That raises the bar against adoption among a broad array of players in the e-mail space, including software vendors and end users alike. At this particular moment, Microsoft is committed to building the Caller-ID technology into the next version of its Exchange server product line, and it is also working with Sendmail to incorporate the technology into the latter's widely used transfer software. Hotmail is also currently publishing Caller-ID records on an experimental basis. But beyond that, very few others have publicly committed to its adoption.
Sender Policy Framework
SPF uses a similar model as Microsoft's Caller-ID, but it does not carry the same baggage. For example, SPF entries are also currently published in TXT records, but they require only a single line of data (as opposed to an entire XML document), meaning that the policy data can usually be retrieved in a single lookup transaction. Furthermore, SPF is being developed in an open-source environment, has been published as an Internet Draft and is much more transparent from a property-rights perspective.
While SPF does not have the formal endorsement from major vendors that some of the other technologies enjoy, there are free implementations available for most of the common mail-transfer products—there is even an open-source Exchange application under development—and a free perl module available for sites running unsupported mail servers. There also are several thousand domains that have publicly declared they are publishing SPF records, including heavy hitters like America Online and pobox. All things considered, SPF has the most momentum, has the least amount of baggage and is, therefore, the most useful today, although the lack of official endorsements from big-name software providers may be discomforting to some VARs.
Of note, a few weeks ago preliminary steps were taken to merge the SPF and Caller-ID technologies into a unified Sender-ID technology, although it's too early to tell if this effort will produce a specification that both camps will support.
Yahoo's DomainKeys
The third significant sender-identification proposal is Yahoo's DomainKeys technology, though this proposal is also the least developed. According to the limited amount of information that has been made available, DomainKeys centers on public-key encryption mechanisms as a way to guarantee a particular mail message originated at a particular source. In this model, the mail servers associated with the domain will sign each message they transmit, storing the signature into a header field of the outgoing messages.
Meanwhile, the public keys associated with that domain will be stored in DNS, where they can be retrieved by recipient systems and subsequently used to decrypt the signature. Messages with valid signatures can then be processed with confidence, while messages with invalid signatures can be discarded as known forgeries.
Although this proposal offers the best hope for irrefutable proof of authorization, it is also the most radical and requires the most ongoing administration.
Rough Spots
While sender-authorization technologies can be useful toward the prevention of certain forgery-related e-mail attacks, they are most helpful as part of a broad array of technologies. For example, a legitimate message from an authorized sender can still contain a virus and can still be unsolicited commercial mail, so content-analysis technologies are going to be required to build a solid line of defense. Just because the e-mail has been authorized doesn't mean the content is desirable.
Meanwhile, organizations also need to be careful not to rely too heavily on sender-authorization technologies for definitive answers. For example, some Web sites allow users to send e-mail messages via that site, such as a greeting-card site that lets users send e-mail cards to mom or news sites that allow the user to forward an article to a friend. If those sites are not listed as authorized senders for the user's e-mail address, then mom might not get the card and your friend might not get that article.
For these reasons, organizations still need to embrace comprehensive toolsets, with sender-authorization technologies taking their rightful places as one of the most powerful tools in that set. From that perspective, VARs who offer e-mail configuration and management services should definitely keep an eye on sender-authorization technologies—and well-managed sites can even go ahead and implement SPF today—but do not expect this or any other technology to provide the single silver bullet.
Copyright © 2010-2017 Eric A. Hall.
Portions copyright © 2004 CMP Media, Inc. Used with permission.