draft-ietf-appsawg-rfc7001bis-02.txt   draft-ietf-appsawg-rfc7001bis-03.txt 
Individual submission M. Kucherawy Individual submission M. Kucherawy
Internet-Draft February 20, 2015 Internet-Draft March 9, 2015
Obsoletes: 7001, 7410 Obsoletes: 7001, 7410
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: August 24, 2015 Expires: September 10, 2015
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-appsawg-rfc7001bis-02 draft-ietf-appsawg-rfc7001bis-03
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 August 24, 2015. This Internet-Draft will expire on September 10, 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 32 skipping to change at page 2, line 32
2.1. General Description . . . . . . . . . . . . . . . . . . . 9 2.1. General Description . . . . . . . . . . . . . . . . . . . 9
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . 18 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19
2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 19 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 20
2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 19 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 20
2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 20 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 21
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 20 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 21
4. Adding the Header Field to a Message . . . . . . . . . . . . . 22 4. Adding the Header Field to a Message . . . . . . . . . . . . . 22
4.1. Header Field Position and Interpretation . . . . . . . . . 23 4.1. Header Field Position and Interpretation . . . . . . . . . 23
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 24 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 25
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 24 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.1. The Authentication-Results Header Field . . . . . . . . . 26 6.1. The Authentication-Results Header Field . . . . . . . . . 26
6.2. "Email Authentication Methods" Registry . . . . . . . . . 26 6.2. "Email Authentication Methods" Registry Description . . . 27
6.3. "Email Authentication Result Names" Registry . . . . . . . 27 6.3. "Email Authentication Methods" Registry Update . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6.4. "Email Authentication Result Names" Registry . . . . . . . 28
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 29 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 29
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 29 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 30
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 29 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 31
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 30 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 31
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 30 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 31
7.7. Attacks against Authentication Methods . . . . . . . . . . 30 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 31
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 30 7.7. Attacks against Authentication Methods . . . . . . . . . . 32
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 30 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 32
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 31 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 32
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 31 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35
Appendix C. Authentication-Results Examples . . . . . . . . . . . 34 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 36
C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 34 Appendix C. Authentication-Results Examples . . . . . . . . . . . 36
C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 36
C.2. Nearly Trivial Case; Service Provided, but No C.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 35 Authentication Done . . . . . . . . . . . . . . . . . . . 37
C.3. Service Provided, Authentication Done . . . . . . . . . . 36 C.3. Service Provided, Authentication Done . . . . . . . . . . 38
C.4. Service Provided, Several Authentications Done, Single C.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
C.5. Service Provided, Several Authentications Done, C.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 38 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 40
C.6. Service Provided, Multi-Tiered Authentication Done . . . . 40 C.6. Service Provided, Multi-Tiered Authentication Done . . . . 42
C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 41 C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 43
Appendix D. Operational Considerations about Message Appendix D. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 42 Authentication . . . . . . . . . . . . . . . . . . . 44
Appendix E. Change History . . . . . . . . . . . . . . . . . . . 43 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 45
E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 43 E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 45
E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 44 E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 46
E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 44 E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 46
E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 46
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 12, line 30 skipping to change at page 12, line 30
extracted. See Section 2.4 for details. extracted. See Section 2.4 for details.
Examples of complete messages using this header field can be found in Examples of complete messages using this header field can be found in
Appendix C. Appendix C.
2.3. Property Types (ptypes) and Properties 2.3. Property Types (ptypes) and Properties
The "ptype" in the ABNF above indicates the general type of property The "ptype" in the ABNF above indicates the general type of property
being described by the result being reported, upon which the reported being described by the result being reported, upon which the reported
result was based. Coupled with the "property", which is more result was based. Coupled with the "property", which is more
specific, they inidcate from which part of the message the reported specific, they inidcate from which particular part of the message the
data were extracted. reported data were extracted.
Combinations of ptypes and properties are registered and described in Combinations of ptypes and properties are registered and described in
the "Email Authentication Methods" registry, coupled with the the "Email Authentication Methods" registry, coupled with the
authentication methods with which they are used. This is further authentication methods with which they are used. This is further
described in Section 6. described in Section 6.
Legal values of "ptype" are as defined in the IANA "Email Legal values of "ptype" are as defined in the IANA "Email
Authentication Property Types" registry, created by Authentication Property Types" registry, created by
[PTYPES-REGISTRY]. The initial values and what they typically [PTYPES-REGISTRY]. The initial values and what they typically
indicate are as follows, copied from [RFC7001]: indicate are as follows, copied from [RFC7001]:
skipping to change at page 13, line 24 skipping to change at page 13, line 24
smtp: Indicates information that was extracted from an SMTP command smtp: Indicates information that was extracted from an SMTP command
that was used to relay the message. The "property" indicates that was used to relay the message. The "property" indicates
which SMTP command included the extracted content as a parameter. which SMTP command included the extracted content as a parameter.
When a consumer of this header field encounters a "ptype" that it When a consumer of this header field encounters a "ptype" that it
does not understand, it ignores the result reported with that does not understand, it ignores the result reported with that
"ptype". "ptype".
Entries in the "Email Authentication Methods" registry can define Entries in the "Email Authentication Methods" registry can define
properties that deviate from these definitions when appropriate. For properties that deviate from these definitions when appropriate.
example, when reporting the result of a [DKIM] evaluation, it would Such deviations need to be clear in the registry and/or in the
be redundant to report the name of the header field from which defining document. See Section 2.7.1 for an example.
details were extracted. Thus, instead, DKIM results use the "header"
property to name the signature tag from which a detail of interest
was extracted.
2.4. The "policy" ptype 2.4. The "policy" ptype
A special ptype value of "policy" is also defined. This ptype is A special ptype value of "policy" is also defined. This ptype is
provided to indicate that some local policy mechanism was applied provided to indicate that some local policy mechanism was applied
that augments or even replaces (i.e., overrides) the result returned that augments or even replaces (i.e., overrides) the result returned
by the authentication mechanism. The property and value in this case by the authentication mechanism. The property and value in this case
identify the local policy that was applied and the result it identify the local policy that was applied and the result it
returned. returned.
skipping to change at page 16, line 49 skipping to change at page 16, line 46
temperror: The message could not be verified due to some error that temperror: The message could not be verified due to some error that
is likely transient in nature, such as a temporary inability to is likely transient in nature, such as a temporary inability to
retrieve a public key. A later attempt may produce a final retrieve a public key. A later attempt may produce a final
result. result.
permerror: The message could not be verified due to some error that permerror: The message could not be verified due to some error that
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,
however, represents one of the tags found in the DKIM-Signature
header field rather than a distinct header field. For example, the
ptype-property combination "header.d" refers to the content of the
"d" (signing domain) tag from within the signature header field, and
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.
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
skipping to change at page 17, line 44 skipping to change at page 18, line 6
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 Similarly, the results for Sender ID are listed and described in
Section 4.2 of [SENDERID], which in turn uses the SPF definitions Section 4.2 of [SENDERID], which in turn uses the SPF definitions
that now appear in [SPF]. that now appear in [SPF].
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
"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 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
skipping to change at page 18, line 43 skipping to change at page 19, line 10
data are published for the connecting IP address, e.g., a DNS data are published for the connecting IP address, e.g., a DNS
RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR) RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR)
in a reply containing no answers, was returned. This prevented in a reply containing no answers, was returned. This prevented
completion of the evaluation. A later attempt is unlikely to completion of the evaluation. A later attempt is unlikely to
produce a final result. produce a final result.
There is no "none" for this method since any TCP connection There is no "none" for this method since any TCP connection
delivering email has an IP address associated with it, so some kind delivering email has an IP address associated with it, so some kind
of evaluation will always be possible. of evaluation will always be possible.
The result is reported using a ptype of "policy" (as this is not part
of any established protocol) and a property of "iprev".
For discussion of the format of DNS replies, see "Domain Names - For discussion of the format of DNS replies, see "Domain Names -
Implementation and Specification" ([DNS]). Implementation and Specification" ([DNS]).
2.7.4. SMTP AUTH 2.7.4. SMTP AUTH
SMTP AUTH (defined in [AUTH]) is represented by the "auth" method, SMTP AUTH (defined in [AUTH]) is represented by the "auth" method,
and its result values are as follows: and its result values are as follows:
none: SMTP authentication was not attempted. none: SMTP authentication was not attempted.
skipping to change at page 19, line 27 skipping to change at page 19, line 43
attempt due to some error that is likely transient in nature, such attempt due to some error that is likely transient in nature, such
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
of "mailfrom", and the reported value is the value of the AUTH
parameter to that command.
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 for Vouch By Result codes were also registered in other RFCs as follows:
Reference (in [AR-VBR], represented by "vbr"), Authorized Third-Party
Signatures (in [ATPS], represented by "dkim-atps"), and the DKIM- o Vouch By Reference (in [AR-VBR], represented by "vbr");
related Author Domain Signing Practices (in [ADSP], represented by
"dkim-adsp"). o Authorized Third-Party Signatures (in [ATPS], represented by
"dkim-atps");
o Author Domain Signing Practices (in [ADSP], represented by "dkim-
adsp");
o Require-Recipient-Valid-Since (in [RRVS], represented by "rrvs");
o S/MIME (in [SMIME-REG], represented by "smime").
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 25, line 50 skipping to change at page 26, line 32
MTA MUST remove such a header field if the [SMTP] connection relaying MTA MUST remove such a header field if the [SMTP] connection relaying
the message is not from a trusted internal MTA. This means the MTA the message is not from a trusted internal MTA. This means the MTA
needs to be able to understand versions of this header field at least needs to be able to understand versions of this header field at least
as late as the ones understood by the MUAs or other consumers within as late as the ones understood by the MUAs or other consumers within
its ADMD. its ADMD.
6. IANA Considerations 6. IANA Considerations
IANA has registered the defined header field and created two tables IANA has registered the defined header field and created two tables
as described below. These registry actions were originally defined as described below. These registry actions were originally defined
by [RFC5451] and are repeated here to provide a single, current by [RFC5451] and updated by [RFC6577] and [RFC7001]. The created
reference. registries are being further updated here to increase their
completeness.
6.1. The Authentication-Results Header Field 6.1. The Authentication-Results Header Field
[RFC5451] added the Authentication-Results header field to the IANA [RFC5451] added the Authentication-Results header field to the IANA
"Permanent Message Header Field Names" registry, per the procedure "Permanent Message Header Field Names" registry, per the procedure
found in [IANA-HEADERS]. That entry has been updated to reference found in [IANA-HEADERS]. That entry is to be updated to reference
this document. The following is the registration template: this document. The following is the registration template:
Header field name: Authentication-Results Header field name: Authentication-Results
Applicable protocol: mail ([MAIL]) Applicable protocol: mail ([MAIL])
Status: Standard Status: Standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [this RFC] Specification document(s): [this RFC]
Related information: Related information:
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 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. A registry was experimental names as described in Section 2.7.6. Along with each
created by [RFC5451] for this purpose. [RFC7001] amended ther rules method is recorded the properties that accompany the method's result.
A registry was created by [RFC5451] for this purpose. [RFC6577]
added a "status" field for each entry. [RFC7001] amended the rules
governing that registry, and also added a "version" field to the governing that registry, and also added a "version" field to the
registry. 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 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".
Each method must register a name, the specification that defines it, No two entries can have the same combination of method, ptype, and
a version number associated with the method being registered property.
(preferably starting at "1"), zero or more "ptype" values appropriate
for use with that method, which "property" value(s) should be
reported by that method, and a description of the "value" to be used
with each.
All existing registry entries that reference [RFC7001] are to be An entry in this registry contains the following:
updated to reference this document, except where entries have already
been deprecated.
6.3. "Email Authentication Result Names" Registry Method: the name of the method;
Defined: a reference to the document that created this entry, if any
(see below);
ptype: a "ptype" value appropriate for use with that method;
property: a "property" value matching that "ptype" also appropriate
for use with that method;
Value: a brief description of the value to be supplied with that
method/ptype/property tuple;
Status: the status of this entry, which is either:
active: The entry is in current use.
deprecated: The entry is no longer in current use.
Version: a version number associated with the method (preferably
starting at "1").
The "Defined" field will typically refer to a permanent document, or
at least some descriptive text, where additional information about
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
around creating or interpreting an Authentication-Results header
field using this method, ptype, and property can be understood.
6.3. "Email Authentication Methods" Registry Update
The following changes are to be made to this registry upon approval
of this document:
1. The sole entry for the "auth" method shall have its "property"
field changed to "mailfrom", and its "Defined" field changed to
this document.
2. All "dkim", "domainkeys", "iprev", "sender-id", and "spf" method
entries shall have their "Defined" fields changed to this
document.
6.4. "Email Authentication Result Names" Registry
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. [RFC7001] updated the rules created by [RFC5451] for this purpose. [RFC6577] added the "status"
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 All existing registry entries that reference [RFC7001] are to be
updated to reference this document. updated to reference this document.
The definitions for the SPF and Sender ID authentication methods are The definitions for the SPF and Sender ID authentication methods are
updated using the references found in Section 2.7.2. to be updated using the references found in Section 2.7.2.
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 32, line 36 skipping to change at page 34, line 15
RFC 6541, February 2012. RFC 6541, February 2012.
[AUTH] Siemborski, R. and A. Melnikov, "SMTP Service [AUTH] Siemborski, R. and A. Melnikov, "SMTP Service
Extension for Authentication", RFC 4954, Extension for Authentication", RFC 4954,
July 2007. July 2007.
[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, [DKIM] Crocker, D., Hansen, T., and M. Kucherawy,
"DomainKeys Identified Mail (DKIM) "DomainKeys Identified Mail (DKIM)
Signatures", STD 76, RFC 6376, September 2011. Signatures", STD 76, RFC 6376, September 2011.
[DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed.,
"Domain-based Message Authentication,
Reporting and Conformance (DMARC)",
I-D draft-kucherawy-dmarc-base, February 2015.
[DNS] Mockapetris, P., "Domain names - [DNS] Mockapetris, P., "Domain names -
Implementation and Specification", STD 13, Implementation and Specification", STD 13,
RFC 1035, November 1987. RFC 1035, November 1987.
[DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M.
Souissi, "DNS Extensions to Support IP Version Souissi, "DNS Extensions to Support IP Version
6", RFC 3596, October 2003. 6", RFC 3596, October 2003.
[DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for [DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for
the use of DNS Reverse Mapping", Work the use of DNS Reverse Mapping", Work
skipping to change at page 33, line 20 skipping to change at page 35, line 5
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 5226, May 2008. RFCs", BCP 26, RFC 5226, May 2008.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL
- VERSION 4rev1", RFC 3501, March 2003. - VERSION 4rev1", RFC 3501, March 2003.
[POP3] Myers, J. and M. Rose, "Post Office Protocol - [POP3] Myers, J. and M. Rose, "Post Office Protocol -
Version 3", STD 53, RFC 1939, May 1996. Version 3", STD 53, RFC 1939, May 1996.
[PRA] Lyon, J., "Purported Responsible Address in
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.
[RFC6577] Kucherawy, M., "Authentication-Results
Registration Update for Sender Policy
Framework (SPF) Results", RFC 6577,
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-
Recipient-Valid-Since Header Field and SMTP
Service Extension", RFC 7293, July 2014.
[SECURITY] Rescorla, E. and B. Korver, "Guidelines for [SECURITY] Rescorla, E. and B. Korver, "Guidelines for
Writing RFC Text on Security Considerations", Writing RFC Text on Security Considerations",
BCP 72, RFC 3552, July 2003. BCP 72, RFC 3552, July 2003.
[SENDERID] Lyon, J. and M. Wong, "Sender ID: [SENDERID] Lyon, J. and M. Wong, "Sender ID:
Authenticating E-Mail", RFC 4406, April 2006. Authenticating E-Mail", RFC 4406, April 2006.
[SMIME-REG] Melnikov, A., "Authentication-Results
Registration for S/MIME Signature
Verification", RFC 7281, June 2014.
[SPF] Kitterman, S., "Sender Policy Framework (SPF) [SPF] Kitterman, S., "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, for Authorizing Use of Domains in E-Mail,
Version 1", RFC 7208, April 2014. Version 1", RFC 7208, April 2014.
[VBR] Hoffman, P., Levine, J., and A. Hathcock, [VBR] Hoffman, P., Levine, J., and A. Hathcock,
"Vouch By Reference", RFC 5518, April 2009. "Vouch By Reference", RFC 5518, April 2009.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The author wishes to acknowledge the following individuals for their The author wishes to acknowledge the following individuals for their
review and constructive criticism of this document: (names) review and constructive criticism of this document: Stephane
Bortzmeyer, Scott Kitterman, John Levine, and Tom Petch.
Appendix B. Legacy MUAs Appendix B. Legacy MUAs
Implementers of this protocol should be aware that many MUAs are Implementers of this protocol should be aware that many MUAs are
unlikely to be retrofitted to support the new header field and its unlikely to be retrofitted to support the new header field and its
semantics. In the interests of convenience and quicker adoption, a semantics. In the interests of convenience and quicker adoption, a
delivery MTA might want to consider adding things that are processed delivery MTA might want to consider adding things that are processed
by existing MUAs in addition to the Authentication-Results header by existing MUAs in addition to the Authentication-Results header
field. One suggestion is to include a Priority header field, on field. One suggestion is to include a Priority header field, on
messages that don't already have such a header field, containing a messages that don't already have such a header field, containing a
skipping to change at page 44, line 19 skipping to change at page 46, line 19
o Update all the RFC4408 references to RFC7208. o Update all the RFC4408 references to RFC7208.
o Add section explaining "property" values. (Errata #4201) o Add section explaining "property" values. (Errata #4201)
o Remove "To-Do" section. o Remove "To-Do" section.
E.3. -01 to -02 E.3. -01 to -02
o Consolidate new sections. o Consolidate new sections.
E.4. -02 to -03
o Move the DKIM exception text down to where the DKIM results are
defined, and add a forward reference to them.
o More detail about registry creation and previous augmentations.
o Add text explaining each of the method-ptype-property tuples
registered by this document.
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
expected that this will then refer to the method's defining
document. Provide IANA with corresponding update instructions.
o Add references: [DMARC], [PRA], [RFC6577], [RRVS], [SMIME-REG].
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. 34 change blocks. 
77 lines changed or deleted 190 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/