draft-ietf-dkim-deployment-03.txt   draft-ietf-dkim-deployment-04.txt 
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Informational E. Siegel Intended status: Informational E. Siegel
Expires: August 13, 2009 Constant Contact, Inc. Expires: September 10, 2009 Constant Contact, Inc.
P. Hallam-Baker P. Hallam-Baker
VeriSign Inc. VeriSign Inc.
D. Crocker D. Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
February 9, 2009 March 9, 2009
DomainKeys Identified Mail (DKIM) Development, Deployment and Operations DomainKeys Identified Mail (DKIM) Development, Deployment and Operations
draft-ietf-dkim-deployment-03 draft-ietf-dkim-deployment-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
DomainKeys Identified Mail (DKIM) allows an organization to claim DomainKeys Identified Mail (DKIM) allows an organization to claim
responsibility for transmitting a message, in a way that can be responsibility for transmitting a message, in a way that can be
validated by a recipient. The organization can be the author's, the validated by a recipient. The organization can be the author's, the
originating sending site, an intermediary, or one of their agents. A originating sending site, an intermediary, or one of their agents. A
message can contain multiple signatures, from the same or different message can contain multiple signatures, from the same or different
organizations involved with the message. DKIM defines a domain-level organizations involved with the message. DKIM defines a domain-level
digital signature authentication framework for email, using public digital signature authentication framework for email, using public
skipping to change at page 3, line 27 skipping to change at page 3, line 27
3.2. Storing Public Keys: DNS Server Software Considerations . 16 3.2. Storing Public Keys: DNS Server Software Considerations . 16
3.3. Per User Signing Key Management Issues . . . . . . . . . . 17 3.3. Per User Signing Key Management Issues . . . . . . . . . . 17
3.4. Third Party Signer Key Management and Selector 3.4. Third Party Signer Key Management and Selector
Administration . . . . . . . . . . . . . . . . . . . . . . 17 Administration . . . . . . . . . . . . . . . . . . . . . . 17
3.5. Key Pair / Selector Lifecycle Management . . . . . . . . . 18 3.5. Key Pair / Selector Lifecycle Management . . . . . . . . . 18
4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Signing Module . . . . . . . . . . . . . . . . . . . . . . 20 4.2. Signing Module . . . . . . . . . . . . . . . . . . . . . . 20
4.3. Signing Policies and Practices . . . . . . . . . . . . . . 20 4.3. Signing Policies and Practices . . . . . . . . . . . . . . 20
5. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Taxonomy of Signatures . . . . . . . . . . . . . . . . . . . . 21 5.1. Intended Scope of Use . . . . . . . . . . . . . . . . . . 21
6.1. Single Domain Signature . . . . . . . . . . . . . . . . . 21 5.2. Signature Scope . . . . . . . . . . . . . . . . . . . . . 21
6.2. Parent Domain Signature . . . . . . . . . . . . . . . . . 22 5.3. Design Scope of Use . . . . . . . . . . . . . . . . . . . 22
6.3. Third Party Signature . . . . . . . . . . . . . . . . . . 23 5.4. Inbound Mail Filtering . . . . . . . . . . . . . . . . . . 22
6.4. Using Trusted 3rd Party Senders . . . . . . . . . . . . . 24 5.5. Messages sent through Mailing Lists and other
6.5. Multiple Signatures . . . . . . . . . . . . . . . . . . . 25 Intermediaries . . . . . . . . . . . . . . . . . . . . . . 23
7. Example Usage Scenarios . . . . . . . . . . . . . . . . . . . 27 5.6. Generation, Transmission and Use of Results Headers . . . 23
7.1. Author's Organization - Simple . . . . . . . . . . . . . . 27 6. Taxonomy of Signatures . . . . . . . . . . . . . . . . . . . . 24
7.2. Author's Organization - Differentiated Types of Mail . . . 27 6.1. Single Domain Signature . . . . . . . . . . . . . . . . . 24
7.3. Author Signature . . . . . . . . . . . . . . . . . . . . . 27 6.2. Parent Domain Signature . . . . . . . . . . . . . . . . . 25
7.4. Author Domain Signing Practices . . . . . . . . . . . . . 28 6.3. Third Party Signature . . . . . . . . . . . . . . . . . . 25
7.5. Delegated Signing . . . . . . . . . . . . . . . . . . . . 28 6.4. Using Trusted 3rd Party Senders . . . . . . . . . . . . . 27
7.6. Independent Third Party Service Providers . . . . . . . . 28 6.5. Multiple Signatures . . . . . . . . . . . . . . . . . . . 28
7.7. Mail Streams Based on Behavioral Assessment . . . . . . . 29 7. Example Usage Scenarios . . . . . . . . . . . . . . . . . . . 30
7.8. Agent or Mediator Signatures . . . . . . . . . . . . . . . 29 7.1. Author's Organization - Simple . . . . . . . . . . . . . . 30
8. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 30 7.2. Author's Organization - Differentiated Types of Mail . . . 30
8.1. Non-standard Submission and Delivery Scenarios . . . . . . 30 7.3. Author Signature . . . . . . . . . . . . . . . . . . . . . 30
8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 31 7.4. Author Domain Signing Practices . . . . . . . . . . . . . 31
8.3. Signature Granularity . . . . . . . . . . . . . . . . . . 31 7.5. Delegated Signing . . . . . . . . . . . . . . . . . . . . 33
8.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 32 7.6. Independent Third Party Service Providers . . . . . . . . 33
8.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 34 7.7. Mail Streams Based on Behavioral Assessment . . . . . . . 34
9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 35 7.8. Agent or Mediator Signatures . . . . . . . . . . . . . . . 34
9.1. Security Considerations . . . . . . . . . . . . . . . . . 35 8. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 35
9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 35 8.1. Non-standard Submission and Delivery Scenarios . . . . . . 35
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 36
11. Informative References . . . . . . . . . . . . . . . . . . . . 35 8.3. Signature Granularity . . . . . . . . . . . . . . . . . . 36
Appendix A. Migrating from DomainKeys . . . . . . . . . . . . . . 37 8.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 37
A.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 39
A.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 40 9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 40
9.1. Security Considerations . . . . . . . . . . . . . . . . . 40
9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 40
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
11. Informative References . . . . . . . . . . . . . . . . . . . . 40
Appendix A. Migrating from DomainKeys . . . . . . . . . . . . . . 42
A.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 42
A.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 45
Appendix B. General Coding Criteria for Cryptographic Appendix B. General Coding Criteria for Cryptographic
Applications . . . . . . . . . . . . . . . . . . . . 41 Applications . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) allows an organization to claim DomainKeys Identified Mail (DKIM) allows an organization to claim
responsibility for transmitting a message, in a way that can be responsibility for transmitting a message, in a way that can be
validated by a recipient. This document provides practical tips for: validated by a recipient. This document provides practical tips for:
those who are developing DKIM software, mailing list managers, those who are developing DKIM software, mailing list managers,
filtering strategies based on the output from DKIM verification, and filtering strategies based on the output from DKIM verification, and
DNS servers; those who are deploying DKIM software, keys, mailing DNS servers; those who are deploying DKIM software, keys, mailing
list software, and migrating from DomainKeys; and those who are list software, and migrating from DomainKeys; and those who are
skipping to change at page 5, line 42 skipping to change at page 5, line 42
email service, to facilitate message handling decisions, such as for email service, to facilitate message handling decisions, such as for
delivery and for content display. Trust-oriented message handling delivery and for content display. Trust-oriented message handling
has substantial differences from approaches that consider messages in has substantial differences from approaches that consider messages in
terms of risk and abuse. With trust, there is a collaborative terms of risk and abuse. With trust, there is a collaborative
exchange between a willing participant along the sending path and a exchange between a willing participant along the sending path and a
willing participant at the recipient site. In contrast, the risk willing participant at the recipient site. In contrast, the risk
model entails independent action by the recipient site, in the face model entails independent action by the recipient site, in the face
of a potentially unknown, hostile and deceptive sender. This of a potentially unknown, hostile and deceptive sender. This
translates into a very basic technical difference: In the face of translates into a very basic technical difference: In the face of
unilateral action by the recipient and even antagonistic efforts by unilateral action by the recipient and even antagonistic efforts by
the sender, risk-oriented mechanisms must be based on heuristics, the sender, risk-oriented mechanisms will be based on heuristics,
that is, on guessing. Guessing produces statistical results with that is, on guessing. Guessing produces statistical results with
some false negatives and some false positives. For trust-based some false negatives and some false positives. For trust-based
exchanges, the goal is the deterministic exchange of information. exchanges, the goal is the deterministic exchange of information.
For DKIM, that information is the one identifier that represents a For DKIM, that information is the one identifier that represents a
stream of mail for which an independent assessment is sought (by the stream of mail for which an independent assessment is sought (by the
signer.) signer.)
A trust-based service is built upon a validated Responsible A trust-based service is built upon a validated Responsible
Identifier that labels a stream of mail and is controlled by an Identifier that labels a stream of mail and is controlled by an
identity (role, person or organization.) The identity is identity (role, person or organization.) The identity is
skipping to change at page 15, line 8 skipping to change at page 15, line 8
Ideally we would like to draw a stronger conclusion, that if we Ideally we would like to draw a stronger conclusion, that if we
obtain a DKIM key record from the DNS zone example.com, that the obtain a DKIM key record from the DNS zone example.com, that the
legitimate holder of the DNS zone example.com claims responsibility legitimate holder of the DNS zone example.com claims responsibility
for the signed message. In order for this conclusion to be drawn it for the signed message. In order for this conclusion to be drawn it
is necessary for the verifier to assume that the operational security is necessary for the verifier to assume that the operational security
of the DNS zone and corresponding private key are adequate. of the DNS zone and corresponding private key are adequate.
3.1. Private Key Management: Deployment and Ongoing Operations 3.1. Private Key Management: Deployment and Ongoing Operations
Access to signing keys must be carefully managed to prevent use by Access to signing keys MUST be carefully managed to prevent use by
unauthorized parties and to minimize the consequences should a unauthorized parties and to minimize the consequences if a compromise
compromise occur. were to occur.
While a DKIM signing key is used to sign messages on behalf of many While a DKIM signing key is used to sign messages on behalf of many
mail users, the signing key itself should be under direct control of mail users, the signing key itself SHOULD be under direct control of
as few key-holders as possible. Should a key-holder leave the as few key-holders as possible. If a key-holder were to leave the
organization, all signing keys held by that key holder should be organization, all signing keys held by that key holder SHOULD be
withdrawn from service and if appropriate, replaced. withdrawn from service and if appropriate, replaced.
If key management hardware support is available, it should be used. If key management hardware support is available, it SHOULD be used.
If keys are stored in software, sppropriate file control protections If keys are stored in software, appropriate file control protections
must be employed and any location in which the private key is stored MUST be employed, and any location in which the private key is stored
in plaintext form should be excluded from regular backup processes in plaintext form SHOULD be excluded from regular backup processes
and should not be accessible through any form of network including and SHOULD not be accessible through any form of network including
private local area networks. Auditing software should be used private local area networks. Auditing software SHOULD be used
periodically to verify that the permissions on the private key files periodically to verify that the permissions on the private key files
remain secure. remain secure.
Wherever possible a signature key should exist in exactly one Wherever possible a signature key SHOULD exist in exactly one
location and be erased when no longer used. Ideally a signature key location and be erased when no longer used. Ideally a signature key
pair should be generated as close to the signing point as possible pair SHOULD be generated as close to the signing point as possible
and only the public key component transferred to another party. If and only the public key component transferred to another party. If
this is not possible, the private key MUST be transported in an this is not possible, the private key MUST be transported in an
encrypted format that protects the confidentiality of the signing encrypted format that protects the confidentiality of the signing
key. A shared directory on a local file system does not provide key. A shared directory on a local file system does not provide
adequate security for distribution of signing keys in plaintext form. adequate security for distribution of signing keys in plaintext form.
Key escrow schemes are not necessary and should not be used. In the Key escrow schemes are not necessary and SHOULD NOT be used. In the
unlikely event of a signing key becomming lost, a new signature key unlikely event of a signing key becomming lost, a new signature key
pair may be generated as easily as recovery from a key escrow scheme. pair may be generated as easily as recovery from a key escrow scheme.
Responsibility for the security of a signing key should ultimately Responsibility for the security of a signing key SHOULD ultimately
vest in a single named individual. Where multiple parties are vest in a single named individual. Where multiple parties are
authorized to sign messages, each signer should use a different key authorized to sign messages, each signer SHOULD use a different key
to enable accountability and auditing. to enable accountability and auditing.
Best practices for management of cryptographic keying material Best practices for management of cryptographic keying material
require keying material to be refreshed at regular intervals, require keying material to be refreshed at regular intervals,
particular where key management is achieved through software. While particular where key management is achieved through software. While
this practice is highly desirable it is of considerably less this practice is highly desirable it is of considerably less
importance than the requirement to maintain the secrecy of the importance than the requirement to maintain the secrecy of the
corresponding private key. An operational practice in which the corresponding private key. An operational practice in which the
private key is stored in tamper proof hardware and changed once a private key is stored in tamper proof hardware and changed once a
year is considerably more desirable than one in which the signature year is considerably more desirable than one in which the signature
skipping to change at page 16, line 24 skipping to change at page 16, line 24
DNS record management is usually operated by an administrative staff DNS record management is usually operated by an administrative staff
that is different from those who operate an organization's email that is different from those who operate an organization's email
service. In order to ensure that DKIM DNS records are accurate, this service. In order to ensure that DKIM DNS records are accurate, this
imposes a requirement for careful coordination between the two imposes a requirement for careful coordination between the two
operations groups. If the best practices for private key management operations groups. If the best practices for private key management
described above are observed, such deployment is not a one time described above are observed, such deployment is not a one time
event, DNS DKIM selectors will be changed over time signing keys are event, DNS DKIM selectors will be changed over time signing keys are
terminated and replaced. terminated and replaced.
At a minimum, a DNS server that handles queries for DKIM key records At a minimum, a DNS server that handles queries for DKIM key records
must allow the server administrators to add free-form TXT records. MUST allow the server administrators to add free-form TXT records.
It would be better if the the DKIM records could be entered using a It would be better if the the DKIM records could be entered using a
structured form, supporting the DKIM-specific fields. structured form, supporting the DKIM-specific fields.
Ideally DNSSEC [] should be employed in a configuration that provides Ideally DNSSEC [RFC4034] SHOULD be employed in a configuration that
protection against record insertion attacks and zone enumeration. In provides protection against record insertion attacks and zone
the case that NSEC3 [RFC 5155] records are employed to prevent enumeration. In the case that NSEC3 [RFC5155] records are employed
insertion attack, the OPT-OUT flag must be set clear. to prevent insertion attack, the OPT-OUT flag MUST be set clear.
3.2.1. Assignment of Selectors 3.2.1. Assignment of Selectors
Selectors are assigned according to the administrative needs of the Selectors are assigned according to the administrative needs of the
signing domain, such as for rolling over to a new key or for signing domain, such as for rolling over to a new key or for
delegating of the right to authenticate a portion of the namespace to delegating of the right to authenticate a portion of the namespace to
a trusted third party. Examples include: a trusted third party. Examples include:
jun2005.eng._domainkey.example.com jun2005.eng._domainkey.example.com
skipping to change at page 17, line 40 skipping to change at page 17, line 40
3.4. Third Party Signer Key Management and Selector Administration 3.4. Third Party Signer Key Management and Selector Administration
A DKIM key record only asserts that the holder of the corresponding A DKIM key record only asserts that the holder of the corresponding
domain name makes a claim of responsibility for messages signed under domain name makes a claim of responsibility for messages signed under
the corresponding key. In some applications, such as bulk mail the corresponding key. In some applications, such as bulk mail
delivery it is desirable to delegate the ability to make a claim of delivery it is desirable to delegate the ability to make a claim of
responsibility to another party. In this case the trust relationship responsibility to another party. In this case the trust relationship
is established between the domain holder and the verifier but the is established between the domain holder and the verifier but the
private signature key is held by a third party. private signature key is held by a third party.
Signature keys used by a third party signer should be kept entirely Signature keys used by a third party signer SHOULD be kept entirely
separate from those used by the domain holder and other third party separate from those used by the domain holder and other third party
signers. As with any other private key, the signature key pair signers. As with any other private key, the signature key pair
should be generated by the third party signer and the public SHOULD be generated by the third party signer and the public
component of the key transmitted to the domain holder rather than component of the key transmitted to the domain holder rather than
have the domain holder generate the key pair and transmit the private have the domain holder generate the key pair and transmit the private
component to the third party signer. component to the third party signer.
Domain holders should adopt a least privilege approach and grant Domain holders SHOULD adopt a least privilege approach and grant
third party signers the minimum access necessary to perform the third party signers the minimum access necessary to perform the
desired function. Limiting the access granted to Third Party Signers desired function. Limiting the access granted to Third Party Signers
serves to protect the interests of both parties. The domain holder serves to protect the interests of both parties. The domain holder
minimizes their security risk and the Trusted Third Party Signer minimizes their security risk and the Trusted Third Party Signer
avoids unnecessary liability. avoids unnecessary liability.
In the most restrictive case a domain holder maintains full control In the most restrictive case a domain holder maintains full control
over the creation of key records and employ appropriate key record over the creation of key records and employ appropriate key record
restrictions to enforce restrictions on the messages for which the restrictions to enforce restrictions on the messages for which the
third party signer is able to sign. If such restrictions are third party signer is able to sign. If such restrictions are
impractical, the domain holder should delegate a DNS subzone for impractical, the domain holder SHOULD delegate a DNS subzone for
publishing key records to the third party signer. The domain holder publishing key records to the third party signer. The domain holder
should not allow a third party signer unrestricted access to their SHOULD not allow a third party signer unrestricted access to their
DNS service for the purpose of publishing key records. DNS service for the purpose of publishing key records.
3.5. Key Pair / Selector Lifecycle Management 3.5. Key Pair / Selector Lifecycle Management
Deployments should establish, document and observe processes for Deployments SHOULD establish, document and observe processes for
managing the entire lifecycle of a public key pair. managing the entire lifecycle of a public key pair.
3.5.1. Example Key Deployment Process 3.5.1. Example Key Deployment Process
When it is determined that a new key pair is required: When it is determined that a new key pair is required:
1. A Key Pair is generated by the signing device 1. A Key Pair is generated by the signing device
2. A proposed key selector record is generated and transmitted to 2. A proposed key selector record is generated and transmitted to
the DNS administration infrasrtructure. the DNS administration infrasrtructure.
skipping to change at page 20, line 36 skipping to change at page 20, line 36
implementing the mechanism "deeper" into the organization's email implementing the mechanism "deeper" into the organization's email
infrastructure, such as at its boundary MTA. infrastructure, such as at its boundary MTA.
Note the discussion in Section 2.2, concerning use of the i= tag. Note the discussion in Section 2.2, concerning use of the i= tag.
The signing module uses the appropriate private key to create one or The signing module uses the appropriate private key to create one or
more signatures. The means by which the signing module obtains the more signatures. The means by which the signing module obtains the
private key(s) is not specified by DKIM. Given that DKIM is intended private key(s) is not specified by DKIM. Given that DKIM is intended
for use during email transit, rather than for long-term storage, it for use during email transit, rather than for long-term storage, it
is expected that keys will be changed regularly. For administrative is expected that keys will be changed regularly. For administrative
convenience, key information should not be hard-coded into software. convenience, key information SHOULD NOT be hard-coded into software.
4.3. Signing Policies and Practices 4.3. Signing Policies and Practices
Every organization (ADMD) will have its own policies and practices Every organization (ADMD) will have its own policies and practices
for deciding when to sign messages (message stream) and with what for deciding when to sign messages (message stream) and with what
domain name, selector and key. Examples of particular message domain name, selector and key. Examples of particular message
streams include all mail sent from the ADMD, versus mail from streams include all mail sent from the ADMD, versus mail from
particular types of user accounts, versus mail having particular particular types of user accounts, versus mail having particular
types of content. Given this variability, and the likelihood that types of content. Given this variability, and the likelihood that
signing practices will change over time, it will be useful to have signing practices will change over time, it will be useful to have
skipping to change at page 21, line 15 skipping to change at page 21, line 15
and well might attempt to impose more differential analysis on the and well might attempt to impose more differential analysis on the
recipient than they wish to support. In such cases, they are likely recipient than they wish to support. In such cases, they are likely
to use only a super-name -- right-hand substring -- of the signing to use only a super-name -- right-hand substring -- of the signing
name. When this occurs, the signer will not know what portion is name. When this occurs, the signer will not know what portion is
being used; this then moves DKIM back to the non-deterministic world being used; this then moves DKIM back to the non-deterministic world
of heuristics, rather than the mechanistic world of signer/recipient of heuristics, rather than the mechanistic world of signer/recipient
collaboration that DKIM seeks. collaboration that DKIM seeks.
5. Verifying 5. Verifying
To be added. A message recipient may verify a DKIM signature to determine if a
claim of responsibility has been made for the message by a trusted
domain.
Access control requires two components: authentication and
authorization. By design, verification of a DKIM signature only
provides the authentication component of an access control decision
and MUST be combined with additional sources of information such as
reputation data to arrive at an access control decision.
5.1. Intended Scope of Use
DKIM requires that a message with a signature that is found to be
invalid is to be treated as if the message had not been signed at
all.
If a DKIM signature fails to verify, it is entirely possible that the
message is valid and that either there is a configuration error in
the signer's system (e.g. a missing key record) or that the message
was inadvertently modified in transit. It is thus undesirable for
mail infrastructure to treat messages with invalid signatures less
favorably than those with no signatures whatsoever. Contrariwise,
creation of an invalid signature requires a trivial amount of effort
on the part of an attacker. If messages with invalid signatures were
to be treated preferentially to messages with no signatures
whatsoever, attackers will simply add invalid signature blocks to
gain the preferential treatment. It follows that messages with
invalid signatures SHOULD be treated no better and no worse than
those with no signature at all.
5.2. Signature Scope
As with any other digital signature scheme, verifiers MUST only
consider the part of the message that is inside the scope of the
message as being authenticated by the signature.
For example, if the l= option is employed to specify a content length
for the scope of the signature, only the part of the message that is
within the scope of the content signature would be considered
authentic.
5.3. Design Scope of Use
Public Key cryptography provides an exceptionally high degree of
assurance bordering on absolute certainty, that the party that
created a valid digital signature had access to the private key
corresponding to the public key indicated in the signature.
In order to make useful conclusions from the verification of a valid
digital signature, the verifier is obliged to make assumptions that
fall far short of absolute certainty. Consequently, mere validation
of a DKIM signature does not represent proof positive that a valid
claim of responsibility was made for it by the indicated party, that
the message is authentic or that the message is not abusive. In
particular:
o The legitimate private key holder may have lost control of their
private key.
o The legitimate domain holder may have lost control of the DNS
server for the zone from which the key record was retrieved.
o The key record may not have been delivered from the legitimate DNS
server for the zone from which the key record was retrieved.
o Ownership of the DNS zone may have changed.
In practice these limitations have little or no impact on the field
of use for which DKIM is designed but may have a bearing if use is
made of the DKIM message signature format or key retrieval mechanism
in other specifications.
In particular the DKIM key retrieval mechanism is designed for ease
of use and deployment rather than to provide a high assurance public
Key Infrastructure suitable for purposes that require robust non-
repudiation such as establishing legally binding contracts.
Developers seeking to extend DKIM beyond its design application
SHOULD consider replacing or supplementing the DNS key retreival
mechanism with one that is designed to meet the intended purposes.
5.4. Inbound Mail Filtering
DKIM is frequently employed in a mail filtering strategy to avoid the
need to perform content analysis on email originating from trusted
sources. Messages that carry a valid DKIM signature from a trusted
source may be whitelisted, avoiding the need to perform computation
and hence energy intensive content analysis to determine the
disposition of the message.
Mail sources may be determined to be trusted by means of previously
observed behavior and/or reference to external reputation or
accreditation services. The precise means by which this is
acomplished is outside the scope of DKIM.
5.4.1. Non-Verifying Adaptive Spam Filtering Systems
Adaptive (or learning) spam filtering mechanisms that are not capable
of verifying DKIM signatures SHOULD at minimum be configured to
ignore DKIM header data entirely.
5.5. Messages sent through Mailing Lists and other Intermediaries
Intermediaries such as mailing lists pose a particular challenge for
DKIM implementations as the message processing steps performed by the
intermediary may cause the message content to change in ways that
prevent the signature passing verification.
Such intermediaries are strongly encouraged to deploy DKIM signing so
that a verifiable claim of responsibility remains available to
parties attempting to verify the modified message.
5.6. Generation, Transmission and Use of Results Headers
In many deployments it is desirable to separate signature
verification from the application relying on the verification. For
example, if:
o The relying application is not capable of performing DKIM
signature verification.
o The message may be modified after the signature verification is
performed.
o The signature key may not be available by the time that the
message is read.
In such cases it is important that the communication link between the
signature verifier and the relying application be sufficiently secure
to prevent insertion of a message that carries a bogus results
header.
An intermediary that generates results headers SHOULD ensure that
relying applications are able to distinguish valid results headers
issued by the intermediary from those introduced by an attacker. For
example, this can be accomplished by signing the results header. At
a minimum, results headers on incoming messages SHOULD be removed if
they purport to have been issued by the intermediary but cannot be
verified as authentic.
6. Taxonomy of Signatures 6. Taxonomy of Signatures
A DKIM signature tells the signature verifier that the owner of a A DKIM signature tells the signature verifier that the owner of a
particular domain name accepts some responsibility for the message. particular domain name accepts some responsibility for the message.
It does not, in and of itself, provide any information about the It does not, in and of itself, provide any information about the
trustworthiness or behavior of that identity. What it does provide trustworthiness or behavior of that identity. What it does provide
is a verified identity to which such behavioral information can be is a verified identity to which such behavioral information can be
associated, so that those who collect and use such information can be associated, so that those who collect and use such information can be
assured that it truly pertains to the identity in question. assured that it truly pertains to the identity in question.
skipping to change at page 21, line 44 skipping to change at page 24, line 38
outbound email using its own domain in the d= tag of the signature. outbound email using its own domain in the d= tag of the signature.
For example, Company A would sign the outbound mail from its For example, Company A would sign the outbound mail from its
employees with d=companyA.example. employees with d=companyA.example.
In the most straightforward configuration, the addresses in the RFC In the most straightforward configuration, the addresses in the RFC
5322 From would also be in the companyA.example domain, but that 5322 From would also be in the companyA.example domain, but that
direct correlation is not required. direct correlation is not required.
A special case of the Single Domain Signature is an Author Signature A special case of the Single Domain Signature is an Author Signature
as defined by the Author Domain Signing Practices specification. as defined by the Author Domain Signing Practices specification.
Author signatures are signatures from an authors organization that Author signatures are signatures from an author's organization that
have an i= value that matches the From: address of the message. have an i= value that matches the From: address of the message.
Under the ADSP specification, an i= value matches a RFC 5322 From Under the ADSP specification, an i= value matches a RFC 5322 From
address when the domains of the two match exactly, and if the i= address when the domains of the two match exactly, and if the i=
value contains a local part it also matches the local part of the value contains a local part it also matches the local part of the
From: address exactly. From: address exactly.
Although an author signature might in some cases be proof against Although an author signature might in some cases be proof against
domain name spoofing the RFC 5322 From address, it is important to domain name spoofing the RFC 5322 From address, it is important to
note that the DKIM and ADSP validation apply only to the exact note that the DKIM and ADSP validation apply only to the exact
address string and not to look-alike addresses nor to the human- address string and not to look-alike addresses nor to the human-
skipping to change at page 26, line 45 skipping to change at page 29, line 42
make modifications that can invalidate a DKIM signature. make modifications that can invalidate a DKIM signature.
However, some forwarders such as mailing lists or forward article However, some forwarders such as mailing lists or forward article
to a friend services, might choose to add their own signature to to a friend services, might choose to add their own signature to
outbound messages to vouch for it having legitimately originated outbound messages to vouch for it having legitimately originated
from the designated service. In this case, the signature would be from the designated service. In this case, the signature would be
added even in the presence of a pre-existing signature, and both added even in the presence of a pre-existing signature, and both
signatures would be relevant to the verifier. signatures would be relevant to the verifier.
Any forwarder that modifies messages in ways that will break pre- Any forwarder that modifies messages in ways that will break pre-
existing DKIM signatures should always sign its forwarded existing DKIM signatures SHOULD always sign its forwarded
messages. messages.
Reputation Providers: Although third party reputation providers Reputation Providers: Although third party reputation providers
today use a variety of protocols to communicate their information today use a variety of protocols to communicate their information
to receivers, it is possible that they, or other organizations to receivers, it is possible that they, or other organizations
willing to put their "seal of approval" on an email stream might willing to put their "seal of approval" on an email stream might
choose to use a DKIM signature to do it. In nearly all cases, choose to use a DKIM signature to do it. In nearly all cases,
this "reputation" signature would be in addition to the author or this "reputation" signature would be in addition to the author or
originator signature. originator signature.
skipping to change at page 27, line 19 skipping to change at page 30, line 17
Signatures are created by different types of email actors, based on Signatures are created by different types of email actors, based on
different criteria, such as where the actor operates in the sequence different criteria, such as where the actor operates in the sequence
from author to recipient, whether they want different messages to be from author to recipient, whether they want different messages to be
evaluated under the same reputation or different, and so on. This evaluated under the same reputation or different, and so on. This
section provides some examples of usage scenarios for DKIM section provides some examples of usage scenarios for DKIM
deployments; the selection is not intended to be exhaustive, but to deployments; the selection is not intended to be exhaustive, but to
illustrate a set of key deployment considerations. illustrate a set of key deployment considerations.
7.1. Author's Organization - Simple 7.1. Author's Organization - Simple
The simplest DKIM configuration is to have all mail from a given The simplest DKIM configuration is to have some mail from a given
organization (Company A) be signed with the same d= value (e.g. organization (Company A) be signed with the same d= value (e.g.
d=companya.example). If there is a desire to associate a user d=companya.example). If there is a desire to associate a user
identity or some other related information, the i= value can become identity or some other related information, the i= value can become
uniqueID@companya.example, or uniqueID.companya.example. uniqueID@companya.example, or @uniqueID.companya.example.
In this scenario, Company A need only generate a single signing key In this scenario, Company A need only generate a single signing key
and publish it under their top level domain (companya.example); the and publish it under their top level domain (companya.example); the
signing module would then tailor the i= value as needed at signing signing module would then tailor the i= value as needed at signing
time. time.
7.2. Author's Organization - Differentiated Types of Mail 7.2. Author's Organization - Differentiated Types of Mail
A slight variation of the one signature case is where Company A signs A slight variation of the one signature case is where Company A signs
all of its mail, but it wants to differentiate different categories some of its mail, but it wants to differentiate different categories
of its outbound mail by using different identifiers. For example, it of its outbound mail by using different identifiers. For example, it
might choose to distinguish marketing mail, billing or transactional might choose to distinguish marketing mail, billing or transactional
mail, and individual corporate email into marketing.companya.example, mail, and individual corporate email into marketing.companya.example,
billing.companya.example, and companya.example, where each category billing.companya.example, and companya.example, where each category
is assigned a unique subdomain and unique signing keys. is assigned a unique subdomain and unique signing keys.
7.3. Author Signature 7.3. Author Signature
As discussed in Section 6.1, author signatures are a special case of As discussed in Section 6.1, author signatures are a special case of
signatures from an authors organization where at least one signature signatures from an author's organization where at least one signature
on the message has an i= value that matches the From: address of the on the message has an i= value that matches the From: address of the
message. message.
Signers wishing to publish an ADSP record describing their signing Signers wishing to publish an ADSP record describing their signing
practices will want to include an author signature on their outbound practices will want to include an author signature on their outbound
mail to avoid ADSP verification failures. For example, if the mail to avoid ADSP verification failures. For example, if the
address in the RFC 5322 From is bob@company.example, the d= value of address in the RFC 5322 From is bob@company.example, the d= value of
the author signature would be company.example, and the i= value would the author signature would be company.example, and the i= value would
be either company.example or bob@company.example. be either company.example or bob@company.example.
7.4. Author Domain Signing Practices 7.4. Author Domain Signing Practices
To be added. 7.4.1. Introduction
DomainKeys Identified Mail (DKIM) defines a mechanism by which email
messages can be cryptographically signed, permitting a signing domain
to claim responsibility for the introduction of a message into the
mail stream.
However, the legacy of the Internet is such that not all messages
will be signed, and the absence of a signature on a message is not an
a priori indication of forgery. In fact, during early phases of
deployment it is very likely that most messages will remain unsigned.
However, some domains might decide to sign all of their outgoing
mail, for example, to assist in protecting their brand names: If all
of the legitimate mail for that brand is signed, recipients can by
more aggressive in their filtering of mail that uses the brand but is
not signed by the domain name associated with the brand. It might be
desirable for such domains to be able to advertise that fact to other
hosts: this is the topic of Author Domain Signing Practices (ADSP).
Note that ADSP is not for everyone. Sending domains that do not have
complete control of all legitimate outbound mail purporting to be
from their domain (i.e., with a From address in their domain) are
likely to experience delivery problems with some percentage of that
mail. Administrators evaluating ADSP for their domains SHOULD
carefully weigh the risk of phishing attacks against the likelihood
of undelivered mail.
This section covers some examples of ADSP usage: for the complete
specification, see [I-D.ietf-dkim-ssp]
7.4.2. A Few Definitions
In the ADSP specification, an <addr-spec> in the From header field of
a message [RFC5322] is defined as an "Author Address", and an "Author
Domain" is defined as anything to the right of the '@' in an Author
Address.
An "Author Signature" is thus any Valid Signature where the identity
of the user or agent on behalf of which the message is signed (listed
in the "i=" tag or its default value from the "d=" tag) matches an
Author Address in the message. (When the identity of the user or
agent includes a Local-part, the identities match if the Local-parts
are the same string, and the domains are the same string. Otherwise,
the identities match if the domains are the same string. Following
[RFC5321], Local-part comparisons are case sensitive, but domain
comparisons are case insensitive.)
It is important to note that unlike the DKIM specification which
makes no correlation between the signature domain and any message
headers, the ADSP specification applies only to the author domain.
In essence, under ADSP, any non-author signatures are ignored
(treated as if they are not present).
7.4.3. Some ADSP Examples
An organization (Company A) may specify its signing practices by
publishing an ADSP record with "dkim=all" or "dkim=discardable". In
order to avoid misdelivery of its mail at receivers that are
validating ADSP, Company A MUST first have done an exhaustive
analysis to determine all sources of outbound mail from its domain
(companyA.example) and ensure that they all have valid author
signatures from that domain.
For example, email with an RFC 5322 From <addr-spec> of bob@
companyA.example MUST have an author signature where the i= value is
either "@companyA.example" or "bob@companyA.example", or it will fail
an ADSP validation.
Note that once an organization publishes an ADSP record using
dkim=all or dkim=discardable, any email with a RFC 5322 From address
that uses the domain where the ADSP record is published that does not
have a valid author signature is at risk of being mis-delivered or
discarded. For example, if a message with an RFC 5322 From <addr-
spec> of newsletter@companyA.example has a signature with
i=@marketing.companyA.example or i=jsmith@companyA.example, that
message will fail the ADSP check because the signature would not be
considered a valid author signature.
Because the semantics of an ADSP author signature are more
constrained than the semantics of a "pure" DKIM signature, it is
important to make sure you understand the nuances before deploying an
ADSP record. The ADSP specification [I-D.ietf-dkim-ssp] provides
some fairly extensive lookup examples (in Appendix A) and usage
examples (in Appendix B).
In particular, in order to prevent mail from being negatively
impacted or even discarded at the receiver, it is essential to
perform a thorough survey of outbound mail from a domain before
publishing an ADSP policy of anything stronger than "unknown". This
includes mail that might be sent from external sources that may not
be authorized to use your domain signature, as well as mail that
risks modification in transit that might invalidate an otherwise
valid author signature (e.g. mailing lists, courtesy forwarders, and
other paths that could add or modify headers, or modify the message
body).
7.5. Delegated Signing 7.5. Delegated Signing
An organization may choose to outsource certain key services to third An organization may choose to outsource certain key services to an
party companies. For example, Company A might outsource its benefits independent company. For example, Company A might outsource its
management, or Organization B might outsource its marketing email. benefits management, or Organization B might outsource its marketing
email.
If Company A wants to ensure that all of the mail sent on its behalf If Company A wants to ensure that all of the mail sent on its behalf
through the benefits providers email servers shares the Company A through the benefits providers email servers shares the Company A
reputation, as discussed in Section 6.4 it can either publish keys reputation, as discussed in Section 6.4 it can either publish keys
designated for the use of the benefits provider under designated for the use of the benefits provider under
companyA.example (preferably under a designated subdomain of companyA.example (preferably under a designated subdomain of
companyA.example), or they can delegate a subdomain (e.g. companyA.example), or they can delegate a subdomain (e.g.
benefits.companyA.example) to the provider and enable the provider to benefits.companyA.example) to the provider and enable the provider to
generate the keys and manage the DNS for the designated subdomain. generate the keys and manage the DNS for the designated subdomain.
skipping to change at page 29, line 21 skipping to change at page 34, line 15
each client: e.g. a signature on behalf of client A would have each client: e.g. a signature on behalf of client A would have
d=clienta.espa.example. d=clienta.espa.example.
Note that this scenario and the delegation scenario are not mutually Note that this scenario and the delegation scenario are not mutually
exclusive: in some cases, it may be desirable to sign the same exclusive: in some cases, it may be desirable to sign the same
message with both the ESP and the ESP client identities. message with both the ESP and the ESP client identities.
7.7. Mail Streams Based on Behavioral Assessment 7.7. Mail Streams Based on Behavioral Assessment
An ISP (ISP A) might want to assign signatures to outbound mail from An ISP (ISP A) might want to assign signatures to outbound mail from
their users according to the users past sending behavior their users according to each user's past sending behavior
(reputation). Since the semantics of behavioral assessments arent (reputation). In other words, the ISP would segment its outbound
allowed as i= values, ISP A (ispa.example) would have to configure traffic according to its own assessment of message quality, to aid
subdomains corresponding the assessment categories (e.g. recipients in deciding to process these different streams
good.ispa.example, neutral.ispa.example, bad.ispa.example), and use differently. Since the semantics of behavioral assessments aren't
these domains as the d= value of the signature. allowed as i= values, ISP A (ispa.example) may configure subdomains
corresponding to the assessment categories (e.g. good.ispa.example,
neutral.ispa.example, bad.ispa.example), and use these subdomains in
the d= value of the signature.
The signing module can also optionally set the i= value to have a The signing module can also optionally set the i= value to have a
unique user id (distinct from the users email address local part), unique user id (distinct from the users email address local part),
for example user3456@neutral.domain.example. Using a userid that is for example user3456@neutral.domain.example. Using a userid that is
distinct from a given email alias is useful in environments where a distinct from a given email alias is useful in environments where a
single user might register multiple email aliases. single user might register multiple email aliases.
Note that in this case the i= values are only partially stable. They Note that in this case the i= values are only partially stable. They
are stable in the sense that a given i= value will always represent are stable in the sense that a given i= value will always represent
the same identity, but they are unstable in the sense that a given the same identity, but they are unstable in the sense that a given
user can migrate among the assessment subdomains depending on their user can migrate among the assessment subdomains depending on their
sending behavior (i.e., the same user might have multiple i= values sending behavior (i.e., the same user might have multiple i= values
over the lifetime of their account). over the lifetime of their account).
In this scenario, ISP A would have to generate as many keys as there In this scenario, ISP A may generate as many keys as there are
are assessment subdomains (d= values), so that each assessment assessment subdomains (d= values), so that each assessment subdomain
subdomain had its own key. The signing module would then choose its has its own key. The signing module would then choose its signing
signing key based on the assessment of the user whose mail was being key based on the assessment of the user whose mail was being signed,
signed, and if desired include the user id in the i= tag of the and if desired include the user id in the i= tag of the signature.
signature.
7.8. Agent or Mediator Signatures 7.8. Agent or Mediator Signatures
Another scenario is that of an agent, usually a re-mailer of some Another scenario is that of an agent, usually a re-mailer of some
kind, that signs on behalf of the service or organization that it kind, that signs on behalf of the service or organization that it
represents. Some examples of agents might be a mailing list manager, represents. Some examples of agents might be a mailing list manager,
or the "forward article to a friend" service that many online or the "forward article to a friend" service that many online
publications offer. In most of these cases, the signature is publications offer. In most of these cases, the signature is
asserting that the message originated with, or was relayed by, the asserting that the message originated with, or was relayed by, the
service asserting responsibility. service asserting responsibility.
skipping to change at page 31, line 39 skipping to change at page 36, line 37
8.3. Signature Granularity 8.3. Signature Granularity
Although DKIM's use of domain names is optimized for a scope of Although DKIM's use of domain names is optimized for a scope of
organization-level signing, it is possible to administer sub-domains organization-level signing, it is possible to administer sub-domains
or otherwise adjust signatures in a way that supports per-user or otherwise adjust signatures in a way that supports per-user
identification. This user level granularity can be specified in two identification. This user level granularity can be specified in two
ways: either by sharing the signing identity and specifying an ways: either by sharing the signing identity and specifying an
extension to the i= value that has a per-user granularity, or by extension to the i= value that has a per-user granularity, or by
creating and signing with unique per-user keys. creating and signing with unique per-user keys.
A subdomain or local part in the i= tag should be treated as an A subdomain or local part in the i= tag SHOULD be treated as an
opaque identifier and thus need not correspond directly to a DNS sub opaque identifier and thus need not correspond directly to a DNS
domain or to a specific user address subdomain or be a specific user address.
The primary way to sign with per-user keys require that each user The primary way to sign with per-user keys require that each user
have a distinct DNS (sub)domain, where each distinct d= value has a have a distinct DNS (sub)domain, where each distinct d= value has a
key published (it is possible, although not recommended, to publish key published (it is possible, although not recommended, to publish
the same key in more than one distinct domain). the same key in more than one distinct domain).
It is technically possible, to publish per-user keys within a single It is technically possible, to publish per-user keys within a single
domain or subdomain by utilizing different selector values. This is domain or subdomain by utilizing different selector values. This is
not recommended and is unlikely to be treated uniquely by Identity not recommended and is unlikely to be treated uniquely by Identity
Assessors: the primary purpose of selectors is to facilitate key Assessors: the primary purpose of selectors is to facilitate key
skipping to change at page 33, line 18 skipping to change at page 38, line 17
advertised email sending policy. It SHOULD also be able to advertised email sending policy. It SHOULD also be able to
generate an operator alert if it determines that the email generate an operator alert if it determines that the email
messages do not comply with the published DKIM sending policy. messages do not comply with the published DKIM sending policy.
An MSA SHOULD be aware that some MUAs may add their own An MSA SHOULD be aware that some MUAs may add their own
signatures. If the MSA needs to perform operations on a signatures. If the MSA needs to perform operations on a
message to make it comply with its email sending policy, if at message to make it comply with its email sending policy, if at
all possible, it SHOULD do so in a way that would not break all possible, it SHOULD do so in a way that would not break
those signatures. those signatures.
[[anchor38: MSK: MUAs being able to sign is a security [[anchor48: MSK: MUAs being able to sign is a security
consideration; MUAs are more prone to vulnerabilities, so an consideration; MUAs are more prone to vulnerabilities, so an
MUA having direct access to signing keys is a security concern; MUA having direct access to signing keys is a security concern;
general MUA vulnerability came up during the IETF Security general MUA vulnerability came up during the IETF Security
Directorate review of draft-kucherawy-sender-auth-header]] Directorate review of draft-kucherawy-sender-auth-header]]
Inbound: When an organization deploys DKIM, it needs to make Inbound: When an organization deploys DKIM, it needs to make
sure that it email infrastructure components that do not have sure that it email infrastructure components that do not have
primary roles in DKIM handling do not modify message in ways primary roles in DKIM handling do not modify message in ways
that prevent subsequent verification. that prevent subsequent verification.
skipping to change at page 36, line 34 skipping to change at page 41, line 32
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001. "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
August 2001. August 2001.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006. Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4870] Delany, M., "Domain-Based Email Authentication Using [RFC4870] Delany, M., "Domain-Based Email Authentication Using
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
May 2007. May 2007.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007. Signatures", RFC 4871, May 2007.
 End of changes. 39 change blocks. 
97 lines changed or deleted 340 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/