DomainKeys
From Wikipedia, the free encyclopedia
DomainKeys is an e-mail authentication system designed to verify the DNS domain of an e-mail sender and the message integrity. 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 guided the specification toward becoming an IETF standard.
The DKIM standard was issued in May 2007. The DomainKeys draft was also issued under "historical" status at the same time.
Contents |
[edit] Overview
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.
DomainKeys is independent of Simple Mail Transfer Protocol (SMTP) routing aspects in that it operates on the RFC 2822 message — i.e., the transported mail data, header and body — not the SMTP envelope defined in RFC 2821.
Note that DomainKeys 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 "DomainKey awareness" is programmed into some e-mail software.
Since 2004, Yahoo! has signed all of its outgoing e-mail with DomainKeys and is verifying all incoming mail. As of 2005, Yahoo reports that the number of DomainKeys-verified e-mail messages they receive exceeds 300 million per day.
Google also uses DomainKeys to sign e-mail messages sent from users of its Gmail service, actually going live with it about a month before Yahoo did.[1]
[edit] How it works
DomainKeys adds a header named "DomainKey-Signature" that contains a digital signature of the contents of the mail message. The default parameters for the authentication mechanism are to use SHA-1 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 body that was received, from the point immediately following the "DomainKey-Signature:" header. 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.
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
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 DomainKeys-enabled domains if e-mail receivers use the DomainKeys system to automatically drop forged e-mail messages claiming to be from that domain.
- The domain owner can then focus their abuse team energies on their own users who actually are abusing their use of that domain.
[edit] Use with spam filtering
Since DomainKeys is an authentication technology, it does not itself filter spam. However, widespread use of DomainKeys 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, DomainKeys 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.
DK 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; DK's successor 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 2822 headers and DNS records, DomainKeys is backwards-compatible with the existing e-mail infrastructure. In particular, it is transparent to existing e-mail systems with no DomainKeys support.
DomainKeys 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
DomainKeys or 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 DomainKeys 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 signature files. 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 DomainKey-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 DomainKeys with SPF, because SPF 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 DomainKeys might run into difficulties, and vice versa.
Mailing Lists that add or change content also effectively invalidate DomainKeys 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
DomainKeys 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
- DomainKeys Identified Mail (DKIM)
- Author Domain Signing Practises
- Sender Policy Framework (SPF)
- E-mail authentication
[edit] External links
- RFC 4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)
- RFC 4871 DomainKeys Identified Mail (DKIM) Signatures
- DKIM.org DKIM resources website: implementations, FAQ, news
- IETF DKIM working group (started 2006)
- Yahoo!'s description of DomainKeys
- Yahoo!'s statement about IPR claimed in DKIM draft
- Yahoo!'s free software reference implementation of DomainKeys
- U.S. Patent 6,986,049
- SpamCop FAQ entry about bogus bounces also discusses DomainKeys
