DomainKeys: Proving and Protecting Email Sender Identity

大 | 中 | 小
[不指定 11/26/2004 14:10 | by liuxyon ]

[center]DomainKeys: Proving and Protecting Email Sender Identity[/center]

Email spoofing - the forging of another person's or company's email address to get users to trust and open a message - is one of the biggest challenges facing both the Internet community and anti-spam technologists today. Without sender authentication, verification, and traceability, email providers can never know for certain if a message is legitimate or forged and will therefore have to continually make educated guesses on behalf of their users on what to deliver, what to block, and what to quarantine, in the pursuit of the best possible user experience.

DomainKeys is a technology proposal that can bring black and white back to this decision process by giving email providers a mechanism for verifying both the domain of each email sender and the integrity of the messages sent (i.e,. that they were not altered during transit). And, once the domain can be verified, it can be compared to the domain used by the sender in the From: field of the message to detect forgeries. If it's a forgery, then it's spam or fraud, and it can be dropped without impact to the user. If it's not a forgery, then the domain is known, and a persistent reputation profile can be established for that sending domain that can be tied into anti-spam policy systems, shared between service providers, and even exposed to the user.

For well-known companies that commonly send transactional email to consumers, such as banks, utilities, and ecommerce services, the benefits of verification are more profound, as it can help them protect their users from "phishing attacks" - the fraudulent solicitation for account information, such as credit card numbers and passwords, by impersonating the domain and email content of a company to which users have entrusted the storage of these data. For these companies, protecting their users from fraud emails translates directly into user protection, user satisfaction, reduced customer care costs, and brand protection.

For consumers, such as Yahoo! Mail users or a grandparent accessing email through a small mid-western ISP, industry support for sender authentication technologies will mean that they can start trusting email again, and it can resume its role as one of the most powerful communication tools of our times.

Standardization and License Terms

Yahoo! Inc. (Yahoo!) is fully committed to making DomainKeys an open Internet standard and has accordingly submitted the DomainKeys framework as an Internet-Draft entitled "http://www.ietf.org/internet-drafts/draft-delany-d...">draft-delany-domainkeys-base-01.txt" for publication with the IETF (Internet Engineering Task Force). Yahoo! hopes that DomainKeys will advance through the IETF Internet standards process and ultimately be approved as an IETF Internet Standard. Meanwhile, Yahoo! has established license terms that apply to the DomainKeys Intellectual Property (Patents, Software and Trademark). The Yahoo! DomainKeys Patent License Agreement can be found here:

Yahoo! DomainKeys Patent License Agreement

In accordance with RFC2026, Yahoo! has also submitted the above license statement to the IETF as an IPR Disclosure. Have license feedback?

Reference Implementation

In addition to the Internet-Draft, Yahoo! is currently developing a reference implementation for DomainKeys that can be plugged into Message Transfer Agents (MTAs), such as qmail. An alpha version of this software has been released and is available at http://domainkeys.sourceforge.net/. Additionally, Yahoo! is working with Sendmail to develop a DomainKey implementation for their popular MTA (both the commercial and freeware versions). In fact, Sendmail, Inc. has released an open source implementation of the Yahoo! DomainKeys specification for testing on the Internet and is actively seeking participants and feedback for this Pilot Program.

How DomainKeys Works

DomainKeys Flow Diagram

How it Works - Sending Servers

There are two steps to signing an email with DomainKeys:
  1. Set up: The domain owner (typically the team running the email systems within a company or service provider) generates a public/private key pair to use for signing all outgoing messages (multiple key pairs are allowed). The public key is published in DNS, and the private key is made available to their DomainKey-enabled outbound email servers. This is step "A" in the diagram to the right.
  2. Signing: When each email is sent by an authorized end-user within the domain, the DomainKey-enabled email system automatically uses the stored private key to generate a digital signature of the message. This signature is then pre-pended as a header to the email, and the email is sent on to the target recipient's mail server. This is step "B" in the diagram to the right.

How it Works - Receiving Servers

There are three steps to verifying a signed email:
  1. Preparing: The DomainKeys-enabled receiving email system extracts the signature and claimed From: domain from the email headers and fetches the public key from DNS for the claimed From: domain. This is step "C" in the diagram to the right.
  2. Verifying: The public key from DNS is then used by the receiving mail system to verify that the signature was generated by the matching private key. This proves that the email was truly sent by, and with the permission of, the claimed sending From: domain and that its headers and content weren't altered during transfer.
  3. Delivering: The receiving email system applies local policies based on the results of the signature test. If the domain is verified and other anti-spam tests don't catch it, the email can be delivered to the user's inbox. If the signature fails to verify, or there isn't one, the email can be dropped, flagged, or quarantined. This is step "D" in the diagram on the right.
In general, Yahoo! expects that DomainKeys will be verified by the receiving email servers. However, end-user mail clients could also be modified to verify signatures and take action on the results.

Frequently Asked Questions

How will this help stop spam?

Several ways. First, it can allow receiving companies to drop or quarantine unsigned email that comes from domains that are known to always sign their emails with DomainKeys, thus impacting spam and phishing attacks. Second, the ability to verify sender domain will allow email service providers to begin to build reputation databases that can be shared with the community and also applied to spam policy. For example, one ISP could share their "spam vs. legit email ratio" for the domain www.example.com with other ISPs that may not yet have built up information about the credibility and "spamminess" of email coming from www.example.com. Last, by eliminating forged From: addresses, we can bring server-level traceability back to email (not user-level - we believe that should be a policy of the provider and the choice of the user). Spammers don't want to be traced, so they will be forced to only spam companies that aren't using verification solutions.

Back to Questions

How will this help stop fraud/phishing attacks?

Companies that are susceptible to phishing attacks can sign all of their outgoing emails with DomainKeys and then tell the world this policy so that email service providers can watch and drop any messages that claim to come from their domain that are unsigned. For example, if the company www.example.com signs all of its outgoing email with DomainKeys, Yahoo! can add a filter to its SpamGuard system that drops any unsigned or improperly signed messages claiming to come from the domain www.example.com, thus protecting tens of millions of example.com's customers or prospective customers from these phishing attacks.

Back to Questions

Won't spammers just sign their messages with DomainKeys?

Hopefully! If they do, they'll make it easier for the Internet community to isolate and drop/quarantine their messages using the methods described above in "How will this help stop spam?" Eliminating the uncertainty of "did this email really come from the domain example.com?" will facilitate a whole range of anti-spam solutions.

Back to Questions

What does DomainKeys verify?

DomainKeys examines the From: and Sender: headers' domain to protect the user and deliver the best possible user experience. Desktop mail clients like Microsoft Outlook show these headers in their user interfaces. If the user establishes their trust based on the these domains, then so should any system built to verify whether that trust is warranted.

Back to Questions

Why sign the entire message?

DomainKeys signs the entire message to allow the receiving server to also verify that the message wasn't tampered with or altered in transit. By signing the headers and the body, DomainKeys makes it impossible to reuse parts of a message from a trusted source to fool users into believing the email is from that source.

Back to Questions

Does DomainKeys encrypt each message?

DomainKeys does not encrypt the actual message - it only pre-pends a "digital signature" as a header.

Back to Questions

What public/private key technology is used for DomainKeys?

DomainKeys currently uses an RSA public/private key method. The key length is decided by the domain owner.

Back to Questions

Who issues the public/private key pairs required by DomainKeys?

The domain owner, or an agent or service provider acting on their behalf, should generate the key pairs that are used for their DomainKeys-enabled mail system.

Back to Questions

Does DomainKeys require signing of the public key by a Certificate Authority (CA)?

DomainKeys does not require a CA. Much like a trusted Notary Public, Certificate Authorities are used in public/private key systems to sign, or "endorse," public keys so that the external users of public keys can know that the public keys they receive are truly owned by the people who sent them. Since DomainKeys leverages DNS as the public key distribution system, and since only a domain owner can publish to their DNS, external users of DomainKeys know that the public key they pull is truly for that domain. The CA is not needed to verify the owner of the public key - the presence in that domain's DNS is the verification. However, it is possible that Certificate Authorities may become a valuable addition to the DomainKeys solution to add an even greater level of security and trust.

Back to Questions

How are DomainKeys revoked?

DomainKeys allows for multiple public keys to be published in DNS at the same time. This allows companies to use different key pairs for the various mail servers they run and also to easily revoke, replace, or expire keys at their convenience. Thus, the domain owner may revoke a public key and shift to signing with a new pair at any time.

Back to Questions

Why not just use S/MIME?

S/MIME was developed for user-to-user message signing and encryption and by design should be independent of the sending and receiving servers. We believe that DomainKeys should be a natural server-to-server complement to S/MIME and not a replacement. Additionally, since S/MIME is used by many security-conscious industries, we need to ensure that the two technologies can work together without breaking each other. Finally, S/MIME is not yet supported by many of the email services, client software, and server software used across the Internet, and in Yahoo!'s opinion, that standardization effort would be much more difficult than the standardization of DomainKeys.

Back to Questions

How does DomainKeys work with mailing lists?

Mailing lists that do not change the content or re-arrange or append headers will be DomainKey compatible with no changes required. Mailing lists that change the message and headers should re-sign the message with their own private key and claim authorship of the message.

Back to Questions

Who implements DomainKeys?

DomainKeys will typically be implemented/enabled by the team within a company, ISP, or email service provider that deploys and runs the incoming and outgoing mail servers. Some companies may have service providers that handle their email. As MTA vendors add support for DomainKeys to their products, the implementation of DomainKeys will become simpler.

Back to Questions

Which mail transfer agents (MTAs) support DomainKeys?

Sendmail has released a milter implementation for both the commercial and freeware versions of their MTA. A Qmail patch is available, as well as a qpsmtpd plugin. CERN, the creators of the WWW has released a C# library for use in MS Exchange 2003. Port 25's PowerMTA, Etype.net's acSMTP, ActivSoftware's XMServer, OmniTI's Ecelerity, and StrongMail all have DomainKey versions of their software. Finally, Yahoo! has released an open source reference implementation for DomainKeys that can be plugged into other MTAs.

Back to Questions

How do I deploy DomainKeys?

After installing a DomainKey aware MTA, there are several key distribution options from which to choose. Once chosen, the public key portion should be published to your domain's _domainkey subdomain's TXT record, and the private key inserted into your MTA. You can test your DNS record policy and selector, and there are several autoresponding email addresses to test your implementations.

I don't use my domain's SMTP server to send email. How do I use DomainKeys?

DomainKeys relies on the domain administrator to authorize the use of the domain in an email. If you can not use the domain's authorized SMTP server because of port 25 blocking, you have a number of options.

  • You should encourage your domain to accept submission services on port 587. Your domain administrator should try to control authorization of the domain. Giving users a path to submit mail will help do this. Yahoo! Mail recently began offering a submission server on port 587.
  • You may be able to convince the domain administrator to grant you a user specific key. With a DomainKey, it should be possible to sign your messages using your mail client or any submission server. In fact, you could ask your submission service if you could give them a private key to use to sign your domain's mail.
  • You could consider using other headers to convey your identity. For instance, the Reply-to: header allows a recipient's mail client to choose an address to which replies should be sent. The Sender: header defines the address that injects the message into the SMTP stream. You might consider sending your message From: your domain, with the Sender: header set to the address of your submission service. Be aware however, that this strategy may be viewed suspiciously by anti-spam filters, as it may become a tactic for spammers and phishers.
  • Finally, you could chose to send unauthenticated mail. While this will not be a good long term strategy, it will certainly take quite a while before the vast majority of Internet email is authenticated. If you choose this path, you should carefully monitor the amount of authenticated mail over time to ensure that this strategy does not impact the deliverability of your email.
Back to Questions

How can I send you feedback?

Yahoo! welcomes your feedback on DomainKeys. You agree that Yahoo! shall own and have the right to use, without attribution or compensation to you, all feedback received by Yahoo!, in any form, to improve or modify DomainKeys or otherwise. Please use this email form to submit your comments. Note that due to the volume of emails we receive, it is unlikely that we'll be able to respond to your individual emails.

http://antispam.yahoo.com/domainkeys

我写一些, 更详细的去看技术资料.

draft-delany-domainkeys-base-01.rtf up/1103186663.rtf

Delany                    Expires February, 2005                      [Page 9]

Internet-Draft            DomainKeys                               August 2004


most visible to the recipient.

In the first instance, the most visible address is clearly the RFC2822
"From:" address [RFC2822]. Therefore, a conforming email MUST contain
a single "From:" header from which an email address with a domain name
can be extracted.

A conforming email MAY contain a single RFC2822 "Sender:" header from
which an email address with a domain name can be extracted.

If the email has a valid "From:" and a valid "Sender:" header, then
the signer MUST use the sending address in the "Sender:" header.

If the email has a valid "From:" and no "Sender:" header, then the
signer MUST use the first sending address in the "From:" header.

In all other cases, a signer MUST NOT sign the email. Implementors
should note the an email with a "Sender:" header and no "From:" header
MUST NOT be signed.

The domain name in the sending address constitutes the "sending
domain".


3.2 Retrieving the public-key given the sending domain

To avoid namespace conflicts, it is proposed that the DNS namespace
"_domainkey." be reserved within the sending domain for storing
public-keys, e.g., if the sending domain is example.net, then the
public-keys for that domain are stored in the _domainkey.example.net
namespace.


3.2.1 Introducing "selectors"

To support multiple concurrent public-keys per sending domain, the DNS
namespace is further subdivided with "selectors". Selectors are
arbitrary names below the "_domainkey." namespace. A selector value
and length MUST be legal in the DNS namespace and in email headers
with the additional provision that they cannot contain a semicolon.

Examples of namespace using selectors are:

    "sanfrancisco._domainkey.example.net"
    "coolumbeach._domainkey.example.net"
    "reykjavik._domainkey.example.net"
    "default._domainkey.example.net"

and

    "january2004._domainkey.example.net"



Delany                    Expires February, 2005                     [Page 10]

Internet-Draft            DomainKeys                               August 2004


    "february2004._domainkey.example.net"
    "march2004._domainkey.example.net"

Periods are allowed in selectors and are to be treated as component
separators. In the case of DNS queries that means the period defines
sub-domain boundaries.

The number of public-keys and corresponding selectors for each domain
are determined by the domain owner. Many domain owners will be
satisfied with just one selector whereas administratively distributed
organizations may choose to manage disparate selectors and key pairs
in different regions or on different email servers.

Beyond administrative convenience, selectors make it possible to
seamlessly replace public-keys on a routine basis. If a domain wishes
to change from using a public-key associated with selector "january"
to a public-key associated with selector "february", it merely makes
sure that both public-keys are advertised in the DNS concurrently for
the transition period during which email may be in transit prior to
verification. At the start of the transition period, the outbound
email servers are configured to sign with the "february"
private-key. At the end of the transition period, the "january"
public-key is removed from the DNS.

While some domains may wish to make selector values well known, others
will want to take care not to allocate selector names in a way that
allows harvesting of data by outside parties. E.g., if per-user keys
are issued, the domain owner will need to make the decision as to
whether to make this selector associated directly with the user name,
or make it some unassociated random value, such as the fingerprint of
the public-key.


3.2.2 Public-key signing and verification algorithm

The default signature is an RSA signed SHA1 digest of the complete
email.

For ease of explanation, the openssl command is used throughout this
document to describe the mechanism by which keys and signatures are
managed.

One way to generate a 768 bit private-key suitable for DomainKeys, is
to use openssl like this:

$ openssl genrsa -out rsa.private 768

Which results in the file rsa.private containing the key information
similar to this:

-----BEGIN RSA PRIVATE KEY-----



Delany                    Expires February, 2005                     [Page 11]

Internet-Draft            DomainKeys                               August 2004


MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5
ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo
AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH
+Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn
Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/
3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew
ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs
FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb
weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG
6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U=
-----END RSA PRIVATE KEY-----

Once a private-key has been generated, the openssl command can be used
to sign an appropriately prepared email, like this:

$ openssl dgst -sign rsa.private -sha1 <input.file

Which results in signature data similar to this when represented in
Base64 [MIME] format:

aoiDeX42BB/gP4ScqTdIQJcpAObYr+54yvctqc4rSEFYby9+omKD3pJ/TVxATeTz
msybuW3WZiamb+mvn7f3rhmnozHJ0yORQbnn4qJQhPbbPbWEQKW09AMJbyz/0lsl

How this signature is added to the email is discussed later in this
document.


To extract the public-key component from the private-key, use openssl
like this:

$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

Which results in the file rsa.public containing the key information
similar to this:

-----BEGIN PUBLIC KEY-----
MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l
MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E
XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
-----END PUBLIC KEY-----


This public-key data is placed in the DNS.


With the signature, canonical email contents and public-key, a
verifying system can test the validity of the signature. The openssl
invocation to verify a signature looks like this:

openssl dgst -verify rsa.public -sha1 -signature signature.file <input.file




Delany                    Expires February, 2005                     [Page 12]

Internet-Draft            DomainKeys                               August 2004




3.2.3 Public-key representation in the DNS

There is currently no standard method defined for storing public-keys
in the DNS. As an interim measure, the public-key is stored as a TXT
record derived from a PEM format [PEM], that is, as a Base64
representation of a DER encoded key. Here is an example of a 768 bit
RSA key in PEM form:

-----BEGIN PUBLIC KEY-----
MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l
MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E
XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
-----END PUBLIC KEY-----

To save scarce DNS packet space and aid extensibility, the PEM
wrapping MUST be removed and the remaining public-key data along with
other attributes relevant to DomainKeys functionality are stored as
tag=value pairs separated by semicolons, e.g.:

brisbane._domainkey IN TXT "g=; k=rsa; p=MHww ... IDAQAB"

Verifiers MUST support key sizes of 512, 768, 1024, 1536 and 2048
bits. Signers MUST support at least one of the verifier supported key
sizes.

The current valid tags are:

    g = granularity of the key. If present with a non-zero length
        value, this value MUST exactly match the local part of the
        sending address. This tag is optional.

        The intent of this tag is to constrain which sending address
        can legitimately use this selector. An email with a sending
        address that does not match the value of this tag constitutes
        a failed verification.

    k = key type (rsa is the default). Signers and verifiers MUST
        support the 'rsa' key type.

    n = Notes that may be of interest to a human. No interpretation is
        made by any program. This tag is optional.

    p = public-key data, encoded as a Base64 string. An empty value
        means that this public-key has been revoked. This tag MUST be
        present.

    t = testing mode ('y' means that this domain is testing DomainKeys
        and unverified email MUST NOT be treated differently from
        verified email. Recipient systems MAY wish to track testing

Technology | 评论(0) | 引用(123) | 阅读(1381)