Solutions are in the works to help curb the amount of junk email we receive. Currently, most people probably use one of three types of solutions (or combinations thereof) to help filter their email. These solutions process incoming mail according to approved senders, banned senders, and banned mail servers. Now three more solutions are making their way into the marketplace: Sender Policy Framework (SPF), Caller ID for E-Mail, and DomainKeys.
Meng Weng Wong and Mark Lentczner began working on SPF more than a year ago, and more than 7500 domain operators have already implemented the solution. AOL, one of the world's largest ISPs, has taken notice and is testing SPF.
SPF attempts to use DNS queries to verify email sender IP addresses. DNS publishes MX records for inbound mail servers for a given domain, but there is no record type for publishing a list of outbound mail servers for a given domain. To improvise, SPF uses specially formatted TXT records in DNS to publish outbound mail servers for public queries and subsequent attempts to authenticate email senders.
When an SPF-enabled mail system receives a message, the mail system can query the sender's domain DNS servers to obtain a list of valid outbound mail server addresses and compare these addresses with the IP address in the message's SMTP email headers. If the IP addresses match, the mail system can assume that the message isn't junk mail. If the addresses don't match, the mail system can take a variety of actions depending on how it's configured. You can learn more about SPF, including how to implement it, at http://spf.pobox.com .
Microsoft recently published the Caller ID for E-Mail specification, which is similar to SPF. Caller ID also works by using DNS TXT records; however, Caller ID uses TXT records written in XML. Like SPF, Caller ID checks IP addresses in SMTP email headers against outbound mail server IP addresses published by DNS servers to verify that a domain's authorized mail server sent a message. The differences between Caller ID and SPF are in the way mail headers are processed and the way DNS publishes outbound mail servers. You can learn more about Microsoft's proposed Caller ID for E-Mail system at http://www.microsoft.com/mscorp/twc/privacy/spam_callerid.mspx .
The third system, DomainKeys, is in development by Yahoo! and works by cryptographically signing messages at the server level. You're probably familiar with tools such as Pretty Good Privacy (PGP) that use a public key and private key. Data is encrypted or signed by using a private key; data is decrypted or a signature is verified by using a public key. DomainKeys works the same way but at the server level. A sending mail server uses a private key to sign all the messages it sends. A DNS record publishes the sending server's public key. When the target server receives a signed message, the server can use a DNS query to obtain the sending server's public key and use the key to verify the message signature.
SPF, Caller ID for E-Mail, and DomainKeys have at least one thing in common: They verify that mail came from a mail server in the domain used by the sender's email address. This sort of functionality will help curb spoofing and help eliminate some amount of junk mail, but it won't completely stop all junk mail. Nevertheless, support is growing for all three proposed systems.
The most widely used mail server software is Sendmail. I recently spoke with J.F. Sullivan, Sendmail's director of product marketing, who told me that the company is providing feedback to all three entities to help them develop their respective solutions. Sullivan said that sometime this summer, Sendmail will release a new version of Sendmail, 8.13.x, that will include mail filter (milter) support for both Caller ID for E-Mail and DomainKeys. The new milter support will be available in both the commercial and open source versions of the mail server. After Sendmail has built-in support, millions of servers could potentially implement Caller ID or DomainKeys or both. Sendmail is also considering implementing SPF but doesn't yet have a timeframe for doing so.
Before that point release of Sendmail becomes available, SPF, Caller ID, and DomainKeys developers have plenty of work to do. All three solutions require particular changes to the configuration of DNS and the architecture of various mail-processing systems. For example, in some instances, the solutions would break widely used tools such as various types of mailing list software because the solutions might rewrite certain SMTP mail headers, which could change mail server or mail client behavior during mail processing. Solution developers might need to come up with workarounds for these types of situations.
The good news is that none of the proposed solutions will place drastic requirements on email end users because the solutions work at the server level. However, we might wonder about server interoperability because not everyone will wind up using the same solution.
Be sure to read about each of the solutions as they stand now, and keep an eye on their progress. Doing so could give you a head start on planning your future mail services.
