draft-ietf-dkim-rfc4871-errata-04.txt   draft-ietf-dkim-rfc4871-errata-05.txt 
DKIM D. Crocker, Ed. DKIM D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Updates: RFC4871 April 21, 2009 Updates: RFC4871 May 22, 2009
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: October 23, 2009 Expires: November 23, 2009
RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update
draft-ietf-dkim-rfc4871-errata-04 draft-ietf-dkim-rfc4871-errata-05
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. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 October 23, 2009. This Internet-Draft will expire on November 23, 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 35 skipping to change at page 3, line 35
that consumes validated payload. The DKIM specification fails to that consumes validated payload. The DKIM specification fails to
clearly define what is "payload" to be delivered to a consuming clearly define what is "payload" to be delivered to a consuming
module, versus what is internal and merely in support of achieving module, versus what is internal and merely in support of achieving
payload delivery. payload delivery.
This currently leaves signers and assessors with the potential for This currently leaves signers and assessors with the potential for
having differing -- and therefore non-interoperable -- having differing -- and therefore non-interoperable --
interpretations of how DKIM operates. interpretations of how DKIM operates.
This update resolves this confusion. It defines new labels for the This update resolves this confusion. It defines new labels for the
two values, clarifies their nature, and specifies and their two values, clarifies their nature, and specifies their relationship.
relationship.
NOTE: The text provided here updates [RFC4871]. All references and NOTE: The text provided here updates [RFC4871]. All references and
all appearances of RFC-2119 keywords are replacing text in RFC all appearances of RFC-2119 keywords are replacing text in RFC
4871. Hence those references are in that document and are not 4871. Hence those references are in that document and are not
needed here. needed here.
2. RFC 4871 Abstract 2. RFC 4871 Abstract
Original Text: Original Text:
skipping to change at page 5, line 41 skipping to change at page 5, line 41
outside the scope of DKIM. It is specified in section 3.5. outside the scope of DKIM. It is specified in section 3.5.
8. RFC4871 Section 2.11 Identity Assessor 8. RFC4871 Section 2.11 Identity Assessor
Original Text: Original Text:
(None. Additional text.) (None. Additional text.)
Corrected Text: Corrected Text:
The name of the module that consumes DKIM's mandatory payload, the A module that consumes DKIM's mandatory payload, which is the
responsible Signing Domain Identifier (SDID). The module is responsible Signing Domain Identifier (SDID). The module is
dedicated to the assessment of the delivered identifier. Other dedicated to the assessment of the delivered identifier. Other
DKIM (and non-DKIM) values can also be delivered to this module as DKIM (and non-DKIM) values can also be delivered to this module as
well as to a more general message evaluation filtering engine. well as to a more general message evaluation filtering engine.
However this additional activity is outside the scope of the DKIM However, this additional activity is outside the scope of the DKIM
signature specification. signature specification.
9. RFC4871 Section 3.5 The DKIM-Signature Header Field 9. RFC4871 Section 3.5 The DKIM-Signature Header Field
Original Text: Original Text:
d= The domain of the signing entity (plain-text; REQUIRED). This is d= The domain of the signing entity (plain-text; REQUIRED). This is
the domain that will be queried for the public key. This domain the domain that will be queried for the public key. This domain
MUST be the same as or a parent domain of the "i=" tag (the MUST be the same as or a parent domain of the "i=" tag (the
signing identity, as described below), or it MUST meet the signing identity, as described below), or it MUST meet the
skipping to change at page 8, line 39 skipping to change at page 8, line 39
part MAY be drawn from a namespace that does not contain the part MAY be drawn from a namespace that does not contain the
user's mailbox. The details of the structure and semantics for user's mailbox. The details of the structure and semantics for
the namespace are determined by the Signer. Any knowledge or the namespace are determined by the Signer. Any knowledge or
use of those details by verifiers or assessors is outside the use of those details by verifiers or assessors is outside the
scope of the DKIM Signing specification. The Signer MAY choose scope of the DKIM Signing specification. The Signer MAY choose
to use the same namespace for its AUIDs as its users' email to use the same namespace for its AUIDs as its users' email
addresses, or MAY choose other means of representing its users. addresses, or MAY choose other means of representing its users.
However, the signer SHOULD use the same AUID for each message However, the signer SHOULD use the same AUID for each message
intended to be evaluated as being within the same sphere of intended to be evaluated as being within the same sphere of
responsibility, if it wishes to offer receivers the option of responsibility, if it wishes to offer receivers the option of
using the AUID as a finer grained, stable identifier than the using the AUID as a stable identifier that is finer grained
SDID. than the SDID.
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
because in some cases a signer may not be able to establish a because in some cases a signer may not be able to establish a
verified individual identity. In such cases, the signer might verified individual identity. In such cases, the signer might
wish to assert that although it is willing to go as far as wish to assert that although it is willing to go as far as
signing for the domain, it is unable or unwilling to commit to signing for the domain, it is unable or unwilling to commit to
an individual user name within their domain. It can do so by an individual user name within their domain. It can do so by
including the domain part but not the Local-part of the including the domain part but not the Local-part of the
identity. identity.
skipping to change at page 10, line 8 skipping to change at page 10, line 8
Hence, DKIM's mandatory output to a receive-side Identity Assessor Hence, DKIM's mandatory output to a receive-side Identity Assessor
is a single domain name. Within the scope of its use as DKIM is a single domain name. Within the scope of its use as DKIM
output, the name has only basic domain name semantics; any output, the name has only basic domain name semantics; any
possible owner-specific semantics are outside the scope of DKIM. possible owner-specific semantics are outside the scope of DKIM.
That is, within its role as a DKIM identifier, additional That is, within its role as a DKIM identifier, additional
semantics cannot be assumed by an Identity Assessor. semantics cannot be assumed by an Identity Assessor.
A receive-side DKIM verifier MUST communicate the Signing Domain A receive-side DKIM verifier MUST communicate the Signing Domain
Identifier (d=) to a consuming Identity Assessor module and MAY Identifier (d=) to a consuming Identity Assessor module and MAY
communicate the User Agent Identifier (i=) if present. communicate the Agent or User Identifier (i=) if present.
To the extent that a receiver attempts to intuit any structured To the extent that a receiver attempts to intuit any structured
semantics for either of the identifiers, this is a heuristic semantics for either of the identifiers, this is a heuristic
function that is outside the scope of DKIM's specification and function that is outside the scope of DKIM's specification and
semantics. Hence it is relegated to a higher-level service, such semantics. Hence it is relegated to a higher-level service, such
as a delivery handling filter that integrates a variety of inputs as a delivery handling filter that integrates a variety of inputs
and performs heuristic analysis of them. and performs heuristic analysis of them.
INFORMATIVE DISCUSSION: This document does not require the value INFORMATIVE DISCUSSION: This document does not require the value
of the SDID or AUID to match the identity in any message header of the SDID or AUID to match the identity in any message header
 End of changes. 9 change blocks. 
11 lines changed or deleted 10 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/