DomainKeys
Yahoo!
DomainKeys
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 plans to guide the specification towards
becoming an IETF standard.
Overview
DomainKeys is a method for
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 independent of
Simple Mail Transfer Protocol (SMTP) routing aspects, it operates on the
RFC 2822 message, the transported mail data, header and body, not the SMTP
envelope defined in
RFC 2821.
Note that DomainKeys does not prevent abusive behavior; rather, it allows it
to be tracked and detected more easily. This ability to prevent some forgery
also has benefits for recipients of E-mails 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 they receive
exceeds 300 million messages per day.
Google also uses DomainKeys to sign emails sent from users of its Gmail
service; actually going live with it about a month before Yahoo! did. The ISP
EarthLink also uses DomainKeys.
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 that 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 did in fact originate at the
purported domain, and has not been tampered with in transit.
Development
DomainKeys was designed by Mark Delany of
Yahoo!. Many
other people including
Russ Nelson of qmail, Eric Allman of sendmail, and John R. Levine of the ASRG provided
comments and wrote prototype implementations.
DomainKeys is covered by
U.S. Patent 6,986,049 assigned to Yahoo!. Yahoo! have 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.
Identified Internet Mail, on which DKIM was also based, was proposed by Jim
Fenton and Michael Thomas of Cisco.
Advantages
There are three primary advantages of this system for the domain owner:
- 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 more easy to detect.
- It allows forged E-mails 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 other E-mail users to be able to verify
DomainKey information:
- 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-mails 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.
Use with spam filtering
With DomainKeys, the absence of a verifiable digital signature header in an
E-mail purporting to be from a domain which has a DomainKeys DNS record may
indicate that that E-mail is a forgery. Thus, E-mails may be divided into three
classes:
- valid DomainKey signature: authentic
- invalid or missing DomainKey signature for a domain with the DNS record:
usually forged
- no DNS record or header: unknown status
These values can be used as input to more general
spam
filtering algorithms.
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.
Disadvantages
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. For a comparison of different
methods addressing also this problem see
E-mail authentication.
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 the message may be rejected. 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.
Protocol overhead
DomainKeys requires cryptographic checksums to be generated for each message
sent through a mail server, which results in computational overhead not usually
required for e-mail delivery. Until recently, this would have been a serious
problem. However, as of 2004
computer processors are now fast enough that the cryptographic overhead
represents only around 10% of the overall mail-handling load for a typical
system.
External links
Home
Up
Buzz Log
DomainKeys
Rollyo
Yahoo! 360º
Yahoo! Calendar
Yahoo! Directory
Yahoo! Fantasy Sports
Yahoo! Games
Yahoo! Groups
Yahoo! HotJobs
Yahoo! Mail
Yahoo! Messenger
Yahoo! News
Yahoo! Personals
Yahoo! Search
Yahoo! Slurp
Yahooligans!
|