Two recently developed protocols, Domain Keys Identified Mail (DKIM) and Sender Policy Framework (SPF), provide tools to protect service providers and their customers from e-mail fraud attempts.
 |
|
|
|
|
Customer requirements may make it necessary to deploy DKIM and/or SPF for sent mail.
David Jacobs
The Jacobs Group
|
|
|
|
|
|
|
|
|
|
The goal of both protocols is to reduce spam by providing a way for legitimate e-mail senders to provide a clear indication of the actual source of mail. DKIM and SPF provide methods to verify the identity of the sender.
DKIM is specified by RFC 4871 and SPF by RFC 4408. See DKIM.org and the Sender Policy Framework Project Overview for more information. DKIM and SPF can each be used alone, or both protocols can be used together.
The primary goal of both protocols is to eliminate phishing. Using the protocols, anyone sending e-mail, such as a bank, can securely identify mail it sends. Any mail purporting to come from that bank but not using the protocols is clearly fraudulent and can be filtered out by anti-spam products.
DKIM protects against falsification of the "From" address specified in the RFC 2822 message header. This is the source address normally displayed by a receiving e-mail client. Public key encryption is used to sign a hash of the entire mail message, including the source address and the contents of the message.
The receiving server accesses DNS and uses the sender's public key to decode the hash. The receiver computes the hash of the received message and compares it to the decoded hash. If the hashes match, the message did in fact come from the source address indicated. The hash is computed over the entire contents of the mail, so DKIM also guarantees that message contents have not been modified along the way.
SPF addresses the case where the return address in the RFC 2821 SMTP envelope is falsified. A sender implementing SPF creates DNS records specifying the IP addresses of all the systems within the sender domain that legitimately send mail.
The receiver of the mail accesses the DNS entry of the purported sending domain. If the IP address from which the mail came does not match one of the legitimate e-mail senders, the mail did not actually come from the indicated domain.
Ongoing work to stop fraudulent mail
Mechanisms to identify fraudulent mail are not sufficient. Many bulk e-mailers, especially financial institutions, have committed to use one, and in some cases, both protocols. But the protocols will not be immediately universally adopted. Receiving sites must have a way to determine whether the indicated sending domain is using the protocols.
Work is currently underway on Author Signing Practices (ASP). A sender uses ASP to specify in its DNS entry whether DKIM is used and whether it is used on all mail from that sender. Receiving sites check the sender's DNS entry to determine whether mail received from the site should be signed. ASP is defined in draft RFC draft-ietf-dkim-ssp-03.
Similarly, receiving sites determine from the sender's DNS entry whether site is using SPF. If so, the sender has listed the addresses of all of its servers that send mail. If such a list is present, the sender is using SPF, and the receiving server must check that the mail came from one of one of the listed servers.
Service provider requirements
The Financial Services Roundtable, an organization of the nation's largest financial institutions, has pledged to adopt DKIM and SPF by October of this year. When they have done so, customers will expect their service providers to follow suit.
Bringing the benefit of these advances to customers will require service providers to do the following:
- Deploy updated software in both the incoming and outgoing mail paths. In some cases, it may be necessary to upgrade servers or hardware e-mail appliances to cope with increased processing load.
- Work with customers that maintain their own e-mail servers to utilize the new protocols.
- Educate all customers on the capabilities and limitations of the new protocols.
Service providers must upgrade software to implement these protocols to examine received mail. ASP must be added later this year when the standard is finalized. Early adopters have not experienced significant increased load from the additional DNS references, but the incremental processing required by public key encryption may require upgrades to servers or e-mail appliances.
Customer requirements may make it necessary to deploy DKIM and/or SPF for sent mail. If DKIM is required, public key certificates must be obtained and the necessary software added to sign outgoing mail.
Customer e-mail security requirements
Service providers must assist their customers who maintain their own e-mail servers. Customers will need help understanding the requirements, adding the software, and those intending to sign mail with DKIM may need help obtaining a public key certificate.
Both DKIM and SPF are aimed primarily at eliminating phishing. They will not eliminate all spam or eliminate all fraud attempts. Not all legitimate e-mail will use the protocols, so anti-spam products cannot filter out mail that isn't using them.
More confusing, e-mail using the protocols is not necessarily legitimate. Those who send out mail claiming to need help retrieving a large fortune from a foreign bank can use the protocols. Both DKIM and SPF verify the identity of the sender, but say nothing about the content of the message.
DKIM and SPF do not promise to be the ultimate spam solution; they are simply two more tools that can reduce spam and the amount lost due to fraudulent e-mail.
About the author: David B. Jacobs of The Jacobs Group has more than 20 years of networking industry experience. He has managed leading-edge software development projects and consulted with Fortune 500 companies, as well as software start-ups.
