DomainKeys Identified Mail

From Wikipedia, the free encyclopedia

Jump to: navigation, search

DomainKeys Identified Mail (DKIM) is a method for E-mail authentication, allowing a person who receives email to verify that the message actually comes from the domain claimed in the message header. The need for this type of authentication arises because spam often has forged headers. For example, a spam message may claim in its "From:" header to be from sender@example.com, when in fact it is not from that address, and the spammer's goal is to convince the recipient to accept and to read the email. Because the email is not actually from the example.com domain, the recipient cannot have any effect by complaining to the system administrator for example.com. It also becomes difficult for recipients to establish whether to give good or bad reputations to various domains, and system administrators may have to deal with complaints about spam that appears to have originated from their systems, but didn't.

DKIM uses public-key cryptography to allow the sender to electronically sign legitimate emails in a way that can be verified by recipients. Prominent email service providers implementing DKIM (or its slightly different predecessor, DomainKeys) include Yahoo and Gmail. Any mail from these domains should carry a DKIM signature, and if the recipient knows this, it can discard mail that hasn't been signed or that has an invalid signature.

DKIM also guards against tampering with mail, offering almost end-to-end integrity from a signing to a verifying Mail transfer agent (MTA). In most cases the signing MTA acts on behalf of the sender by inserting a DKIM-Signature header, and the verifying MTA on behalf of the receiver, validating the signature by retrieving a sender's public key through the DNS.

The DomainKeys specification has adopted aspects of Identified Internet Mail to create an enhanced protocol called DomainKeys Identified Mail (DKIM). This merged specification is the basis for an IETF Working Group which has guided the specification towards becoming an IETF Proposed Standard.

Contents

[edit] Overview

DKIM (and its predecessor DomainKeys) is a method of e-mail authentication. Unlike some other methods, it offers almost end-to-end integrity from a signing to a verifying Mail Transfer Agent (MTA). In most cases the signing MTA acts on behalf of the sender, and the verifying MTA on behalf of the receiver. DomainKeys is specified in Historic RFC 4870, which is obsoleted by Standards Track RFC 4871, DomainKeys Identified Mail (DKIM) Signatures.

DKIM is independent of Simple Mail Transfer Protocol (SMTP) routing aspects in that it operates on the RFC 5322 message — i.e., the transported mail data, header and body — not the SMTP envelope defined in RFC 5321.

Note that DKIM does not directly prevent abusive behavior; rather, it allows abuse to be tracked and detected more easily. This ability to prevent some forgery also has benefits for recipients of e-mail as well as senders, and "DKIM awareness" is programmed into some e-mail software.

[edit] How it works

DKIM adds a header named "DKIM-Signature" that contains a digital signature of the contents (headers and body) of the mail message. The default parameters for the authentication mechanism are to use SHA-256 as the cryptographic hash and RSA as the public key encryption scheme, and encode the encrypted hash using Base64.

The receiving SMTP server then uses the name of the domain from which the mail originated, the string "_domainkey", and a selector from the header to perform a DNS lookup. The returned data includes the domain's public key. The receiver can then decrypt the hash value in the header field and at the same time recalculate the hash value for the mail message (headers and body) that was received. If the two values match, this cryptographically proves that the mail originated at the purported domain and has not been tampered with in transit.

[edit] Development

DomainKeys was designed by Mark Delany of Yahoo!. Many other people provided comments and wrote prototype implementations, including Russ Nelson of the qmail community, Eric Allman of sendmail, and John R. Levine of the ASRG.

DKIM was designed by the IETF DKIM Working Group, chaired by Barry Leiba and Stephen Farrell, with Eric Allman of sendmail, Jon Callas of PGP Corporation, Mark Delany and Miles Libbey of Yahoo!, and Jim Fenton and Michael Thomas of Cisco Systems attributed as primary authors.

DomainKeys is covered by U.S. patent 6,986,049  assigned to Yahoo!. Yahoo! released DomainKeys under a dual license scheme: the traditional corporate oriented royalty-free, nonexclusive, relicensable patent license which is designed to be friendly to open source and free software implementations, and under GPL 2.0 for the purpose of the DKIM IETF Working Group.

[edit] Advantages

 This section needs additional citations for verification. Please help improve this article by adding reliable references (ideally, using inline citations). Unsourced material may be challenged and removed. (July 2008)

There are three primary advantages of this system for e-mail recipients:

  • It allows the originating domain of an e-mail to be positively identified, allowing domain-based blacklists and whitelists to be more effective. This is also likely to make phishing attacks easier to detect.
  • It allows forged e-mail messages to be discarded on sight, either by end-user e-mail software (mail user agents), or by ISPs' mail transfer agents.
  • It allows abusive domain owners to be tracked more easily.

There are some incentives for mail senders to authenticate outgoing e-mail:

  • It allows a great reduction in abuse desk work for DKIM-enabled domains if e-mail receivers use the DKIM system to identify forged e-mail messages claiming to be from that domain.
  • The domain owner can then focus its abuse team energies on its own users who actually are making inappropriate use of that domain.

[edit] Use with spam filtering

Since DKIM is an authentication technology, it does not itself filter spam. However, widespread use of DKIM can prevent spammers from forging the source address of their messages, a technique they commonly employ today. If spammers are forced to show a correct source domain, then other filtering techniques can work more effectively. In particular, the source domain can feed into a collaborative reputation system to better identify spam. Conversely, DKIM can make it easier to identify mail that is known not to be spam and need not be filtered. If a receiving system has a whitelist of known good sending domains, either locally maintained or from third party certifiers, it can skip the filtering on signed mail from those domains, and perhaps filter the remaining mail more aggressively.

DKIM can be useful as an anti-phishing technology. Mailers in heavily phished domains can sign their mail to show that it is genuine. Recipients can take the absence of a signature on mail from those domains to be an indication that the mail is probably forged. The best way to determine the set of domains that merit this degree of scrutiny remains an open question; DKIM will likely have an optional feature called ADSP that lets authors that sign all their mail self-identify, but the effectiveness of this approach remains to be tested.

[edit] Compatibility

Because it is implemented using optional RFC 5322 headers and DNS records, DKIM is backwards-compatible with the existing e-mail infrastructure. In particular, it is transparent to existing e-mail systems with no DKIM support.

DKIM has also been designed to be compatible with other proposed extensions to the e-mail system, in particular to be compatible with SPF, the S/MIME e-mail standard and DNSSEC. It is also compatible with the OpenPGP standard.

[edit] Weaknesses

 This section does not cite any references or sources. Please help improve this article by adding citations to reliable sources (ideally, using inline citations). Unsourced material may be challenged and removed. (July 2008)

DKIM signatures do not encompass the message envelope, which holds the return-path and message recipients. A concern for any cryptographic solution would be message replay abuse, which bypasses techniques that currently limit the level of abuse from larger domains. Replay can be inferred by using per-message public keys, tracking the DNS queries for those keys and filtering out the high number of queries due to e-mail being sent to large mailing lists or malicious queries by bad actors. For a comparison of different methods also addressing this problem see e-mail authentication.

[edit] Content modification in-transit

One of the problems with DKIM is that if the message is significantly modified en route by a forwarding mechanism such as a list server, then the signature may no longer be valid and, if the domain specifies that all e-mail is signed, the message may be rejected. Also many central antivirus solutions add a footer that the email has been scanned and the date of the virus signature files used in the scan. Some free email servers also add advertisements at the bottom of the emails. (The solution is to whitelist e-mail from known forwarders, or for the forwarder to verify the signature, modify the e-mail, and resign the message with a Sender: header.) Many domains, however, say that only some of their e-mail is signed, and so a missing or broken signature can not always be used to reject e-mail. (The solution is to sign all your e-mail.) If the only modifications en-route involve the addition or modification of headers before the DKIM-Signature: header, the signature should remain valid; also the mechanism includes features that allow certain limited modifications to be made to headers and the message body without invalidating the signature.

Some suggest that this limitation could be addressed by combining DKIM with SPF, because SPF (which breaks when messages are forwarded) is immune to modifications of the e-mail data, and mailing lists typically use their own SMTP error address aka Return-Path. In short, SPF works without problems where DKIM might run into difficulties, and vice versa.

Mailing lists that add or change content also effectively invalidate DKIM signatures. Yahoo! suggested that the mailing list should re-sign the message itself under these circumstances, thus in effect taking responsibility for the message.

[edit] Protocol overhead

DKIM requires cryptographic checksums to be generated for each message sent through a mail server, which results in computational overhead not otherwise required for e-mail delivery.

[edit] See also

[edit] External links

Retrieved from "http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail"
Personal tools