draft-ietf-appsawg-rfc7001bis-03.txt   draft-ietf-appsawg-rfc7001bis-04.txt 
Individual submission M. Kucherawy Individual submission M. Kucherawy
Internet-Draft March 9, 2015 Internet-Draft March 23, 2015
Obsoletes: 7001, 7410 Obsoletes: 7001, 7410
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 10, 2015 Expires: September 24, 2015
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-appsawg-rfc7001bis-03 draft-ietf-appsawg-rfc7001bis-04
Abstract Abstract
This document specifies a message header field called Authentication- This document specifies a message header field called Authentication-
Results for use with electronic mail messages to indicate the results Results for use with electronic mail messages to indicate the results
of message authentication efforts. Any receiver-side software, such of message authentication efforts. Any receiver-side software, such
as mail filters or Mail User Agents (MUAs), can use this header field as mail filters or Mail User Agents (MUAs), can use this header field
to relay that information in a convenient and meaningful way to users to relay that information in a convenient and meaningful way to users
or to make sorting and filtering decisions. or to make sorting and filtering decisions.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 10, 2015. This Internet-Draft will expire on September 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2.3. Property Types (ptypes) and Properties . . . . . . . . . . 12 2.3. Property Types (ptypes) and Properties . . . . . . . . . . 12
2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 13 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 13
2.5. Authentication Identifier Field . . . . . . . . . . . . . 14 2.5. Authentication Identifier Field . . . . . . . . . . . . . 14
2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 15 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 15
2.7. Defined Methods and Result Values . . . . . . . . . . . . 15 2.7. Defined Methods and Result Values . . . . . . . . . . . . 15
2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16
2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17
2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 18 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 18
2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19
2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 20 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 20
2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 20 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21
2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 21 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 21
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 21 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22
4. Adding the Header Field to a Message . . . . . . . . . . . . . 22 4. Adding the Header Field to a Message . . . . . . . . . . . . . 23
4.1. Header Field Position and Interpretation . . . . . . . . . 23 4.1. Header Field Position and Interpretation . . . . . . . . . 24
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 25 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 25
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 25 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.1. The Authentication-Results Header Field . . . . . . . . . 26 6.1. The Authentication-Results Header Field . . . . . . . . . 27
6.2. "Email Authentication Methods" Registry Description . . . 27 6.2. "Email Authentication Methods" Registry Description . . . 27
6.3. "Email Authentication Methods" Registry Update . . . . . . 28 6.3. "Email Authentication Methods" Registry Update . . . . . . 28
6.4. "Email Authentication Result Names" Registry . . . . . . . 28 6.4. "Email Authentication Property Types" Registry . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6.5. "Email Authentication Result Names" Description . . . . . 30
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 29 6.6. "Email Authentication Result Names" Update . . . . . . . . 30
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 31 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 31
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 31 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 33
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 31 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 33
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 31 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 34
7.7. Attacks against Authentication Methods . . . . . . . . . . 32 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 34
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 32 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 34
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 32 7.7. Attacks against Authentication Methods . . . . . . . . . . 34
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 32 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 34
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 33 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 35
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 35
8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 35
8.2. Informative References . . . . . . . . . . . . . . . . . . 33 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35
Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 36 8.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix C. Authentication-Results Examples . . . . . . . . . . . 36 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38
C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 36 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 38
Appendix C. Authentication-Results Examples . . . . . . . . . . . 39
C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 39
C.2. Nearly Trivial Case; Service Provided, but No C.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 37 Authentication Done . . . . . . . . . . . . . . . . . . . 40
C.3. Service Provided, Authentication Done . . . . . . . . . . 38 C.3. Service Provided, Authentication Done . . . . . . . . . . 41
C.4. Service Provided, Several Authentications Done, Single C.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
C.5. Service Provided, Several Authentications Done, C.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 40 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 43
C.6. Service Provided, Multi-Tiered Authentication Done . . . . 42 C.6. Service Provided, Multi-Tiered Authentication Done . . . . 45
C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 43 C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 46
Appendix D. Operational Considerations about Message Appendix D. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 44 Authentication . . . . . . . . . . . . . . . . . . . 47
Appendix E. Change History . . . . . . . . . . . . . . . . . . . 45 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 48
E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 45 E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 48
E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 46 E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 49
E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 46 E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 49
E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 46 E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 49
E.5. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
This document describes a header field called Authentication-Results This document describes a header field called Authentication-Results
for electronic mail messages that presents the results of a message for electronic mail messages that presents the results of a message
authentication effort in a machine-readable format. The intent of authentication effort in a machine-readable format. The intent of
the header field is to create a place to collect such data when the header field is to create a place to collect such data when
message authentication mechanisms are in use so that a Mail User message authentication mechanisms are in use so that a Mail User
Agent (MUA) and downstream filters can make filtering decisions Agent (MUA) and downstream filters can make filtering decisions
and/or provide a recommendation to the user as to the validity of the and/or provide a recommendation to the user as to the validity of the
skipping to change at page 16, line 11 skipping to change at page 16, line 11
not specified in this document, but intended to be supported by the not specified in this document, but intended to be supported by the
header field defined here, MUST include a similar result table either header field defined here, MUST include a similar result table either
in their defining documents or in supplementary ones. in their defining documents or in supplementary ones.
2.7.1. DKIM and DomainKeys 2.7.1. DKIM and DomainKeys
DKIM is represented by the "dkim" method and is defined in [DKIM]. DKIM is represented by the "dkim" method and is defined in [DKIM].
DomainKeys is defined in [DOMAINKEYS] and is represented by the DomainKeys is defined in [DOMAINKEYS] and is represented by the
"domainkeys" method. "domainkeys" method.
Section 3.8 of [DOMAINKEYS] enumerates some possible results of a
DomainKeys evaluation. Those results are not used when generating
this header field; rather, the results returned are listed below.
A signature is "acceptable to the ADMD" if it passes local policy A signature is "acceptable to the ADMD" if it passes local policy
checks (or there are no specific local policy checks). For example, checks (or there are no specific local policy checks). For example,
an ADMD policy might require that the signature(s) on the message be an ADMD policy might require that the signature(s) on the message be
added using the DNS domain present in the From header field of the added using the DNS domain present in the From header field of the
message, thus making third-party signatures unacceptable even if they message, thus making third-party signatures unacceptable even if they
verify. verify.
Both DKIM and DomainKeys use the same result set, as follows: Both DKIM and DomainKeys use the same result set, as follows:
none: The message was not signed. none: The message was not signed.
skipping to change at page 17, line 5 skipping to change at page 17, line 8
is unrecoverable, such as a required header field being absent. A is unrecoverable, such as a required header field being absent. A
later attempt is unlikely to produce a final result. later attempt is unlikely to produce a final result.
DKIM results are reported using a ptype of "header". The property, DKIM results are reported using a ptype of "header". The property,
however, represents one of the tags found in the DKIM-Signature however, represents one of the tags found in the DKIM-Signature
header field rather than a distinct header field. For example, the header field rather than a distinct header field. For example, the
ptype-property combination "header.d" refers to the content of the ptype-property combination "header.d" refers to the content of the
"d" (signing domain) tag from within the signature header field, and "d" (signing domain) tag from within the signature header field, and
not a distinct header field called "d". not a distinct header field called "d".
DomainKeys results are reported using the "header" ptype, but a
mixture of DKIM-style values (e.g., "d" represents the value of the
"d" tag from the DomainKey-Signature header field) and typical uses
(e.g., "from" and "sender", containing those header fields' values).
In the latter case, [MAIL]-style comments are removed, leaving only
the address.
[DKIM] advises that if a message fails verification, it is to be [DKIM] advises that if a message fails verification, it is to be
treated as an unsigned message. A report of "fail" here permits the treated as an unsigned message. A report of "fail" here permits the
receiver of the report to decide how to handle the failure. A report receiver of the report to decide how to handle the failure. A report
of "neutral" or "none" preempts that choice, ensuring the message of "neutral" or "none" preempts that choice, ensuring the message
will be treated as if it had not been signed. will be treated as if it had not been signed.
Section 3.1 of [DOMAINKEYS] describes a process by which the sending
address of the message is determined. DomainKeys results are thus
reported along with the signing domain name, the sending address of
the message, and the name of the header field from which the latter
was extracted. This means that a DomainKeys result includes a ptype-
property combination of "header.d", plus one of "header.from" and
"header.sender". The sending address extracted from the header is
included with any [MAIL]-style comments removed; moreover, the local-
part of the address is removed if it has not been authenticated in
some way.
2.7.2. SPF and Sender ID 2.7.2. SPF and Sender ID
SPF and Sender ID use the "spf" and "sender-id" method names, SPF and Sender ID use the "spf" and "sender-id" method names,
respectively. The result values for SPF are defined in Section 2.6 respectively. The result values for SPF are defined in Section 2.6
of [SPF], and those definitions are included here by reference: of [SPF], and those definitions are included here by reference:
+-----------+--------------------------------+ +-----------+--------------------------------+
| Code | Meaning | | Code | Meaning |
+-----------+--------------------------------+ +-----------+--------------------------------+
| none | [RFC7208], Section 2.6.1 | | none | [RFC7208], Section 2.6.1 |
skipping to change at page 17, line 48 skipping to change at page 18, line 7
+-----------+--------------------------------+ +-----------+--------------------------------+
| temperror | [RFC7208], Section 2.6.6 | | temperror | [RFC7208], Section 2.6.6 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| permerror | [RFC7208], Section 2.6.7 | | permerror | [RFC7208], Section 2.6.7 |
+-----------+--------------------------------+ +-----------+--------------------------------+
These result codes are used in the context of this specification to These result codes are used in the context of this specification to
reflect the result returned by the component conducting SPF reflect the result returned by the component conducting SPF
evaluation. evaluation.
Similarly, the results for Sender ID are listed and described in For SPF, the ptype used is "smtp", and the property is any of
Section 4.2 of [SENDERID], which in turn uses the SPF definitions "mailfrom", "helo", and "ehlo", since those values are the ones SPF
that now appear in [SPF]. can evaluate.
The "sender-id" method is described in [SENDERID]. For this method,
the ptype used is "header" and the property will be the name of the
header field from which the Purported Responsible address (see [PRA])
was extracted, namely one of "Resent-Sender", "Resent-From",
"Sender", or "From".
The results for Sender ID are listed and described in Section 4.2 of
[SENDERID], but for the purposes of this specification, the SPF
definitions enumerated above are used instead.
Note that both of those documents specify result codes that use mixed Note that both of those documents specify result codes that use mixed
case, but they are typically used all lowercase in this context. case, but they are typically used all lowercase in this context.
For SPF, the ptype used is "smtp", and the property is any of For both methods, an additional result of "policy" is defined, which
"mailfrom", "helo", and "ehlo", since those values are the ones SPF
can evaluate. For Sender ID, the ptype used is "header", and the
property will be the name of the header field from which the
Purported Responsible Address (see [PRA]) was extracted.
In both cases, an additional result of "policy" is defined, which
means the client was authorized to inject or relay mail on behalf of means the client was authorized to inject or relay mail on behalf of
the sender's DNS domain according to the authentication method's the sender's DNS domain according to the authentication method's
algorithm, but local policy dictates that the result is unacceptable. algorithm, but local policy dictates that the result is unacceptable.
For example, "policy" might be used if SPF returns a "pass" result, For example, "policy" might be used if SPF returns a "pass" result,
but a local policy check matches the sending DNS domain to one found but a local policy check matches the sending DNS domain to one found
in an explicit list of unacceptable DNS domains (e.g., spammers). in an explicit list of unacceptable DNS domains (e.g., spammers).
If the retrieved sender policies used to evaluate SPF and Sender ID If the retrieved sender policies used to evaluate SPF and Sender ID
do not contain explicit provisions for authenticating the local-part do not contain explicit provisions for authenticating the local-part
(see Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported (see Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported
skipping to change at page 19, line 44 skipping to change at page 20, line 7
as a temporary directory service lookup error. A later attempt as a temporary directory service lookup error. A later attempt
may produce a final result. may produce a final result.
permerror: The SMTP client attempted to authenticate using the permerror: The SMTP client attempted to authenticate using the
protocol described in [AUTH] but was not able to complete the protocol described in [AUTH] but was not able to complete the
attempt due to some error that is likely not transient in nature, attempt due to some error that is likely not transient in nature,
such as a permanent directory service lookup error. A later such as a permanent directory service lookup error. A later
attempt is not likely to produce a final result. attempt is not likely to produce a final result.
The result of AUTH is reported using a ptype of "smtp" and a property The result of AUTH is reported using a ptype of "smtp" and a property
of "mailfrom", and the reported value is the value of the AUTH of either:
parameter to that command.
o "auth", in which case the value is the authorization identity
generated by the exchange initiated by the AUTH command; or
o "mailfrom", in which case the value is the mailbox identified by
the AUTH parameter used with the MAIL FROM command.
If both identities are available, both can be reported. For example,
consider this command issued by a client that has completed session
authentication with the AUTH command resulting in an authorized
identity of "client@c.example":
MAIL FROM:<alice@a.example> AUTH=<bob@b.example>
This could result in a resinfo construction like so:
; auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example
An agent making use of the data provided by this header field SHOULD An agent making use of the data provided by this header field SHOULD
consider "fail" and "temperror" to be synonymous in terms of message consider "fail" and "temperror" to be synonymous in terms of message
authentication, i.e., the client did not authenticate in either case. authentication, i.e., the client did not authenticate in either case.
2.7.5. Other Registered Codes 2.7.5. Other Registered Codes
Result codes were also registered in other RFCs as follows: Result codes were also registered in other RFCs as follows:
o Vouch By Reference (in [AR-VBR], represented by "vbr"); o Vouch By Reference (in [AR-VBR], represented by "vbr");
skipping to change at page 20, line 21 skipping to change at page 20, line 46
o Authorized Third-Party Signatures (in [ATPS], represented by o Authorized Third-Party Signatures (in [ATPS], represented by
"dkim-atps"); "dkim-atps");
o Author Domain Signing Practices (in [ADSP], represented by "dkim- o Author Domain Signing Practices (in [ADSP], represented by "dkim-
adsp"); adsp");
o Require-Recipient-Valid-Since (in [RRVS], represented by "rrvs"); o Require-Recipient-Valid-Since (in [RRVS], represented by "rrvs");
o S/MIME (in [SMIME-REG], represented by "smime"). o S/MIME (in [SMIME-REG], represented by "smime").
o The ability to report different DKIM results for a multiply-signed
message (in [RFC6008]).
2.7.6. Extension Methods 2.7.6. Extension Methods
Additional authentication method identifiers (extension methods) may Additional authentication method identifiers (extension methods) may
be defined in the future by later revisions or extensions to this be defined in the future by later revisions or extensions to this
specification. These method identifiers are registered with the specification. These method identifiers are registered with the
Internet Assigned Numbers Authority (IANA) and, preferably, published Internet Assigned Numbers Authority (IANA) and, preferably, published
in an RFC. See Section 6 for further details. in an RFC. See Section 6 for further details.
Extension methods can be defined for the following reasons: Extension methods can be defined for the following reasons:
skipping to change at page 27, line 12 skipping to change at page 27, line 41
Requesting review of any proposed changes and additions to Requesting review of any proposed changes and additions to
this field is recommended. this field is recommended.
6.2. "Email Authentication Methods" Registry Description 6.2. "Email Authentication Methods" Registry Description
Names of message authentication methods supported by this Names of message authentication methods supported by this
specification are to be registered with IANA, with the exception of specification are to be registered with IANA, with the exception of
experimental names as described in Section 2.7.6. Along with each experimental names as described in Section 2.7.6. Along with each
method is recorded the properties that accompany the method's result. method is recorded the properties that accompany the method's result.
A registry was created by [RFC5451] for this purpose. [RFC6577] The "Email Authentication Parameters" group, and within it the "Email
added a "status" field for each entry. [RFC7001] amended the rules Authentication Methods" registry, were created by [RFC5451] for this
governing that registry, and also added a "version" field to the purpose. [RFC6577] added a "status" field for each entry. [RFC7001]
registry. amended the rules governing that registry, and also added a "version"
field to the registry.
The reference for that registry shall be updated to reference this
document.
New entries are assigned only for values that have received Expert New entries are assigned only for values that have received Expert
Review, per [IANA-CONSIDERATIONS]. The designated expert shall be Review, per [IANA-CONSIDERATIONS]. The designated expert shall be
appointed by the IESG. The designated expert has discretion to appointed by the IESG. The designated expert has discretion to
request that a publication be referenced if a clear, concise request that a publication be referenced if a clear, concise
definition of the authentication method cannot be provided such that definition of the authentication method cannot be provided such that
interoperability is assured. Registrations should otherwise be interoperability is assured. Registrations should otherwise be
permitted. The designated expert can also handle requests to mark permitted. The designated expert can also handle requests to mark
any current registration as "deprecated". any current registration as "deprecated".
skipping to change at page 28, line 20 skipping to change at page 28, line 50
the entry being added can be found. This in turn would reference the the entry being added can be found. This in turn would reference the
document where the method is defined so that all of the semantics document where the method is defined so that all of the semantics
around creating or interpreting an Authentication-Results header around creating or interpreting an Authentication-Results header
field using this method, ptype, and property can be understood. field using this method, ptype, and property can be understood.
6.3. "Email Authentication Methods" Registry Update 6.3. "Email Authentication Methods" Registry Update
The following changes are to be made to this registry upon approval The following changes are to be made to this registry upon approval
of this document: of this document:
1. The sole entry for the "auth" method shall have its "property" 1. The current entry for the "auth" method shall have its "property"
field changed to "mailfrom", and its "Defined" field changed to field changed to "mailfrom", and its "Defined" field changed to
this document. this document.
2. All "dkim", "domainkeys", "iprev", "sender-id", and "spf" method 2. The entry for the "dkim" method, "header" ptype and "b" property
entries shall have their "Defined" fields changed to this shall now reference [RFC6008] as its defining document, and the
reference shall be removed from the description.
3. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf"
method entries shall have their "Defined" fields changed to this
document. document.
6.4. "Email Authentication Result Names" Registry 4. All "smime" entries have their "Defined" fields changed to
[SMIME-REG].
5. The "value" field of the "smime" entry using property "smime-
part" shall be changed to read "A reference to the MIME body part
that contains the signature." The redundant reference is thus
removed.
6. The following entry is to be added:
Method: auth
Defined: [this document]
ptype: smtp
property: auth
Value: identity confirmed by the AUTH command
Status: active
Version: 1
7. The values of the "domainkeys" entries for ptype "header" are
updated as follows:
from: contents of the [MAIL] From: header field, after removing
comments, and removing the local-part if not authenticated
sender: contents of the [MAIL] Sender: header field, after
removing comments, and removing the local-part if not
authenticated
8. All entries for "dkim-adsp" and "domainkeys" shall have their
Status values changed to "deprecated", reflecting the fact that
the corresponding specifications now have Historical status.
6.4. "Email Authentication Property Types" Registry
[PTYPES-REGISTRY] created the Email Authentication Property Types
registry. IANA shall update this registry to show Section 2.3 of
this document as the current definitions for the "body", "header",
"policy" and "smtp" entries of that registry.
6.5. "Email Authentication Result Names" Description
Names of message authentication result codes supported by this Names of message authentication result codes supported by this
specification must be registered with IANA, with the exception of specification must be registered with IANA, with the exception of
experimental codes as described in Section 2.7.7. A registry was experimental codes as described in Section 2.7.7. A registry was
created by [RFC5451] for this purpose. [RFC6577] added the "status" created by [RFC5451] for this purpose. [RFC6577] added the "status"
column, and [RFC7001] updated the rules governing that registry. column, and [RFC7001] updated the rules governing that registry.
New entries are assigned only for values that have received Expert New entries are assigned only for values that have received Expert
Review, per [IANA-CONSIDERATIONS]. The designated expert shall be Review, per [IANA-CONSIDERATIONS]. The designated expert shall be
appointed by the IESG. The designated expert has discretion to appointed by the IESG. The designated expert has discretion to
request that a publication be referenced if a clear, concise request that a publication be referenced if a clear, concise
definition of the authentication result cannot be provided such that definition of the authentication result cannot be provided such that
interoperability is assured. Registrations should otherwise be interoperability is assured. Registrations should otherwise be
permitted. The designated expert can also handle requests to mark permitted. The designated expert can also handle requests to mark
any current registration as "deprecated". any current registration as "deprecated".
All existing registry entries that reference [RFC7001] are to be No two entries can have the same combination of method and code.
updated to reference this document.
The definitions for the SPF and Sender ID authentication methods are An entry in this registry contains the following:
to be updated using the references found in Section 2.7.2.
Auth Method: an authentication method for which results are being
returned using the header field defined in this document;
Code: a result code that can be returned for this authentication
method;
Specification: either free form text explaining the meaning of this
method-code combination, or a reference to such a definition.
6.6. "Email Authentication Result Names" Update
The following changes are to be made to this registry on publication
of this document:
o The "Defined" field shall be removed.
o The "Meaning" field shall be renamed to "Specification", as
described above.
o The "Auth Method" field shall appear before the "Code" field.
o For easier searching, the table shall be arranged such that it is
sorted first by Auth Method, then by Code within each Auth Method
grouping.
o All entries for the "dkim", "domainkeys", "spf", "sender-id",
"auth", and "iprev" methods shall have their "Specification"
fields changed to refer to this document, as follows:
dkim: [this document] Section 2.7.1
domainkeys: [this document] Section 2.7.1
spf: [this document] Section 2.7.2
sender-id: [this document] Section 2.7.2
auth: [this document] Section 2.7.4
iprev: [this document] Section 2.7.3
o All entries for "dkim-adsp" that are missing an explicit reference
to a defining document shall have [ADSP] added to their
Specification fields.
o All entries for "dkim-adsp" and "domainkeys" shall have their
Status values changed to "deprecated", reflecting the fact that
the corresponding specifications now have Historical status.
7. Security Considerations 7. Security Considerations
The following security considerations apply when adding or processing The following security considerations apply when adding or processing
the Authentication-Results header field: the Authentication-Results header field:
7.1. Forged Header Fields 7.1. Forged Header Fields
An MUA or filter that accesses a mailbox whose messages are handled An MUA or filter that accesses a mailbox whose messages are handled
by a non-conformant MTA, and understands Authentication-Results by a non-conformant MTA, and understands Authentication-Results
skipping to change at page 35, line 16 skipping to change at page 37, line 47
E-Mail Messages", RFC 4407, April 2006. E-Mail Messages", RFC 4407, April 2006.
[PTYPES-REGISTRY] Kucherawy, M., "A Property Types Registry for [PTYPES-REGISTRY] Kucherawy, M., "A Property Types Registry for
the Authentication-Results Header Field", the Authentication-Results Header Field",
RFC 7410, December 2014. RFC 7410, December 2014.
[RFC5451] Kucherawy, M., "Message Header Field for [RFC5451] Kucherawy, M., "Message Header Field for
Indicating Message Authentication Status", Indicating Message Authentication Status",
RFC 5451, April 2009. RFC 5451, April 2009.
[RFC6008] Kucherawy, M., "Authentication-Results
Registration for Differentiating among
Cryptographic Results", RFC 6008,
September 2010.
[RFC6577] Kucherawy, M., "Authentication-Results [RFC6577] Kucherawy, M., "Authentication-Results
Registration Update for Sender Policy Registration Update for Sender Policy
Framework (SPF) Results", RFC 6577, Framework (SPF) Results", RFC 6577,
March 2012. March 2012.
[RFC7001] Kucherawy, M., "Message Header Field for [RFC7001] Kucherawy, M., "Message Header Field for
Indicating Message Authentication Status", Indicating Message Authentication Status",
RFC 7001, September 2013. RFC 7001, September 2013.
[RRVS] Mills, W. and M. Kucherawy, "The Require- [RRVS] Mills, W. and M. Kucherawy, "The Require-
skipping to change at page 46, line 36 skipping to change at page 49, line 36
o Add text explaining each of the method-ptype-property tuples o Add text explaining each of the method-ptype-property tuples
registered by this document. registered by this document.
o Change the meaning of the "Defined" column of the methods registry o Change the meaning of the "Defined" column of the methods registry
to be the place where each entry was created and described; it is to be the place where each entry was created and described; it is
expected that this will then refer to the method's defining expected that this will then refer to the method's defining
document. Provide IANA with corresponding update instructions. document. Provide IANA with corresponding update instructions.
o Add references: [DMARC], [PRA], [RFC6577], [RRVS], [SMIME-REG]. o Add references: [DMARC], [PRA], [RFC6577], [RRVS], [SMIME-REG].
E.5. -03 to -04
o Add specific update instructions for the "dkim"/"header"/"b" entry
in IANA Considerations.
o Add description of values that can be extracted from SMTP AUTH
sessions and an example.
o Much more complete descriptions of reporting DomainKeys results.
o Minor editorial adjustments.
o Fix up "smime" entries.
o Update current definitions for the Email Authentication Property
Types registry to point to this document.
o Rework the Email Authentication Result Names registry.
o Add more detail about Sender ID.
o Mark all ADSP and DomainKeys entries as deprecated since their
defining documents are as well.
o Add references: [RFC6008].
Author's Address Author's Address
Murray S. Kucherawy Murray S. Kucherawy
270 Upland Drive 270 Upland Drive
San Francisco, CA 94127 San Francisco, CA 94127
US US
EMail: superuser@gmail.com EMail: superuser@gmail.com
 End of changes. 27 change blocks. 
74 lines changed or deleted 239 lines changed or added

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