draft-ietf-dkim-rfc4871-errata-01.txt   draft-ietf-dkim-rfc4871-errata-02.txt 
DKIM D. Crocker, Ed. DKIM D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Intended status: Standards Track February 2, 2009 Intended status: Standards Track February 5, 2009
Expires: August 6, 2009 Expires: August 9, 2009
RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Errata RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Errata
draft-ietf-dkim-rfc4871-errata-01 draft-ietf-dkim-rfc4871-errata-02
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 32 skipping to change at page 1, line 32
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 6, 2009. This Internet-Draft will expire on August 9, 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Abstract Abstract
This documents and resolves errata for RFC 4871, DomainKeys This documents and resolves errata for RFC 4871, DomainKeys
Identified Mail (DKIM) Signatures. Specifically the document Identified Mail (DKIM) Signatures. Specifically the document
clarifies the nature, roles and relationship of the two DKIM clarifies the nature, roles and relationship of the two DKIM
identifier tag values that are candidates for payload delivery to a identifier tag values that are candidates for payload delivery to a
receiving processing module. receiving processing module. This Errata entry has been developed
and approved by the IETF's DKIM working group.
Errata Contact Fields Errata Contact Fields
Name: Dave Crocker Name: Dave Crocker
Email: dcrocker@bbiw.net Email: dcrocker@bbiw.net
Type Type
Technical Technical
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RFC 4871 Abstract . . . . . . . . . . . . . . . . . . . . . . . 3 2. RFC 4871 Abstract . . . . . . . . . . . . . . . . . . . . . . 3
3. RFC4871 Section 1. Introduction . . . . . . . . . . . . . . . . 3 3. RFC4871 Section 1. Introduction . . . . . . . . . . . . . . . 4
4. RFC4871 Section 2.7 Identity . . . . . . . . . . . . . . . . . 4 4. RFC4871 Section 2.7 Identity . . . . . . . . . . . . . . . . . 4
5. RFC4871 Section 2.8 Identifier . . . . . . . . . . . . . . . . 4 5. RFC4871 Section 2.8 Identifier . . . . . . . . . . . . . . . . 4
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) . . . . . 4 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) . . . . . 4
7. RFC4871 Section 2.10 User Agent Identifier (UAID) . . . . . . . 4 7. RFC4871 Section 2.10 User Agent Identifier (UAID) . . . . . . 5
8. RFC4871 Section 2.11 Identity Assessor . . . . . . . . . . . . 5 8. RFC4871 Section 2.11 Identity Assessor . . . . . . . . . . . . 5
9. RFC4871 Section 3.9 Relationship Between SDID and UAID . . . . 5 9. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 5
10. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . . 6 10. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 6
11. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . . 6 11. RFC4871 Section 3.8. Signing by Parent Domains . . . . . . . 8
12. RFC4871 Section 3.8. Signing by Parent Domains . . . . . . . . 6 12. RFC4871 Section 3.9 Relationship Between SDID and UAID . . . . 9
13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 7 13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 10
14. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 7 14. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 11
15. RFC4871 Appendix D. MUA Considerations . . . . . . . . . . . . 8 15. RFC4871 Appendix D. MUA Considerations . . . . . . . . . . . 11
16. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 16. Security Considerations . . . . . . . . . . . . . . . . . . . 11
17. Normative References . . . . . . . . . . . . . . . . . . . . . 8 17. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
About the purpose for DKIM, [RFC4871] states: About the purpose for DKIM, [RFC4871] states:
The ultimate goal of this framework is to permit a signing domain The ultimate goal of this framework is to permit a signing domain
to assert responsibility for a message, thus protecting message to assert responsibility for a message, thus protecting message
signer identity... signer identity...
Hence, DKIM has a signer that produces a signed message, a verifier Hence, DKIM has a signer that produces a signed message, a verifier
that confirms the signature and an assessor that consumes the that confirms the signature and an assessor that consumes the
validated signing domain. so the simple purpose of DKIM is to validated signing domain. So the simple purpose of DKIM is to
communicate an identifier to a receive-side assessor module. The communicate an identifier to a receive-side assessor module. The
identifier is in the form of a domain name that refers to a identifier is in the form of a domain name that refers to a
responsible identity. For DKIM to be interoperable and useful, responsible identity. For DKIM to be interoperable and useful,
signer and assessor must share the same understanding of the details signer and assessor must share the same understanding of the details
about the identifier. about the identifier.
However the specification defines two, potentially different However the RFC5871 specification defines two, potentially different
identifiers that are carried in the DKIM-Signature: header field and identifiers that are carried in the DKIM-Signature: header field, d=
might be delivered to a receiving processing module that consumes and i=. Either might be delivered to a receiving processing module
validated payload. The DKIM specification fails to clearly define that consumes validated payload. The DKIM specification fails to
what is "payload" to be delivered to a consuming module, versus what clearly define what is "payload" to be delivered to a consuming
is internal and merely in support of achieving payload delivery. module, versus what is internal and merely in support of achieving
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 erratum resolves this confusion. It defines new labels for the This erratum 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 and their
relationship. relationship.
NOTE: This Errata document has been developed and approved by the
IETF's DKIM working group. For more information about DKIM and
its IETF working group, see: <http://dkim.org>.
2. RFC 4871 Abstract 2. RFC 4871 Abstract
Original Text: The ultimate goal of this framework is to permit a Original Text:
signing domain to assert responsibility
Corrected Text: The ultimate goal of this framework is to permit a The ultimate goal of this framework is to permit a signing domain
person, role or organization that owns the signing domain to to assert responsibility for a message,
assert responsibility Corrected Text:
The ultimate goal of this framework is to permit a person, role or
organization that owns the signing domain to assert responsibility
for a message,
3. RFC4871 Section 1. Introduction 3. RFC4871 Section 1. Introduction
Original Text: permitting a signing domain to claim responsibility
Corrected Text: permitting a person, role or organization that owns Original Text:
the signing domain to claim responsibility
...permitting a signing domain to claim responsibility
Corrected Text:
permitting a person, role or organization that owns the signing
domain to claim responsibility
4. RFC4871 Section 2.7 Identity 4. RFC4871 Section 2.7 Identity
A person, role or organization. Original Text:
Original Text: (None. Additional text.) (None. Additional text.)
Corrected Text: A person, role or organization. Corrected Text:
A person, role or organization. In the context of DKIM, examples
include author, author's organization, an ISP along the handling
path, an independent trust assessment service, and a mailing list
operator.
5. RFC4871 Section 2.8 Identifier 5. RFC4871 Section 2.8 Identifier
Original Text: (None. Additional text.) Original Text:
Corrected Text: A label that refers to an identity. (None. Additional text.)
Corrected Text:
A label that refers to an identity.
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
Original Text:
Original Text: (None. Additional text.) (None. Additional text.)
Corrected Text: A single, opaque value that is the mandatory Corrected Text:
payload output of DKIM and that refers to the identity claiming
responsibility for the introduction of a message into the mail A single, opaque value that is the mandatory payload output of
stream. Within the scope of the DKIM Signing specification, the DKIM and which refers to the identity claiming responsibility for
conventions and semantics used by a signer to create and use a the introduction of a message into the mail stream. It is
specific SDID are outside the scope of the DKIM Signing specified in section 3.5.
specification, as is any use of those conventions and semantics.
7. RFC4871 Section 2.10 User Agent Identifier (UAID) 7. RFC4871 Section 2.10 User Agent Identifier (UAID)
Original Text: (None. Additional text.) Original Text:
Corrected Text: A single, opaque value that is the optional, (None. Additional text.)
additional payload output of DKIM and that identifies the user or
agent on behalf of whom the SDID has taken responsibility. The Corrected Text:
conventions and semantics used by a signer to create and use a
specific UAID are outside the scope of the DKIM Signing A single, opaque value that identifies the user or agent on behalf
specification, as is any use of those conventions and semantics. of whom the SDID has taken responsibility. It is specified in
section 3.5.
8. RFC4871 Section 2.11 Identity Assessor 8. RFC4871 Section 2.11 Identity Assessor
Original Text: (None. Additional text.) Original Text:
Corrected Text: The name of the module that consumes DKIM's primary (None. Additional text.)
payload, the responsible Signing Domain Identifier (SDID). It can
optionally consume the User Agent Identifier (UAID) value, if Corrected Text:
provided to the module. The conventions and semantics used by a
signer to create and use a specific SDID or UAID are outside the The name of the module that consumes DKIM's primary payload, the
responsible Signing Domain Identifier (SDID). It can optionally
consume the User Agent Identifier (UAID) value, if provided to the
module.
9. RFC4871 Section 3.5 The DKIM-Signature Header Field
Original Text:
d= The domain of the signing entity (plain-text; REQUIRED). This is
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
signing identity, as described below), or it MUST meet the
requirements for parent domain signing described in Section 3.8.
When presented with a signature that does not meet these
requirement, verifiers MUST consider the signature invalid.
Internationalized domain names MUST be encoded as described in
[RFC3490].
ABNF:
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain, but excluding address-literal
Corrected Text:
d=
Specifies the SDID claiming responsibility for an introduction
of a message into the mail stream (plain-text; REQUIRED). This
is the domain that will be queried for the public key. The
SDID MUST correspond to a valid DNS name under which the DKIM
key record is published. The conventions and semantics used by
a signer to create and use a specific SDID are outside the
scope of the DKIM Signing specification, as is any use of those scope of the DKIM Signing specification, as is any use of those
conventions and semantics. conventions and semantics. When presented with a signature
that does not meet these requirements, verifiers MUST consider
the signature invalid.
9. RFC4871 Section 3.9 Relationship Between SDID and UAID Internationalized domain names MUST be encoded as described in
[RFC3490].
Original Text: (None. This is an addition.) ABNF:
Corrected Text: DKIM's primary task is to communicate from the sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
Signer to a recipient-side Identity Assessor a single, Signing domain-name = sub-domain 1*("." sub-domain)
Domain Identifier (SDID) that identifies a responsible identity. ; from RFC 2821 Domain, but excluding address-literal
The SDID MUST be the value of the d= tag. DKIM MAY optionally
provide a single responsible User Agent Identifier (UAID); if the
UAID is present, it MUST be the value of the i= tag.
The SDID MUST correspond to a valid DNS name under which the DKIM 10. RFC4871 Section 3.5 The DKIM-Signature Header Field
key record is published.
Original Text:
i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty Local-part followed by an "@"
followed by the domain from the "d=" tag). The syntax is a
standard email address where the Local-part MAY be omitted. The
domain part of the address MUST be the same as or a subdomain of
the value of the "d=" tag.
Internationalized domain names MUST be converted using the steps
listed in Section 4 of [RFC3490] using the "ToASCII" function.
ABNF:
sig-i-tag =
%x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
because in some cases a signer may not be able to establish a
verified individual identity. In such cases, the signer may
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 an individual user name within their domain. It can do so
by including the domain part but not the Local-part of the
identity.
INFORMATIVE DISCUSSION: This document does not require the value
of the "i=" tag to match the identity in any message header
fields. This is considered to be a verifier policy issue.
Constraints between the value of the "i=" tag and other
identities in other header fields seek to apply basic
authentication into the semantics of trust associated with a
role such as content author. Trust is a broad and complex
topic and trust mechanisms are subject to highly creative
attacks. The real-world efficacy of any but the most basic
bindings between the "i=" value and other identities is not
well established, nor is its vulnerability to subversion by
an attacker. Hence reliance on the use of these options
should be strictly limited. In particular, it is not at all
clear to what extent a typical end-user recipient can rely on
any assurances that might be made by successful use of the
"i=" options.
Corrected Text:
i=
The User Agent Identifier (UAID) on behalf of which the SDID is
taking responsibility (dkim-quoted-printable; OPTIONAL, default
is an empty Local-part followed by an "@" followed by the
domain from the "d=" tag).
The syntax is a standard email address where the Local-part MAY
be omitted. The domain part of the address MUST be the same
as, or a subdomain of the value of, the "d=" tag.
Internationalized domain names MUST be converted using the
steps listed in Section 4 of [RFC3490] using the "ToASCII"
function.
ABNF:
sig-i-tag = %x69 [FWS] "=" [FWS]
[ Local-part ] "@" domain-name
The UAID is specified as having the same syntax as an email The UAID is specified as having the same syntax as an email
address, but is not required to have the same semantics. Notably, address, but is not required to have the same semantics.
the domain name is not required to be registered in the DNS -- so Notably, the domain name is not required to be registered in
it might not resolve in a query -- and the Local-part MAY be drawn the DNS -- so it might not resolve in a query -- and the Local-
from a namespace that does not contain the user's mailbox. The part MAY be drawn from a namespace that does not contain the
details of the structure and semantics for the namespace are user's mailbox. The details of the structure and semantics for
determined by the Signer. Any knowledge or use of those details the namespace are determined by the Signer. Any knowledge or
by verifiers or assessors is outside the scope of the DKIM Signing use of those details by verifiers or assessors is outside the
specification. The Signer MAY choose to use the same namespace scope of the DKIM Signing specification. The Signer MAY choose
for its UAIDs as its users' email addresses, or MAY choose other to use the same namespace for its UAIDs as its users' email
means of representing its users. However, the signer SHOULD use addresses, or MAY choose other means of representing its users.
the same UAID for each message intended to be evaluated as being However, the signer SHOULD use the same UAID for each message
within the same sphere of responsibility, if it wishes to offer intended to be evaluated as being within the same sphere of
receivers the option of using the UAID as a finer grained, stable responsibility, if it wishes to offer receivers the option of
identifier than the SDID. using the UAID as a finer grained, stable identifier than the
SDID.
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
because in some cases a signer may not be able to establish a
verified individual identity. In such cases, the signer might
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
an individual user name within their domain. It can do so by
including the domain part but not the Local-part of the
identity.
11. RFC4871 Section 3.8. Signing by Parent Domains
Original Text:
e.g., a key record for the domain example.com can be used to verify
messages where the signing identity ("i=" tag of the signature) is
sub.example.com, or even sub1.sub2.example.com. In order to limit
the capability of such keys when this is not intended, the "s" flag
may be set in the "t=" tag of the key record to constrain the
validity of the record to exactly the domain of the signing identity.
If the referenced key record contains the "s" flag as part of the
"t=" tag, the domain of the signing identity ("i=" flag) MUST be the
same as that of the d= domain. If this flag is absent, the domain of
the signing identity MUST be the same as, or a subdomain of, the d=
domain.
Corrected Text:
...for example, a key record for the domain example.com can be
used to verify messages where the UAID ("i=" tag of the signature)
is sub.example.com, or even sub1.sub2.example.com. In order to
limit the capability of such keys when this is not intended, the
"s" flag MAY be set in the "t=" tag of the key record, to
constrain the validity of the domain of the UAID. If the
referenced key record contains the "s" flag as part of the "t="
tag, the domain of the UAID ("i=" flag) MUST be the same as that
of the SDID (d=) domain. If this flag is absent, the domain of
the UAID MUST be the same as, or a subdomain of, the SDID.
12. RFC4871 Section 3.9 Relationship Between SDID and UAID
Original Text: (None. This is an addition.)
Corrected Text:
DKIM's primary task is to communicate from the Signer to a
recipient-side Identity Assessor a single, Signing Domain
Identifier (SDID) that refers to a responsible identity. DKIM MAY
optionally provide a single responsible User Agent Identifier
(UAID).
Hence, DKIM delivers to receive-side Identity Assessors Hence, DKIM delivers to receive-side Identity Assessors
responsible Identifiers that are individual, opaque values. Their responsible Identifiers that are opaque to the assessor. Their
sub-structures and particular semantics are not publicly defined sub-structures and particular semantics are not publicly defined
and, therefore, cannot be assumed by an Identity Assessor. and, therefore, 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 User Agent 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.
10. RFC4871 Section 3.5 The DKIM-Signature Header Field INFORMATIVE DISCUSSION: This document does not require the value
of the SDID or UAID to match the identity in any message header
Original Text: d= The domain of the signing entity. fields. This is considered to be an assessor policy issue.
Constraints between the value of the SDID or UAID and other
Corrected Text: d= Specifies the SDID claiming responsibility for identities in other header fields seek to apply basic
an introduction of a message into the mail stream. authentication into the semantics of trust associated with a role
such as content author. Trust is a broad and complex topic and
11. RFC4871 Section 3.5 The DKIM-Signature Header Field trust mechanisms are subject to highly creative attacks. The
real-world efficacy of any but the most basic bindings between the
Original Text: i= Identity of the user or agent (e.g., a mailing SDID or UAID and other identities is not well established, nor is
list manager) on behalf of which this message is signed its vulnerability to subversion by an attacker. Hence reliance on
the use of these options should be strictly limited. In
Corrected Text: i= The responsible User Agent Identifier (UAID) on particular, it is not at all clear to what extent a typical end-
behalf of which the SDID is taking responsibility. user recipient can rely on any assurances that might be made by
successful use of the SDID or UAID.
12. RFC4871 Section 3.8. Signing by Parent Domains
the section where the error appears 13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy
Original Text: e.g., a key record for the domain example.com can be Original Text:
used to verify messages where the signing identity ("i=" tag of
the signature) is sub.example.com, or even sub1.sub2.example.com.
In order to limit the capability of such keys when this is not
intended, the "s" flag may be set in the "t=" tag of the key
record to constrain the validity of the record to exactly the
domain of the signing identity. If the referenced key record
contains the "s" flag as part of the "t=" tag, the domain of the
signing identity ("i=" flag) MUST be the same as that of the d=
domain. If this flag is absent, the domain of the signing
identity MUST be the same as, or a subdomain of, the d=
Corrected Text: For example, a key record for the domain
example.com can be used to verify messages where the UAID ("i="
tag of the signature) is sub.example.com, or even
sub1.sub2.example.com. In order to limit the capability of such
keys when this is not intended, the "s" flag MAY be set in the
"t=" tag of the key record, to constrain the validity of the
domain of the UAID. If the referenced key record contains the "s"
flag as part of the "t=" tag, the domain of the UAID ("i=" flag)
MUST be the same as that of the SDID (d=) domain. If this flag is
absent, the domain of the UAID MUST be the same as, or a subdomain
of, the SDID.
13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy It is beyond the scope of this specification to describe what actions
a verifier system should make, but an authenticated email presents an
opportunity to a receiving system that unauthenticated email cannot.
Specifically, an authenticated email creates a predictable identifier
by which other decisions can reliably be managed, such as trust and
reputation. Conversely, unauthenticated email lacks a reliable
identifier that can be used to assign trust and reputation.
Original Text: It is beyond the scope of this specification to Corrected Text:
describe what actions a verifier system should make, but an
authenticated email presents an opportunity to a receiving system
that unauthenticated email cannot. Specifically, an authenticated
email creates a predictable identifier by which other decisions
can reliably be managed, such as trust and reputation.
Corrected Text: It is beyond the scope of this specification to It is beyond the scope of this specification to describe what
describe what actions an Identity Assessor can make, but mail actions an Identity Assessor can make, but mail carrying a
carrying a validated SDID presents an opportunity to an Identity validated SDID presents an opportunity to an Identity Assessor
Assessor that unauthenticated email does not Specifically, an that unauthenticated email does not. Specifically, an
authenticated email creates a predictable identifier by which authenticated email creates a predictable identifier by which
other decisions can reliably be managed, such as trust and other decisions can reliably be managed, such as trust and
reputation. reputation.
14. RFC4871 Section 6.3. Interpret Results/Apply Local Policy 14. RFC4871 Section 6.3. Interpret Results/Apply Local Policy
Original Text: Once the signature has been verified, that Original Text:
information MUST be conveyed to higher-level systems (such as
explicit allow/whitelists and reputation systems) and/or to the
end user. If the message is signed on behalf of any address other
than that in the From: header field, the mail system SHOULD take
pains to ensure that the actual signing identity is clear to the
reader.
Corrected Text: Once the signature has been verified, that Once the signature has been verified, that information MUST be
information MUST be conveyed to the Identity Assessor (such as an conveyed to higher-level systems (such as explicit allow/whitelists
explicit allow/whitelist and reputation system) and/or to the end and reputation systems) and/or to the end user. If the message is
user. If the SDID is not the same as the address in the From: signed on behalf of any address other than that in the From: header
header field, the mail system SHOULD take pains to ensure that the field, the mail system SHOULD take pains to ensure that the actual
actual SDID is clear to the reader. signing identity is clear to the reader.
Corrected Text:
Once the signature has been verified, that information MUST be
conveyed to the Identity Assessor (such as an explicit allow/
whitelist and reputation system) and/or to the end user. If the
SDID is not the same as the address in the From: header field, the
mail system SHOULD take pains to ensure that the actual SDID is
clear to the reader.
15. RFC4871 Appendix D. MUA Considerations 15. RFC4871 Appendix D. MUA Considerations
Original Text: The tendency is to have the MUA highlight the Original Text: The tendency is to have the MUA highlight the
address associated with this signing identity in some way, in an address associated with this signing identity in some way, in an
attempt to show the user the address from which the mail was sent. attempt to show the user the address from which the mail was sent.
Corrected Text: The tendency is to have the MUA highlight the SDID, Corrected Text: The tendency is to have the MUA highlight the SDID,
in an attempt to show the user the identity that is claiming in an attempt to show the user the identity that is claiming
responsibility for the message. responsibility for the message.
skipping to change at page 8, line 35 skipping to change at page 12, line 10
[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.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This document was initially formulated by an ad hoc design team, This document was initially formulated by an ad hoc design team,
comprising: Jon Callas, J D Falk, Jim Fenton, Tony Hansen, Murray comprising: Jon Callas, J D Falk, Jim Fenton, Tony Hansen, Murray
Kucherawy, John Levine, Michael Hammer, Jeff Macdonald, Ellen Siegel, Kucherawy, John Levine, Michael Hammer, Jeff Macdonald, Ellen Siegel,
Wietse Venema. It represents a rough consensus of that effort, Wietse Venema. It was then submitted to the DKIM working group for
although the final wording of the submitted draft is the sole revision and approval.
responsibility (d=) of the listed author.
Author's Address Author's Address
D. Crocker (editor) D. Crocker (editor)
Brandenburg InternetWorking Brandenburg InternetWorking
Phone: +1.408.246.8253 Phone: +1.408.246.8253
Email: dcrocker@bbiw.net Email: dcrocker@bbiw.net
 End of changes. 42 change blocks. 
152 lines changed or deleted 308 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/