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.
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.