draft-ietf-dkim-deployment-00.txt   draft-ietf-dkim-deployment-01.txt 
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Informational D. Crocker Intended status: Informational P. Hallam-Baker
Expires: May 14, 2008 Brandenburg InternetWorking Expires: August 28, 2008 VeriSign Inc.
P. Hallam-Baker D. Crocker
VeriSign Inc. Brandenburg InternetWorking
November 11, 2007 February 25, 2008
DomainKeys Identified Mail (DKIM) Development, Deployment and Operations DomainKeys Identified Mail (DKIM) Development, Deployment and Operations
draft-ietf-dkim-deployment-00 draft-ietf-dkim-deployment-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
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 May 14, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
DomainKeys Identified Mail (DKIM) associates a "responsible" identity DomainKeys Identified Mail (DKIM) associates a "responsible" identity
with a message and provides a means of verifying that the association with a message and provides a means of verifying that the association
is legitimate. [RFC4871] DKIM defines a domain-level authentication is legitimate. [RFC4871] DKIM defines a domain-level authentication
framework for email using public-key cryptography and key server framework for email using public-key cryptography and key server
technology. This permits verifying the source or intermediary for a technology. This permits verifying the source or intermediary for a
message, as well as the contents of messages. The ultimate goal of message, as well as the contents of messages. The ultimate goal of
this framework is to permit a signing domain to assert responsibility this framework is to permit a signing domain to assert responsibility
for a message, thus proving and protecting the identity associated for sending a message, thus proving and protecting the identity
with the message and the integrity of the messages itself, while associated with the message and the integrity of the messages itself,
retaining the functionality of Internet email as it is known today. while retaining the functionality of Internet email as it is known
Such protection of email identity may assist in the global control of today. Such protection of email identity may assist in the global
"spam" and "phishing". This document provides implementation, control of "spam" and "phishing". This document provides
deployment, operational and migration considerations for DKIM. implementation, deployment, operational and migration considerations
for DKIM.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Development . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Development . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. DKIM Signing Software . . . . . . . . . . . . . . . . . . 3 2.1. DKIM Signing Software . . . . . . . . . . . . . . . . . . 3
2.2. General Coding Criteria for Cryptographic Applications . . 3 2.2. General Coding Criteria for Cryptographic Applications . . 3
2.3. Mailing List Manager Software . . . . . . . . . . . . . . 4 2.3. Mailing List Manager Software . . . . . . . . . . . . . . 4
2.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 5 2.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 5
2.5. Filtering Software . . . . . . . . . . . . . . . . . . . . 6 2.5. Filtering Software . . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 8, line 25 skipping to change at page 8, line 25
input to the message evaluation process rather than as providing a input to the message evaluation process rather than as providing a
final decision. The knowledge that a message is authentically sent final decision. The knowledge that a message is authentically sent
by a domain does not say much about the legitimacy of the message, by a domain does not say much about the legitimacy of the message,
unless the characteristics of the domain claiming responsibility are unless the characteristics of the domain claiming responsibility are
known. known.
In particular, verifiers SHOULD NOT automatically assume that an In particular, verifiers SHOULD NOT automatically assume that an
email message that does not contain a signature, or that contains a email message that does not contain a signature, or that contains a
signature that does not verify, is forged. Verifiers should treat a signature that does not verify, is forged. Verifiers should treat a
signature that fails to verify the same as if no signature were signature that fails to verify the same as if no signature were
present. NOTE: THE ABOVE MAY BE MODIFIED BY SSP present. NOTE: THE ABOVE MAY BE MODIFIED BY SSP/ASP
Verification is performed within an ADMD that wishes to make Verification is performed within an ADMD that wishes to make
assessments based upon the DKIM signature's domain name. Any assessments based upon the DKIM signature's domain name. Any
component within the ADMD that handles messages, whether in transit component within the ADMD that handles messages, whether in transit
or being delivered, can do the verifying and subsequent assessments. or being delivered, can do the verifying and subsequent assessments.
Verification and assessment might occur within the same software Verification and assessment might occur within the same software
mechanism, such as a Boundary MTA, or an MDA. Or they may be mechanism, such as a Boundary MTA, or an MDA. Or they may be
separated, such as having verification performed by the Boundary MTA separated, such as having verification performed by the Boundary MTA
and assessment performed by the MDA. and assessment performed by the MDA.
skipping to change at page 10, line 10 skipping to change at page 10, line 10
field list, if the Sender header field exists. field list, if the Sender header field exists.
Signers wishing to avoid the use of Third-Party Signatures SHOULD do Signers wishing to avoid the use of Third-Party Signatures SHOULD do
everything listed above, and also: everything listed above, and also:
o Include the Sender header field name in the header field list o Include the Sender header field name in the header field list
("h=" tag) under all circumstances, even if the Sender header ("h=" tag) under all circumstances, even if the Sender header
field does not exist in the header block. This prevents another field does not exist in the header block. This prevents another
entity from adding a Sender header field. entity from adding a Sender header field.
o Publish Sender Signing Practices that does not sanction the use of o Publish Signing Practices that do not sanction the use of Third-
Third-Party Signatures Party Signatures.
3.4. Mailing Lists 3.4. Mailing Lists
There are several forms of mailing lists, which interact with signing There are several forms of mailing lists, which interact with signing
in different ways. in different ways.
o "Verbatim" mailing lists send messages without modification o "Verbatim" mailing lists send messages without modification
whatsoever. They are often implemented as MTA-based aliases. whatsoever. They are often implemented as MTA-based aliases.
Since they do not modify the message, signatures are unaffected Since they do not modify the message, signatures are unaffected
and will continue to verify. It is not necessary for the and will continue to verify. It is not necessary for the
skipping to change at page 19, line 19 skipping to change at page 19, line 19
9. Informative References 9. Informative References
[I-D.ietf-openpgp-rfc2440bis] [I-D.ietf-openpgp-rfc2440bis]
Callas, J., "OpenPGP Message Format", Callas, J., "OpenPGP Message Format",
draft-ietf-openpgp-rfc2440bis-22 (work in progress), draft-ietf-openpgp-rfc2440bis-22 (work in progress),
April 2007. April 2007.
[I-D.kucherawy-sender-auth-header] [I-D.kucherawy-sender-auth-header]
Kucherawy, M., "Message Header Field for Indicating Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", Message Authentication Status",
draft-kucherawy-sender-auth-header-09 (work in progress), draft-kucherawy-sender-auth-header-11 (work in progress),
November 2007. February 2008.
[RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement
for Internet electronic mail: Part I: Message encipherment for Internet electronic mail: Part I: Message encipherment
and authentication procedures", RFC 989, February 1987. and authentication procedures", RFC 989, February 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME
Object Security Services", RFC 1848, October 1995. Object Security Services", RFC 1848, October 1995.
skipping to change at page 20, line 27 skipping to change at page 20, line 27
Authors' Addresses Authors' Addresses
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
200 Laurel Ave. 200 Laurel Ave.
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: tony+dkimov@maillennium.att.com Email: tony+dkimov@maillennium.att.com
Phillip Hallam-Baker
VeriSign Inc.
Email: pbaker@verisign.com
Dave Crocker Dave Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
675 Spruce Dr. 675 Spruce Dr.
Sunnyvale, CA 94086 Sunnyvale, CA 94086
USA USA
Email: dcrocker@bbiw.net Email: dcrocker@bbiw.net
Phillip Hallam-Baker
VeriSign Inc.
Email: pbaker@verisign.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 11 change blocks. 
25 lines changed or deleted 26 lines changed or added

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