draft-ietf-appsawg-rfc7001bis-11.txt   rfc7601.txt 
Individual submission M. Kucherawy Internet Engineering Task Force (IETF) M. Kucherawy
Internet-Draft June 4, 2015 Request for Comments: 7601 August 2015
Obsoletes: 7001, 7410 Obsoletes: 7001, 7410
(if approved) Category: Standards Track
Intended status: Standards Track ISSN: 2070-1721
Expires: December 6, 2015
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-appsawg-rfc7001bis-11
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 6, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7601.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . 5
1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 6 1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . 6
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7 1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 6
1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 7 1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . 7
1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 8 1.5.3. Email Architecture . . . . . . . . . . . . . . . . . 7
1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 9 1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 8
1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 9 1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 8
2. Definition and Format of the Header Field . . . . . . . . . . 9 2. Definition and Format of the Header Field . . . . . . . . . . 9
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 . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . 18
2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 20
2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 21 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . 21
2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21
2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 22 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . 22
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22
4. Adding the Header Field to a Message . . . . . . . . . . . . . 23 4. Adding the Header Field to a Message . . . . . . . . . . . . 23
4.1. Header Field Position and Interpretation . . . . . . . . . 25 4.1. Header Field Position and Interpretation . . . . . . . . 25
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 26 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . 26
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.1. The Authentication-Results Header Field . . . . . . . . . 27 6.1. The Authentication-Results Header Field . . . . . . . . . 27
6.2. "Email Authentication Methods" Registry Description . . . 28 6.2. "Email Authentication Methods" Registry Description . . . 28
6.3. "Email Authentication Methods" Registry Update . . . . . . 29 6.3. "Email Authentication Methods" Registry Update . . . . . 29
6.4. "Email Authentication Property Types" Registry . . . . . . 30 6.4. "Email Authentication Property Types" Registry . . . . . 30
6.5. "Email Authentication Result Names" Description . . . . . 31 6.5. "Email Authentication Result Names" Description . . . . . 31
6.6. "Email Authentication Result Names" Update . . . . . . . . 32 6.6. "Email Authentication Result Names" Update . . . . . . . 32
6.7. SMTP Enhanced Status Codes . . . . . . . . . . . . . . . . 33 6.7. SMTP Enhanced Status Codes . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 33 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 33
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 35 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . 35
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 35 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 35
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 35 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . 35
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 35 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 36
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 36 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . 36
7.7. Attacks against Authentication Methods . . . . . . . . . . 36 7.7. Attacks against Authentication Methods . . . . . . . . . 36
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 36 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 36
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 36 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . 36
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 36 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . 37
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 37 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 40 Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . 42
Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 40 Appendix B. Authentication-Results Examples . . . . . . . . . . 42
Appendix C. Authentication-Results Examples . . . . . . . . . . . 40 B.1. Trivial Case; Header Field Not Present . . . . . . . . . 42
C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 41 B.2. Nearly Trivial Case; Service Provided, but No
C.2. Nearly Trivial Case; Service Provided, but No Authentication Done . . . . . . . . . . . . . . . . . . . 43
Authentication Done . . . . . . . . . . . . . . . . . . . 41 B.3. Service Provided, Authentication Done . . . . . . . . . . 44
C.3. Service Provided, Authentication Done . . . . . . . . . . 42 B.4. Service Provided, Several Authentications Done, Single
C.4. Service Provided, Several Authentications Done, Single MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 B.5. Service Provided, Several Authentications Done, Different
C.5. Service Provided, Several Authentications Done, MTAs . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 44 B.6. Service Provided, Multi-tiered Authentication Done . . . 48
C.6. Service Provided, Multi-Tiered Authentication Done . . . . 46 B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 49
C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 47 Appendix C. Operational Considerations about Message
Appendix D. Operational Considerations about Message Authentication . . . . . . . . . . . . . . . . . . . 50
Authentication . . . . . . . . . . . . . . . . . . . 48 Appendix D. Changes since RFC 7001 . . . . . . . . . . . . . . . 51
Appendix E. Change Since RFC7001 . . . . . . . . . . . . . . . . 49 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53
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/
and/or provide a recommendation to the user as to the validity of the or provide a recommendation to the user as to the validity of the
message's origin and possibly the safety and integrity of its message's origin and possibly the safety and integrity of its
content. content.
This document revises the original definition found in [RFC5451] This document revises the original definition found in [RFC5451]
based upon various authentication protocols in current use and based upon various authentication protocols in current use and
incorporates errata logged since the publication of the original incorporates errata logged since the publication of the original
specification. specification.
End users are not expected to be direct consumers of this header End users are not expected to be direct consumers of this header
field. This header field is intended for consumption by programs field. This header field is intended for consumption by programs
skipping to change at page 5, line 15 skipping to change at page 4, line 41
o S/MIME Signature Verification ([SMIME-REG]) o S/MIME Signature Verification ([SMIME-REG])
o Vouch By Reference ([VBR]) o Vouch By Reference ([VBR])
o DomainKeys ([DOMAINKEYS]) (Historic) o DomainKeys ([DOMAINKEYS]) (Historic)
o Sender ID ([SENDERID]) (Experimental) o Sender ID ([SENDERID]) (Experimental)
There exist registries for tokens used within this header field that There exist registries for tokens used within this header field that
refer to the specifications listed above. Section 6 describes the refer to the specifications listed above. Section 6 describes the
registries and their contents, and specifies the process by which registries and their contents and specifies the process by which
entries are added or updated. It also updates the existing contents entries are added or updated. It also updates the existing contents
to match the current states of these specifications. to match the current states of these specifications.
This specification is not intended to be restricted to domain-based This specification is not intended to be restricted to domain-based
authentication schemes, but the existing schemes in that family have authentication schemes, but the existing schemes in that family have
proven to be a good starting point for implementations. The goal is proven to be a good starting point for implementations. The goal is
to give current and future authentication schemes a common framework to give current and future authentication schemes a common framework
within which to deliver their results to downstream agents and within which to deliver their results to downstream agents and
discourage the creation of unique header fields for each. discourage the creation of unique header fields for each.
skipping to change at page 8, line 28 skipping to change at page 8, line 8
o A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA that o A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA that
actually enacts delivery of a message to a user's inbox or other actually enacts delivery of a message to a user's inbox or other
final delivery. final delivery.
o An "intermediate MTA" is any MTA that is not a delivery MTA and is o An "intermediate MTA" is any MTA that is not a delivery MTA and is
also not the first MTA to handle the message. also not the first MTA to handle the message.
The following diagram illustrates the flow of mail among these The following diagram illustrates the flow of mail among these
defined components. See Internet Mail Architecture [EMAIL-ARCH] for defined components. See Internet Mail Architecture [EMAIL-ARCH] for
further discussion on general email system architecture, which further discussion on general email system architecture, which
includes detailed descriptions of these components, and Appendix D of includes detailed descriptions of these components, and Appendix C of
this document for discussion about the common aspects of email this document for discussion about the common aspects of email
authentication in current environments. authentication in current environments.
+-----+ +-----+ +------------+ +-----+ +-----+ +------------+
| MUA |-->| MSA |-->| Border MTA | | MUA |-->| MSA |-->| Border MTA |
+-----+ +-----+ +------------+ +-----+ +-----+ +------------+
| |
| |
V V
+----------+ +----------+
skipping to change at page 12, line 17 skipping to change at page 11, line 48
The "value" is as defined in Section 5.1 of [MIME]. The "value" is as defined in Section 5.1 of [MIME].
The "domain-name" is as defined in Section 3.5 of [DKIM]. The "domain-name" is as defined in Section 3.5 of [DKIM].
The "Keyword" used in "result" above is further constrained by the The "Keyword" used in "result" above is further constrained by the
necessity of being enumerated in Section 2.7. necessity of being enumerated in Section 2.7.
See Section 2.5 for a description of the authserv-id element. See Section 2.5 for a description of the authserv-id element.
If the value portion of a "pvalue" construction identifies something If the value portion of a "pvalue" construction identifies something
intended to be an e-mail identity, then it MUST use the right hand intended to be an email identity, then it MUST use the right hand
portion of that ABNF definition. portion of that ABNF definition.
The list of commands eligible for use with the "smtp" ptype can be The list of commands eligible for use with the "smtp" ptype can be
found in Section 4.1 of [SMTP]. found in Section 4.1 of [SMTP].
The "propspec" may be omitted if, for example, the method was unable The "propspec" may be omitted if, for example, the method was unable
to extract any properties to do its evaluation yet has a result to to extract any properties to do its evaluation yet has a result to
report. report.
Where an SMTP command name is being reported as a "property", the Where an SMTP command name is being reported as a "property", the
agent generating the header field represents that command by agent generating the header field represents that command by
converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" converting it to lowercase and dropping any spaces (e.g., "MAIL FROM"
becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.).
A "ptype" value of "policy" indicates a policy decision about the A "ptype" value of "policy" indicates a policy decision about the
message not specific to a property of the message that could be message not specific to a property of the message that could be
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 B.
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 indicate from which particular part of the message the specific, they indicate from which particular part of the message the
reported 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 [RFC7410]. The
[PTYPES-REGISTRY]. The initial values and what they typically initial values and what they typically indicate are as follows, based
indicate are as follows, copied from [RFC7001]: on [RFC7001]:
body: Information that was extracted from the body of the message. body: Information that was extracted from the body of the message.
This might be an arbitrary string of bytes, a hash of a string of This might be an arbitrary string of bytes, a hash of a string of
bytes, a Uniform Resource Identifier, or some other content of bytes, a Uniform Resource Identifier, or some other content of
interest. The "property" is an indication of where within the interest. The "property" is an indication of where within the
message body the extracted content was found, and can indicate an message body the extracted content was found, and can indicate an
offset, identify a MIME part, etc. offset, identify a MIME part, etc.
header: Indicates information that was extracted from the header of header: Indicates information that was extracted from the header of
the message. This might be the value of a header field or some the message. This might be the value of a header field or some
skipping to change at page 17, line 21 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".
The ability to report different DKIM results for a multiply-signed The ability to report different DKIM results for a message with
message is described in [RFC6008]. multiple signatures is described in [RFC6008].
[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 Section 3.1 of [DOMAINKEYS] describes a process by which the sending
address of the message is determined. DomainKeys results are thus address of the message is determined. DomainKeys results are thus
reported along with the signing domain name, the sending address of reported along with the signing domain name, the sending address of
skipping to change at page 18, line 16 skipping to change at page 18, line 22
| Code | Meaning | | Code | Meaning |
+-----------+--------------------------------+ +-----------+--------------------------------+
| none | [RFC7208], Section 2.6.1 | | none | [RFC7208], Section 2.6.1 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| pass | [RFC7208], Section 2.6.3 | | pass | [RFC7208], Section 2.6.3 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| fail | [RFC7208], Section 2.6.4 | | fail | [RFC7208], Section 2.6.4 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| softfail | [RFC7208], Section 2.6.5 | | softfail | [RFC7208], Section 2.6.5 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| policy | [this RFC], Section 2.4 | | policy | RFC 7601, Section 2.4 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| neutral | [RFC7208], Section 2.6.2 | | neutral | [RFC7208], Section 2.6.2 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| 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.
For SPF, the ptype used is "smtp", and the property is either For SPF, the ptype used is "smtp", and the property is either
"mailfrom" or "helo", since those values are the ones SPF can "mailfrom" or "helo", since those values are the ones SPF can
evaluate. (If the SMTP client issued the EHLO command instead of evaluate. (If the SMTP client issued the EHLO command instead of
HELO, the property used is "helo".) HELO, the property used is "helo".)
The "sender-id" method is described in [SENDERID]. For this method, 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 the ptype used is "header" and the property will be the name of the
header field from which the Purported Responsible address (see [PRA]) header field from which the Purported Responsible Address (see [PRA])
was extracted, namely one of "Resent-Sender", "Resent-From", was extracted -- namely, one of "Resent-Sender", "Resent-From",
"Sender", or "From". "Sender", or "From".
The results for Sender ID are listed and described in Section 4.2 of The results for Sender ID are listed and described in Section 4.2 of
[SENDERID], but for the purposes of this specification, the SPF [SENDERID], but for the purposes of this specification, the SPF
definitions enumerated above are used instead. Also, [SENDERID] definitions enumerated above are used instead. Also, [SENDERID]
specifies result codes that use mixed case, but they are typically specifies result codes that use mixed case, but they are typically
used all lowercase in this context. used all lowercase in this context.
For both methods, an additional result of "policy" is defined, which For both methods, 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
skipping to change at page 20, line 42 skipping to change at page 20, line 50
o "mailfrom", in which case the value is the mailbox identified by o "mailfrom", in which case the value is the mailbox identified by
the AUTH parameter used with the MAIL FROM command. the AUTH parameter used with the MAIL FROM command.
If both identities are available, both can be reported. For example, If both identities are available, both can be reported. For example,
consider this command issued by a client that has completed session consider this command issued by a client that has completed session
authentication with the AUTH command resulting in an authorized authentication with the AUTH command resulting in an authorized
identity of "client@c.example": identity of "client@c.example":
MAIL FROM:<alice@a.example> AUTH=<bob@b.example> MAIL FROM:<alice@a.example> AUTH=<bob@b.example>
This could result in a resinfo construction like so: This could result in a "resinfo" construction like so:
; auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example ; auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example
Note that in all cases other than "pass", the message was sent by an Note that in all cases other than "pass", the message was sent by an
unauthenticated client. All non-"pass" cases SHOULD thus be treated unauthenticated client. All non-"pass" cases SHOULD thus be treated
as equivalent with respect to this method. as equivalent with respect to this method.
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:
skipping to change at page 25, line 12 skipping to change at page 25, line 16
users such information if it is presented by a method known not to users such information if it is presented by a method known not to
authenticate it. authenticate it.
4.1. Header Field Position and Interpretation 4.1. Header Field Position and Interpretation
In order to ensure non-ambiguous results and avoid the impact of In order to ensure non-ambiguous results and avoid the impact of
false header fields, MUAs and downstream filters SHOULD NOT interpret false header fields, MUAs and downstream filters SHOULD NOT interpret
this header field unless specifically configured to do so by the user this header field unless specifically configured to do so by the user
or administrator. That is, this interpretation should not be "on by or administrator. That is, this interpretation should not be "on by
default". Naturally then, users or administrators ought not activate default". Naturally then, users or administrators ought not activate
such a feature unless they are certain the header field will be such a feature unless (1) they are certain the header field will be
validly added by an agent within the ADMD that accepts the mail that validly added by an agent within the ADMD that accepts the mail that
is ultimately read by the MUA, and instances of the header field is ultimately read by the MUA, and (2) instances of the header field
appearing to originate within the ADMD but are actually added by that appear to originate within the ADMD but are actually added by
foreign MTAs will be removed before delivery. foreign MTAs will be removed before delivery.
Furthermore, MUAs and downstream filters SHOULD NOT interpret this Furthermore, MUAs and downstream filters SHOULD NOT interpret this
header field unless the authentication service identifier it bears header field unless the authentication service identifier it bears
appears to be one used within its own ADMD as configured by the user appears to be one used within its own ADMD as configured by the user
or administrator. or administrator.
MUAs and downstream filters MUST ignore any result reported using a MUAs and downstream filters MUST ignore any result reported using a
"result" not specified in the IANA "Result Code" registry or a "result" not specified in the IANA "Result Code" registry or a
"ptype" not listed in the corresponding registry for such values as "ptype" not listed in the "Email Authentication Property Types"
defined in Section 6. Moreover, such agents MUST ignore a result registry for such values as defined in Section 6. Moreover, such
indicated for any "method" they do not specifically support. agents MUST ignore a result indicated for any "method" they do not
specifically support.
An MUA SHOULD NOT reveal these results to end users, absent careful An MUA SHOULD NOT reveal these results to end users, absent careful
human factors design considerations and testing, for the presentation human factors design considerations and testing, for the presentation
of trust-related materials. For example, an attacker could register of trust-related materials. For example, an attacker could register
examp1e.com (note the digit "one") and send signed mail to intended examp1e.com (note the digit "1" (one)) and send signed mail to
victims; a verifier would detect that the signature was valid and intended victims; a verifier would detect that the signature was
report a "pass" even though it's clear the DNS domain name was valid and report a "pass" even though it's clear the DNS domain name
intended to mislead. See Section 7.2 for further discussion. was intended to mislead. See Section 7.2 for further discussion.
As stated in Section 2.1, this header field MUST be treated as though As stated in Section 2.1, this header field MUST be treated as though
it were a trace header field as defined in Section 3.6.7 of [MAIL] it were a trace header field as defined in Section 3.6.7 of [MAIL]
and hence MUST NOT be reordered and MUST be prepended to the message, and hence MUST NOT be reordered and MUST be prepended to the message,
so that there is generally some indication upon delivery of where in so that there is generally some indication upon delivery of where in
the chain of handling MTAs the message authentication was done. the chain of handling MTAs the message authentication was done.
Note that there are a few message handlers that are only capable of Note that there are a few message handlers that are only capable of
appending new header fields to a message. Strictly speaking, these appending new header fields to a message. Strictly speaking, these
handlers are not compliant with this specification. They can still handlers are not compliant with this specification. They can still
skipping to change at page 27, line 11 skipping to change at page 27, line 18
As stated in Section 1.2, a formal definition of "trust boundary" is As stated in Section 1.2, a formal definition of "trust boundary" is
deliberately not made here. It is entirely possible that a border deliberately not made here. It is entirely possible that a border
MTA for example.com will explicitly trust authentication results MTA for example.com will explicitly trust authentication results
asserted by upstream host example.net even though they exist in asserted by upstream host example.net even though they exist in
completely disjoint administrative boundaries. In that case, the completely disjoint administrative boundaries. In that case, the
border MTA MAY elect not to delete those results; moreover, the border MTA MAY elect not to delete those results; moreover, the
upstream host doing some authentication work could apply a signing upstream host doing some authentication work could apply a signing
technology such as [DKIM] on its own results to assure downstream technology such as [DKIM] on its own results to assure downstream
hosts of their authenticity. An example of this is provided in hosts of their authenticity. An example of this is provided in
Appendix C. Appendix B.
Similarly, in the case of messages signed using [DKIM] or other Similarly, in the case of messages signed using [DKIM] or other
message-signing methods that sign header fields, this removal action message-signing methods that sign header fields, this removal action
could invalidate one or more signatures on the message if they could invalidate one or more signatures on the message if they
covered the header field to be removed. This behavior can be covered the header field to be removed. This behavior can be
desirable since there's little value in validating the signature on a desirable since there's little value in validating the signature on a
message with forged header fields. However, signing agents MAY message with forged header fields. However, signing agents MAY
therefore elect to omit these header fields from signing to avoid therefore elect to omit these header fields from signing to avoid
this situation. this situation.
skipping to change at page 27, line 42 skipping to change at page 27, line 49
IANA has registered the defined header field and created tables as IANA has registered the defined header field and created tables as
described below. These registry actions were originally defined by described below. These registry actions were originally defined by
[RFC5451] and updated by [RFC6577] and [RFC7001]. The created [RFC5451] and updated by [RFC6577] and [RFC7001]. The created
registries are being further updated here to increase their registries are being further updated here to increase their
completeness. 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 is to be updated to reference found in [IANA-HEADERS]. That entry has been 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): RFC 7601
Related information: none Related information: none
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 have been 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.
The "Email Authentication Parameters" group, and within it the "Email The "Email Authentication Parameters" group, and within it the "Email
Authentication Methods" registry, were created by [RFC5451] for this Authentication Methods" registry, were created by [RFC5451] for this
purpose. [RFC6577] added a "status" field for each entry. [RFC7001] purpose. [RFC6577] added a "status" field for each entry. [RFC7001]
amended the rules governing that registry, and also added a "version" amended the rules governing that registry and also added a "version"
field to the registry. field to the registry.
The reference for that registry shall be updated to reference this The reference for that registry has been updated to reference this
document. 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".
No two entries can have the same combination of method, ptype, and No two entries can have the same combination of method, ptype, and
property. property.
An entry in this registry contains the following: An entry in this registry contains the following:
Method: the name of the method; Method: the name of the method.
Definition: a reference to the document that created this entry, if Definition: a reference to the document that created this entry, if
any (see below); any (see below).
ptype: a "ptype" value appropriate for use with that method; ptype: a "ptype" value appropriate for use with that method.
property: a "property" value matching that "ptype" also appropriate property: a "property" value matching that "ptype" also appropriate
for use with that method; for use with that method.
Value: a brief description of the value to be supplied with that Value: a brief description of the value to be supplied with that
method/ptype/property tuple; method/ptype/property tuple.
Status: the status of this entry, which is either: Status: the status of this entry, which is either:
active: The entry is in current use. active: The entry is in current use.
deprecated: The entry is no longer in current use. deprecated: The entry is no longer in current use.
Version: a version number associated with the method (preferably Version: a version number associated with the method (preferably
starting at "1"). starting at "1").
The "Definition" field will typically refer to a permanent document, The "Definition" field will typically refer to a permanent document,
or at least some descriptive text, where additional information about or at least some descriptive text, where additional information about
the entry being added can be found. This might in turn reference the the entry being added can be found. This might in turn 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 have been made to this registry per this
of this document: document:
1. The "Defined" field shall be renamed to "Definition", to be 1. The "Defined" field has been renamed "Definition", to be
consistent with the other registries in this group. consistent with the other registries in this group.
2. The current entry for the "auth" method shall have its "property" 2. The entry for the "dkim" method, "header" ptype, and "b" property
field changed to "mailfrom", and its "Definition" field changed now reference [RFC6008] as the defining document, and the
to this document. reference has be removed from the description.
3. The entry for the "dkim" method, "header" ptype and "b" property
shall now reference [RFC6008] as its defining document, and the
reference shall be removed from the description.
4. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf" 3. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf"
method entries shall have their "Definition" fields changed to method entries have had their "Definition" fields changed to
this document, as this document contains a complete description refer to this document, as this document contains a complete
of the registry and these corresponding values. description of the registry and these corresponding values.
5. All "smime" entries have their "Definition" fields changed to 4. All "smime" entries have had their "Definition" fields changed to
[SMIME-REG]. [SMIME-REG].
6. The "value" field of the "smime" entry using property "smime- 5. The "value" field of the "smime" entry using property "smime-
part" shall be changed to read: "The MIME body part reference part" has been changed to read: "The MIME body part reference
that contains the S/MIME signature. See Section 3.2.1 of RFC7281 that contains the S/MIME signature. See Section 3.2.1 of RFC
for full syntax." 7281 for full syntax."
7. The following entry is to be added: 6. The single entry for the "auth" method was intended to reflect
the identity indicated by the "AUTH" parameter to the SMTP "MAIL
FROM" command verb. However, there is also an "AUTH" command
verb. To clarify this ambiguity, the entry for the "auth" method
has had its "property" field changed to "mailfrom", and its
"Definition" field changed to this document.
7. The following entry has been added:
Method: auth Method: auth
Definition: [this document] Definition: this document (RFC 7601)
ptype: smtp ptype: smtp
property: auth property: auth
Value: identity confirmed by the AUTH command Value: identity confirmed by the AUTH command
Status: active Status: active
Version: 1 Version: 1
8. The values of the "domainkeys" entries for ptype "header" are 8. The values of the "domainkeys" entries for ptype "header" have
updated as follows: been updated as follows:
from: contents of the [MAIL] From: header field, after removing from: contents of the [MAIL] From: header field, after removing
comments, and removing the local-part and following "@" if not comments, and removing the local-part and following "@" if not
authenticated authenticated
sender: contents of the [MAIL] Sender: header field, after sender: contents of the [MAIL] Sender: header field, after
removing comments, and removing the local-part and following removing comments, and removing the local-part and following
"@" if not authenticated "@" if not authenticated
9. All entries for "dkim-adsp" and "domainkeys" shall have their 9. For all entries for "dkim-adsp" and "domainkeys", their Status
Status values changed to "deprecated", reflecting the fact that values have been changed to "deprecated", reflecting the fact
the corresponding specifications now have Historical status. that the corresponding specifications now have Historic status.
Their "Definition" fields shall also be modified to include a Their "Definition" fields have also been modified to include a
reference to this document. reference to this document.
6.4. "Email Authentication Property Types" Registry 6.4. "Email Authentication Property Types" Registry
[PTYPES-REGISTRY] created the Email Authentication Property Types [RFC7410] created the "Email Authentication Property Types" registry.
registry.
Entries in this registry are subject to the Expert Review rules as Entries in this registry are subject to the Expert Review rules as
described in [IANA-CONSIDERATIONS]. Each entry in the registry described in [IANA-CONSIDERATIONS]. Each entry in the registry
requires the following values: requires the following values:
ptype: The name of the ptype being registered, which must fit within ptype: The name of the ptype being registered, which must fit within
the ABNF described in Section 2.2. the ABNF described in Section 2.2.
Definition: An optional reference to a defining specification. Definition: An optional reference to a defining specification.
Description: A brief description of what sort of information this Description: A brief description of what sort of information this
"ptype" is meant to cover. "ptype" is meant to cover.
For new entries, the Designated Expert needs to assure that the For new entries, the Designated Expert needs to assure that the
description provided for the new entry adequately describes the description provided for the new entry adequately describes the
intended use. An example would be helpful to include in the entry's intended use. An example would be helpful to include in the entry's
defining document, if any, although entries in the "Email defining document, if any, although entries in the "Email
Authentication Methods" registry or the "Email Authentication Result Authentication Methods" registry or the "Email Authentication Result
Names" registry might also serve as examples of intended use. Names" registry might also serve as examples of intended use.
As this is a complete re-statement of the definition and rules for As this is a complete restatement of the definition and rules for
this registry, IANA shall update this registry to show Section 2.3 of this registry, IANA has updated this registry to show Section 2.3 of
this document as the current definitions for the "body", "header", this document as the current definitions for the "body", "header",
"policy" and "smtp" entries of that registry. References to "policy", and "smtp" entries of that registry. References to
[RFC7001] shall be removed. [RFC7001] and [RFC7410] have been removed.
6.5. "Email Authentication Result Names" Description 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".
No two entries can have the same combination of method and code. No two entries can have the same combination of method and code.
An entry in this registry contains the following: An entry in this registry contains the following:
Auth Method: an authentication method for which results are being Auth Method: an authentication method for which results are being
returned using the header field defined in this document; returned using the header field defined in this document.
Code: a result code that can be returned for this authentication Code: a result code that can be returned for this authentication
method; method.
Specification: either free form text explaining the meaning of this Specification: either free form text explaining the meaning of this
method-code combination, or a reference to such a definition. method-code combination, or a reference to such a definition.
Status: the status of this entry, which is either: Status: the status of this entry, which is either:
active: The entry is in current use. active: The entry is in current use.
deprecated: The entry is no longer in current use. deprecated: The entry is no longer in current use.
6.6. "Email Authentication Result Names" Update 6.6. "Email Authentication Result Names" Update
This document includes a complete description of the registry, This document includes a complete description of the registry,
obsoleting [RFC7001]. Accordingly, the following changes are to be obsoleting [RFC7001]. Accordingly, the following changes have been
made to this registry on publication of this document: made to this registry per this document:
o The "Defined" field shall be removed. o The "Defined" field has been removed.
o The "Meaning" field shall be renamed to "Specification", as o The "Meaning" field has been renamed "Specification", as described
described above. above.
o The "Auth Method" field shall appear before the "Code" field. o The "Auth Method" field now appears before the "Code" field.
o For easier searching, the table shall be arranged such that it is o For easier searching, the table has been arranged such that it is
sorted first by Auth Method, then by Code within each Auth Method sorted first by Auth Method, then by Code within each Auth Method
grouping. grouping.
o All entries for the "dkim", "domainkeys", "spf", "sender-id", o All entries for the "dkim", "domainkeys", "spf", "sender-id",
"auth", and "iprev" methods shall have their "Specification" "auth", and "iprev" methods have had their "Specification" fields
fields replaced as follows: replaced as follows:
dkim: [this document] Section 2.7.1 dkim: Section 2.7.1 of this document (RFC 7601)
domainkeys: [this document] Section 2.7.1 domainkeys: Section 2.7.1 of this document (RFC 7601)
spf: for "hardfail", [RFC5451] Section 2.4.2; for all others, spf: for "hardfail", Section 2.4.2 of [RFC5451]; for all others,
[this document] Section 2.7.2 Section 2.7.2 of this document (RFC 7601)
sender-id: for "hardfail", [RFC5451] Section 2.4.2; for all sender-id: for "hardfail", Section 2.4.2 of [RFC5451]; for all
others, [this document] Section 2.7.2 others, Section 2.7.2 of this document (RFC 7601)
auth: [this document] Section 2.7.4 auth: Section 2.7.4 of this document (RFC 7601)
iprev: [this document] Section 2.7.3 iprev: Section 2.7.3 of this document (RFC 7601)
o All entries for "dkim-adsp" that are missing an explicit reference o All entries for "dkim-adsp" that were missing an explicit
to a defining document shall have [ADSP] added to their reference to a defining document now reference [ADSP] in their
"Specification" fields. "Specification" fields.
o All entries for "dmarc" shall have their "Specification" fields o All entries for "dmarc" have had their "Specification" fields
changed to reference Secton 11.2 of [DMARC]. changed to reference Section 11.2 of [DMARC].
o All entries for "dkim-adsp" and "domainkeys" shall have their o All entries for "dkim-adsp" and "domainkeys" have had their Status
Status values changed to "deprecated", reflecting the fact that values changed to "deprecated", reflecting the fact that the
the corresponding specifications now have Historical status. corresponding specifications now have Historic status. Their
Their "Specification" fields shall also be modified to include a "Specification" fields have also been modified to include a
reference to this document. reference to this document.
6.7. SMTP Enhanced Status Codes 6.7. SMTP Enhanced Status Codes
The entry for X.7.25 in the Enumerated Status Codes sub-registry of The entry for X.7.25 in the "Enumerated Status Codes" sub-registry of
the SMTP Enhanced Status Codes registry is to be updated to refer to the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes
this document instead of [RFC7001]. Registry" has been updated to refer to this document instead of
[RFC7001].
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 34, line 46 skipping to change at page 35, line 6
Support for some of these is being considered for future work. Support for some of these is being considered for future work.
In any case, a mechanism needs to exist for an MUA or filter to In any case, a mechanism needs to exist for an MUA or filter to
verify that the host that appears to have added the header field (a) verify that the host that appears to have added the header field (a)
actually did so and (b) is legitimately adding that header field for actually did so and (b) is legitimately adding that header field for
this delivery. Given the variety of messaging environments deployed this delivery. Given the variety of messaging environments deployed
today, consensus appears to be that specifying a particular mechanism today, consensus appears to be that specifying a particular mechanism
for doing so is not appropriate for this document. for doing so is not appropriate for this document.
Mitigation of the forged header field attack can also be accomplished Mitigation of the forged header field attack can also be accomplished
by moving the authentication results data into meta-data associated by moving the authentication results data into metadata associated
with the message. In particular, an [SMTP] extension could be with the message. In particular, an [SMTP] extension could be
established to communicate authentication results from the border MTA established to communicate authentication results from the border MTA
to intermediate and delivery MTAs; the latter of these could arrange to intermediate and delivery MTAs; the latter of these could arrange
to store the authentication results as meta-data retrieved and to store the authentication results as metadata retrieved and
rendered along with the message by an [IMAP] client aware of a rendered along with the message by an [IMAP] client aware of a
similar extension in that protocol. The delivery MTA would be told similar extension in that protocol. The delivery MTA would be told
to trust data via this extension only from MTAs it trusts, and border to trust data via this extension only from MTAs it trusts, and border
MTAs would not accept data via this extension from any source. There MTAs would not accept data via this extension from any source. There
is no vector in such an arrangement for forgery of authentication is no vector in such an arrangement for forgery of authentication
data by an outside agent. data by an outside agent.
7.2. Misleading Results 7.2. Misleading Results
Until some form of service for querying the reputation of a sending Until some form of service for querying the reputation of a sending
skipping to change at page 37, line 27 skipping to change at page 37, line 34
"iprev" method, its value as an authentication mechanism is limited. "iprev" method, its value as an authentication mechanism is limited.
Implementers of both this proposal and agents that use the data it Implementers of both this proposal and agents that use the data it
relays are encouraged to become familiar with the issues raised by relays are encouraged to become familiar with the issues raised by
[DNSOP-REVERSE] when deciding whether or not to include support for [DNSOP-REVERSE] when deciding whether or not to include support for
"iprev". "iprev".
8. References 8. References
8.1. Normative References 8.1. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Syntax Specifications: ABNF", STD 68, Specifications: ABNF", STD 68, RFC 5234,
RFC 5234, January 2008. DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, [IANA-HEADERS]
"Registration Procedures for Message Header Klyne, G., Nottingham, M., and J. Mogul, "Registration
Fields", BCP 90, RFC 3864, September 2004. Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004,
<http://www.rfc-editor.org/info/rfc3864>.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Indicate Requirement Levels", BCP 14, Requirement Levels", BCP 14, RFC 2119,
RFC 2119. DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[MAIL] Resnick, P., Ed., "Internet Message Format", [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322,
RFC 5322, October 2008. DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[MIME] Freed, N. and N. Borenstein, "Multipurpose [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Internet Mail Extensions (MIME) Part One: Extensions (MIME) Part One: Format of Internet Message
Format of Internet Message Bodies", RFC 2045, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
November 1996. <http://www.rfc-editor.org/info/rfc2045>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
RFC 5321, October 2008. DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>.
8.2. Informative References 8.2. Informative References
[ADSP] Allman, E., Fenton, J., Delany, M., and J. [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine,
Levine, "DomainKeys Identified Mail (DKIM) "DomainKeys Identified Mail (DKIM) Author Domain Signing
Author Domain Signing Practices (ADSP)", Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617, August
RFC 5617, August 2009. 2009, <http://www.rfc-editor.org/info/rfc5617>.
[AR-VBR] Kucherawy, M., "Authentication-Results
Registration for Vouch by Reference Results",
RFC 6212, April 2011.
[ATPS] Kucherawy, M., "DomainKeys Identified Mail
(DKIM) Authorized Third-Party Signatures",
RFC 6541, February 2012.
[AUTH] Siemborski, R. and A. Melnikov, "SMTP Service [AR-VBR] Kucherawy, M., "Authentication-Results Registration for
Extension for Authentication", RFC 4954, Vouch by Reference Results", RFC 6212,
July 2007. DOI 10.17487/RFC6212, April 2011,
<http://www.rfc-editor.org/info/rfc6212>.
[AUTH-ESC] Kucherawy, M., "Email Authentication Status [ATPS] Kucherawy, M., "DomainKeys Identified Mail (DKIM)
Codes", RFC 7372, September 2014. Authorized Third-Party Signatures", RFC 6541,
DOI 10.17487/RFC6541, February 2012,
<http://www.rfc-editor.org/info/rfc6541>.
[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, [AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
"DomainKeys Identified Mail (DKIM) Extension for Authentication", RFC 4954,
Signatures", STD 76, RFC 6376, September 2011. DOI 10.17487/RFC4954, July 2007,
<http://www.rfc-editor.org/info/rfc4954>.
[DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., [AUTH-ESC]
"Domain-based Message Authentication, Kucherawy, M., "Email Authentication Status Codes",
Reporting and Conformance (DMARC)", RFC 7489, RFC 7372, DOI 10.17487/RFC7372, September 2014,
March 2015. <http://www.rfc-editor.org/info/rfc7372>.
[DNS] Mockapetris, P., "Domain names - [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
Implementation and Specification", STD 13, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 1035, November 1987. RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>.
[DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Souissi, "DNS Extensions to Support IP Version Message Authentication, Reporting, and Conformance
6", RFC 3596, October 2003. (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>.
[DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for [DNS] Mockapetris, P., "Domain names - implementation and
the use of DNS Reverse Mapping", Work specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
in Progress, March 2008. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[DOMAINKEYS] Delany, M., "Domain-Based Email Authentication [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
Using Public Keys Advertised in the DNS "DNS Extensions to Support IP Version 6", RFC 3596,
(DomainKeys)", RFC 4870, May 2007. DOI 10.17487/RFC3596, October 2003,
<http://www.rfc-editor.org/info/rfc3596>.
[DSN] Moore, K. and G. Vaudreuil, "An Extensible [DNSOP-REVERSE]
Message Format for Delivery Status Senie, D. and A. Sullivan, "Considerations for the use of
Notifications", RFC 3464, January 2003. DNS Reverse Mapping", Work in Progress, draft-ietf-dnsop-
reverse-mapping-considerations-06, March 2008.
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", [DOMAINKEYS]
RFC 5598, July 2009. Delany, M., "Domain-Based Email Authentication Using
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
DOI 10.17487/RFC4870, May 2007,
<http://www.rfc-editor.org/info/rfc4870>.
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
Writing an IANA Considerations Section in for Delivery Status Notifications", RFC 3464,
RFCs", BCP 26, RFC 5226, May 2008. DOI 10.17487/RFC3464, January 2003,
<http://www.rfc-editor.org/info/rfc3464>.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL [EMAIL-ARCH]
- VERSION 4rev1", RFC 3501, March 2003. Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
<http://www.rfc-editor.org/info/rfc5598>.
[POP3] Myers, J. and M. Rose, "Post Office Protocol - [IANA-CONSIDERATIONS]
Version 3", STD 53, RFC 1939, May 1996. Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[PRA] Lyon, J., "Purported Responsible Address in [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
E-Mail Messages", RFC 4407, April 2006. 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<http://www.rfc-editor.org/info/rfc3501>.
[PTYPES-REGISTRY] Kucherawy, M., "A Property Types Registry for [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
the Authentication-Results Header Field", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
RFC 7410, December 2014. <http://www.rfc-editor.org/info/rfc1939>.
[RFC5451] Kucherawy, M., "Message Header Field for [PRA] Lyon, J., "Purported Responsible Address in E-Mail
Indicating Message Authentication Status", Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006,
RFC 5451, April 2009. <http://www.rfc-editor.org/info/rfc4407>.
[RFC6008] Kucherawy, M., "Authentication-Results [RFC5451] Kucherawy, M., "Message Header Field for Indicating
Registration for Differentiating among Message Authentication Status", RFC 5451,
Cryptographic Results", RFC 6008, DOI 10.17487/RFC5451, April 2009,
September 2010. <http://www.rfc-editor.org/info/rfc5451>.
[RFC6577] Kucherawy, M., "Authentication-Results [RFC6008] Kucherawy, M., "Authentication-Results Registration for
Registration Update for Sender Policy Differentiating among Cryptographic Results", RFC 6008,
Framework (SPF) Results", RFC 6577, DOI 10.17487/RFC6008, September 2010,
March 2012. <http://www.rfc-editor.org/info/rfc6008>.
[RFC7001] Kucherawy, M., "Message Header Field for [RFC6577] Kucherawy, M., "Authentication-Results Registration Update
Indicating Message Authentication Status", for Sender Policy Framework (SPF) Results", RFC 6577,
RFC 7001, September 2013. DOI 10.17487/RFC6577, March 2012,
<http://www.rfc-editor.org/info/rfc6577>.
[RRVS] Mills, W. and M. Kucherawy, "The Require- [RFC7001] Kucherawy, M., "Message Header Field for Indicating
Recipient-Valid-Since Header Field and SMTP Message Authentication Status", RFC 7001,
Service Extension", RFC 7293, July 2014. DOI 10.17487/RFC7001, September 2013,
<http://www.rfc-editor.org/info/rfc7001>.
[SECURITY] Rescorla, E. and B. Korver, "Guidelines for [RFC7410] Kucherawy, M., "A Property Types Registry for the
Writing RFC Text on Security Considerations", Authentication-Results Header Field", RFC 7410,
BCP 72, RFC 3552, July 2003. DOI 10.17487/RFC7410, December 2014,
<http://www.rfc-editor.org/info/rfc7410>.
[SENDERID] Lyon, J. and M. Wong, "Sender ID: [RRVS] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid-
Authenticating E-Mail", RFC 4406, April 2006. Since Header Field and SMTP Service Extension", RFC 7293,
DOI 10.17487/RFC7293, July 2014,
<http://www.rfc-editor.org/info/rfc7293>.
[SMIME-REG] Melnikov, A., "Authentication-Results [SECURITY] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Registration for S/MIME Signature Text on Security Considerations", BCP 72, RFC 3552,
Verification", RFC 7281, June 2014. DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>.
[SPF] Kitterman, S., "Sender Policy Framework (SPF) [SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
for Authorizing Use of Domains in E-Mail, RFC 4406, DOI 10.17487/RFC4406, April 2006,
Version 1", RFC 7208, April 2014. <http://www.rfc-editor.org/info/rfc4406>.
[VBR] Hoffman, P., Levine, J., and A. Hathcock, [SMIME-REG]
"Vouch By Reference", RFC 5518, April 2009. Melnikov, A., "Authentication-Results Registration for
S/MIME Signature Verification", RFC 7281,
DOI 10.17487/RFC7281, June 2014,
<http://www.rfc-editor.org/info/rfc7281>.
Appendix A. Acknowledgments [SPF] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<http://www.rfc-editor.org/info/rfc7208>.
The author wishes to acknowledge the following individuals for their [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
review and constructive criticism of this document: Stephane Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009,
Bortzmeyer, Scott Kitterman, John Levine, Tom Petch, and Pete <http://www.rfc-editor.org/info/rfc5518>.
Resnick.
Appendix B. Legacy MUAs Appendix A. 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
value that reflects the strength of the authentication that was value that reflects the strength of the authentication that was
accomplished, e.g., "low" for weak or no authentication, "normal" or accomplished, e.g., "low" for weak or no authentication, "normal" or
"high" for good or strong authentication. "high" for good or strong authentication.
Some modern MUAs can already filter based on the content of this Some modern MUAs can already filter based on the content of this
header field. However, there is keen interest in having MUAs make header field. However, there is keen interest in having MUAs make
some kind of graphical representation of this header field's meaning some kind of graphical representation of this header field's meaning
to end users. Until this capability is added, other interim means of to end users. Until this capability is added (i.e., while this
conveying authentication results may be necessary while this proposal proposal and its successors are being adopted), other interim means
and its successors are adopted. of conveying authentication results may be necessary.
Appendix C. Authentication-Results Examples Appendix B. Authentication-Results Examples
This section presents some examples of the use of this header field This section presents some examples of the use of this header field
to indicate authentication results. to indicate authentication results.
C.1. Trivial Case; Header Field Not Present B.1. Trivial Case; Header Field Not Present
The trivial case: The trivial case:
Received: from mail-router.example.com Received: from mail-router.example.com
(mail-router.example.com [192.0.2.1]) (mail-router.example.com [192.0.2.1])
by server.example.org (8.11.6/8.11.6) by server.example.org (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489; with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800 Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.com From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800 Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org To: receiver@example.org
Message-Id: <12345.abc@example.com> Message-Id: <12345.abc@example.com>
Subject: here's a sample Subject: here's a sample
Hello! Goodbye! Hello! Goodbye!
Example 1: Trivial Case Example 1: Trivial Case
The Authentication-Results header field is completely absent. The The Authentication-Results header field is completely absent. The
MUA may make no conclusion about the validity of the message. This MUA may make no conclusion about the validity of the message. This
could be the case because the message authentication services were could be the case because the message authentication services were
not available at the time of delivery, or no service is provided, or not available at the time of delivery, or no service is provided, or
the MTA is not in compliance with this specification. the MTA is not in compliance with this specification.
C.2. Nearly Trivial Case; Service Provided, but No Authentication Done B.2. Nearly Trivial Case; Service Provided, but No Authentication Done
A message that was delivered by an MTA that conforms to this A message that was delivered by an MTA that conforms to this
specification but provides no actual message authentication service: specification but provides no actual message authentication service:
Authentication-Results: example.org 1; none Authentication-Results: example.org 1; none
Received: from mail-router.example.com Received: from mail-router.example.com
(mail-router.example.com [192.0.2.1]) (mail-router.example.com [192.0.2.1])
by server.example.org (8.11.6/8.11.6) by server.example.org (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489; with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800 Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.com From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800 Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org To: receiver@example.org
Message-Id: <12345.abc@example.com> Message-Id: <12345.abc@example.com>
Subject: here's a sample Subject: here's a sample
Hello! Goodbye! Hello! Goodbye!
Example 2: Header Present but No Authentication Done Example 2: Header Present but No Authentication Done
The Authentication-Results header field is present, showing that the The Authentication-Results header field is present, showing that the
delivering MTA conforms to this specification. It used its DNS delivering MTA conforms to this specification. It used its DNS
domain name as the authserv-id. The presence of "none" (and the domain name as the authserv-id. The presence of "none" (and the
absence of any method and result tokens) indicates that no message absence of any method or result tokens) indicates that no message
authentication was done. The version number of the specification to authentication was done. The version number of the specification to
which the field's content conforms is explicitly provided. which the field's content conforms is explicitly provided.
C.3. Service Provided, Authentication Done B.3. Service Provided, Authentication Done
A message that was delivered by an MTA that conforms to this A message that was delivered by an MTA that conforms to this
specification and applied some message authentication: specification and applied some message authentication:
Authentication-Results: example.com; Authentication-Results: example.com;
spf=pass smtp.mailfrom=example.net spf=pass smtp.mailfrom=example.net
Received: from dialup-1-2-3-4.example.net Received: from dialup-1-2-3-4.example.net
(dialup-1-2-3-4.example.net [192.0.2.200]) (dialup-1-2-3-4.example.net [192.0.2.200])
by mail-router.example.com (8.11.6/8.11.6) by mail-router.example.com (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489; with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800 Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.net From: sender@example.net
Date: Fri, Feb 15 2002 16:54:30 -0800 Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com To: receiver@example.com
Message-Id: <12345.abc@example.net> Message-Id: <12345.abc@example.net>
Subject: here's a sample Subject: here's a sample
Hello! Goodbye! Hello! Goodbye!
Example 3: Header Reporting Results Example 3: Header Reporting Results
The Authentication-Results header field is present, indicating that The Authentication-Results header field is present, indicating that
the border MTA conforms to this specification. The authserv-id is the border MTA conforms to this specification. The authserv-id is
once again the DNS domain name. Furthermore, the message was once again the DNS domain name. Furthermore, the message was
authenticated by that MTA via the method specified in [SPF]. Note authenticated by that MTA via the method specified in [SPF]. Note
that since that method cannot authenticate the local-part, it has that since that method cannot authenticate the local-part, it has
been omitted from the result's value. The MUA could extract and been omitted from the result's value. The MUA could extract and
relay this extra information if desired. relay this extra information if desired.
C.4. Service Provided, Several Authentications Done, Single MTA B.4. Service Provided, Several Authentications Done, Single MTA
A message that was relayed inbound via a single MTA that conforms to A message that was relayed inbound via a single MTA that conforms to
this specification and applied three different message authentication this specification and applied three different message authentication
checks: checks:
Authentication-Results: example.com; Authentication-Results: example.com;
auth=pass (cram-md5) smtp.auth=sender@example.net; auth=pass (cram-md5) smtp.auth=sender@example.net;
spf=pass smtp.mailfrom=example.net spf=pass smtp.mailfrom=example.net
Authentication-Results: example.com; Authentication-Results: example.com;
sender-id=pass header.from=example.net sender-id=pass header.from=example.net
skipping to change at page 43, line 29 skipping to change at page 45, line 29
with ESMTPA id g1G0r1kA003489; with ESMTPA id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800 Fri, Feb 15 2002 17:19:07 -0800
Date: Fri, Feb 15 2002 16:54:30 -0800 Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com To: receiver@example.com
From: sender@example.net From: sender@example.net
Message-Id: <12345.abc@example.net> Message-Id: <12345.abc@example.net>
Subject: here's a sample Subject: here's a sample
Hello! Goodbye! Hello! Goodbye!
Example 4: Headers Reporting Results from One MTA Example 4: Headers Reporting Results from One MTA
The Authentication-Results header field is present, indicating that The Authentication-Results header field is present, indicating that
the delivering MTA conforms to this specification. Once again, the the delivering MTA conforms to this specification. Once again, the
receiving DNS domain name is used as the authserv-id. Furthermore, receiving DNS domain name is used as the authserv-id. Furthermore,
the sender authenticated herself/himself to the MTA via a method the sender authenticated herself/himself to the MTA via a method
specified in [AUTH], and both SPF and Sender ID checks were done and specified in [AUTH], and both SPF and Sender ID checks were done and
passed. The MUA could extract and relay this extra information if passed. The MUA could extract and relay this extra information if
desired. desired.
Two Authentication-Results header fields are not required since the Two Authentication-Results header fields are not required since the
same host did all of the checking. The authenticating agent could same host did all of the checking. The authenticating agent could
have consolidated all the results into one header field. have consolidated all the results into one header field.
This example illustrates a scenario in which a remote user on a This example illustrates a scenario in which a remote user on a dial-
dialup connection (example.net) sends mail to a border MTA up connection (example.net) sends mail to a border MTA (example.com)
(example.com) using SMTP authentication to prove identity. The using SMTP authentication to prove identity. The dial-up provider
dialup provider has been explicitly authorized to relay mail as has been explicitly authorized to relay mail as example.com,
example.com resulting in passes by the SPF and Sender ID checks. producing "pass" results from the SPF and Sender ID checks.
C.5. Service Provided, Several Authentications Done, Different MTAs B.5. Service Provided, Several Authentications Done, Different MTAs
A message that was relayed inbound by two different MTAs that conform A message that was relayed inbound by two different MTAs that conform
to this specification and applied multiple message authentication to this specification and applied multiple message authentication
checks: checks:
Authentication-Results: example.com; Authentication-Results: example.com;
sender-id=fail header.from=example.com; sender-id=fail header.from=example.com;
dkim=pass (good signature) header.d=example.com dkim=pass (good signature) header.d=example.com
Received: from mail-router.example.com Received: from mail-router.example.com
(mail-router.example.com [192.0.2.1]) (mail-router.example.com [192.0.2.1])
skipping to change at page 44, line 40 skipping to change at page 46, line 40
with ESMTPA id g1G0r1kA003489; with ESMTPA id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800 Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.com From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800 Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com To: receiver@example.com
Message-Id: <12345.abc@example.com> Message-Id: <12345.abc@example.com>
Subject: here's a sample Subject: here's a sample
Hello! Goodbye! Hello! Goodbye!
Example 5: Headers Reporting Results from Multiple MTAs Example 5: Headers Reporting Results from Multiple MTAs
The Authentication-Results header field is present, indicating The Authentication-Results header field is present, indicating
conformance to this specification. Once again, the authserv-id used conformance to this specification. Once again, the authserv-id used
is the recipient's DNS domain name. The header field is present is the recipient's DNS domain name. The header field is present
twice because two different MTAs in the chain of delivery did twice because two different MTAs in the chain of delivery did
authentication tests. The first MTA, mail-router.example.com, authentication tests. The first MTA, mail-router.example.com,
reports that SMTP AUTH and SPF were both used and that the former reports that SMTP AUTH and SPF were both used and that the former
passed while the latter failed. In the SMTP AUTH case, additional passed while the latter failed. In the SMTP AUTH case, additional
information is provided in the comment field, which the MUA can information is provided in the comment field, which the MUA can
choose to render if desired. choose to render if desired.
skipping to change at page 45, line 14 skipping to change at page 47, line 16
Sender ID test (which failed) and a DKIM test (which passed). Again, Sender ID test (which failed) and a DKIM test (which passed). Again,
additional data about one of the tests is provided as a comment, additional data about one of the tests is provided as a comment,
which the MUA may choose to render. Also noteworthy here is the fact which the MUA may choose to render. Also noteworthy here is the fact
that there is a DKIM signature added by example.com that assured the that there is a DKIM signature added by example.com that assured the
integrity of the lower Authentication-Results field. integrity of the lower Authentication-Results field.
Since different hosts did the two sets of authentication checks, the Since different hosts did the two sets of authentication checks, the
header fields cannot be consolidated in this example. header fields cannot be consolidated in this example.
This example illustrates more typical transmission of mail into This example illustrates more typical transmission of mail into
example.com from a user on a dialup connection example.net. The user example.com from a user on a dial-up connection example.net. The
appears to be legitimate as he/she had a valid password allowing user appears to be legitimate as he/she had a valid password allowing
authentication at the border MTA using SMTP AUTH. The SPF and Sender authentication at the border MTA using SMTP AUTH. The SPF and Sender
ID tests failed since example.com has not granted example.net ID tests failed since example.com has not granted example.net
authority to relay mail on its behalf. However, the DKIM test passed authority to relay mail on its behalf. However, the DKIM test passed
because the sending user had a private key matching one of because the sending user had a private key matching one of
example.com's published public keys and used it to sign the message. example.com's published public keys and used it to sign the message.
C.6. Service Provided, Multi-Tiered Authentication Done B.6. Service Provided, Multi-tiered Authentication Done
A message that had authentication done at various stages, one of A message that had authentication done at various stages, one of
which was outside the receiving ADMD: which was outside the receiving ADMD:
Authentication-Results: example.com; Authentication-Results: example.com;
dkim=pass reason="good signature" dkim=pass reason="good signature"
header.i=@mail-router.example.net; header.i=@mail-router.example.net;
dkim=fail reason="bad signature" dkim=fail reason="bad signature"
header.i=@newyork.example.com header.i=@newyork.example.com
Received: from mail-router.example.net Received: from mail-router.example.net
skipping to change at page 46, line 45 skipping to change at page 48, line 45
t=1188964191; c=simple/simple; t=1188964191; c=simple/simple;
h=From:Date:To:Message-Id:Subject; h=From:Date:To:Message-Id:Subject;
bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
From: sender@newyork.example.com From: sender@newyork.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800 Date: Fri, Feb 15 2002 16:54:30 -0800
To: meetings@example.net To: meetings@example.net
Message-Id: <12345.abc@newyork.example.com> Message-Id: <12345.abc@newyork.example.com>
Subject: here's a sample Subject: here's a sample
Example 6: Headers Reporting Results from Multiple MTAs in Different Example 6: Headers Reporting Results from Multiple MTAs in
ADMDs Different ADMDs
In this example, we see multi-tiered authentication with an extended In this example, we see multi-tiered authentication with an extended
trust boundary. trust boundary.
The message was sent from someone at example.com's New York office The message was sent from someone at example.com's New York office
(newyork.example.com) to a mailing list managed at an intermediary. (newyork.example.com) to a mailing list managed at an intermediary.
The message was signed at the origin using DKIM. The message was signed at the origin using DKIM.
The message was sent to a mailing list service provider called The message was sent to a mailing list service provider called
example.net, which is used by example.com. There, example.net, which is used by example.com. There,
meetings@example.net is expanded to a long list of recipients, one of meetings@example.net is expanded to a long list of recipients, one of
whom is at the Chicago office. In this example, we will assume that whom is at the Chicago office. In this example, we will assume that
the trust boundary for chicago.example.com includes the mailing list the trust boundary for chicago.example.com includes the mailing list
server at example.net. server at example.net.
The mailing list server there first authenticated the message and The mailing list server there first authenticated the message and
skipping to change at page 47, line 32 skipping to change at page 49, line 34
The border MTA for chicago.example.com explicitly trusts results from The border MTA for chicago.example.com explicitly trusts results from
mail-router.example.net, so that header field is not removed. It mail-router.example.net, so that header field is not removed. It
performs evaluation of both signatures and determines that the first performs evaluation of both signatures and determines that the first
(most recent) is a "pass" but, because of the aforementioned (most recent) is a "pass" but, because of the aforementioned
modifications, the second is a "fail". However, the first signature modifications, the second is a "fail". However, the first signature
included the Authentication-Results header added at mail- included the Authentication-Results header added at mail-
router.example.net that validated the second signature. Thus, router.example.net that validated the second signature. Thus,
indirectly, it can be determined that the authentications claimed by indirectly, it can be determined that the authentications claimed by
both signatures are indeed valid. both signatures are indeed valid.
Note that two styles of presenting meta-data about the result are in Note that two styles of presenting metadata about the result are in
use here. In one case, the "reason=" clause is present, which is use here. In one case, the "reason=" clause is present, which is
intended for easy extraction by parsers; in the other case, the CFWS intended for easy extraction by parsers; in the other case, the CFWS
production of the ABNF is used to include such data as a header field production of the ABNF is used to include such data as a header field
comment. The latter can be harder for parsers to extract given the comment. The latter can be harder for parsers to extract given the
varied supported syntaxes of mail header fields. varied supported syntaxes of mail header fields.
C.7. Comment-Heavy Example B.7. Comment-Heavy Example
The formal syntax permits comments within the content in a number of The formal syntax permits comments within the content in a number of
places. For the sake of illustration, this example is also legal: places. For the sake of illustration, this example is also legal:
Authentication-Results: foo.example.net (foobar) 1 (baz); Authentication-Results: foo.example.net (foobar) 1 (baz);
dkim (Because I like it) / 1 (One yay) = (wait for it) fail dkim (Because I like it) / 1 (One yay) = (wait for it) fail
policy (A dot can go here) . (like that) expired policy (A dot can go here) . (like that) expired
(this surprised me) = (as I wasn't expecting it) 1362471462 (this surprised me) = (as I wasn't expecting it) 1362471462
Example 7: A Very Comment-Heavy but Perfectly Legal Example Example 7: A Very Comment-Heavy but Perfectly Legal Example
Appendix D. Operational Considerations about Message Authentication Appendix C. Operational Considerations about Message Authentication
This protocol is predicated on the idea that authentication (and This protocol is predicated on the idea that authentication (and
presumably in the future, reputation) work is typically done by presumably in the future, reputation) work is typically done by
border MTAs rather than MUAs or intermediate MTAs; the latter merely border MTAs rather than MUAs or intermediate MTAs; the latter merely
make use of the results determined by the former. Certainly this is make use of the results determined by the former. Certainly this is
not mandatory for participation in electronic mail or message not mandatory for participation in electronic mail or message
authentication, but this protocol and its deployment to date are authentication, but this protocol and its deployment to date are
based on that model. The assumption satisfies several common ADMD based on that model. The assumption satisfies several common ADMD
requirements: requirements:
skipping to change at page 48, line 38 skipping to change at page 50, line 38
configurations or similar burdens. configurations or similar burdens.
3. MUAs rely upon the upstream MTAs within their trust boundaries to 3. MUAs rely upon the upstream MTAs within their trust boundaries to
make correct (as much as is possible) evaluations about the make correct (as much as is possible) evaluations about the
message's envelope, header, and content. Thus, MUAs don't need message's envelope, header, and content. Thus, MUAs don't need
to know how to do the work that upstream MTAs do; they only need to know how to do the work that upstream MTAs do; they only need
the results of that work. the results of that work.
4. Evaluations about the quality of a message, from simple token 4. Evaluations about the quality of a message, from simple token
matching (e.g., a list of preferred DNS domains) to cryptanalysis matching (e.g., a list of preferred DNS domains) to cryptanalysis
(e.g., public/private key work), are at least a little bit (e.g., public/private key work), do have a cost and thus need to
expensive and thus need to be minimized. To that end, performing be minimized. To that end, performing those tests at the border
those tests at the border MTA is far preferred to doing that work MTA is far preferred to doing that work at each MUA that handles
at each MUA that handles a message. If an ADMD's environment a message. If an ADMD's environment adheres to common messaging
adheres to common messaging protocols, a reputation query or an protocols, a reputation query or an authentication check
authentication check performed by a border MTA would return the performed by a border MTA would return the same result as the
same result as the same query performed by an MUA. By contrast, same query performed by an MUA. By contrast, in an environment
in an environment where the MUA does the work, a message arriving where the MUA does the work, a message arriving for multiple
for multiple recipients would thus cause authentication or recipients would thus cause authentication or reputation
reputation evaluation to be done more than once for the same evaluation to be done more than once for the same message (i.e.,
message (i.e., at each MUA), causing needless amplification of at each MUA), causing needless amplification of resource use and
resource use and creating a possible denial-of-service attack creating a possible denial-of-service attack vector.
vector.
5. Minimizing change is good. As new authentication and reputation 5. Minimizing change is good. As new authentication and reputation
methods emerge, the list of methods supported by this header methods emerge, the list of methods supported by this header
field would presumably be extended. If MUAs simply consume the field would presumably be extended. If MUAs simply consume the
contents of this header field rather than actually attempt to do contents of this header field rather than actually attempt to do
authentication and/or reputation work, then MUAs only need to authentication and/or reputation work, then MUAs only need to
learn to parse this header field once; emergence of new methods learn to parse this header field once; emergence of new methods
requires only a configuration change at the MUAs and software requires only a configuration change at the MUAs and software
changes at the MTAs (which are presumably fewer in number). When changes at the MTAs (which are presumably fewer in number). When
choosing to implement these functions in MTAs vs. MUAs, the choosing to implement these functions in MTAs vs. MUAs, the
skipping to change at page 49, line 28 skipping to change at page 51, line 28
many MUAs is more effort than changing a smaller number of MTAs. many MUAs is more effort than changing a smaller number of MTAs.
6. For decisions affecting message delivery and display, assessment 6. For decisions affecting message delivery and display, assessment
based on authentication and reputation is best performed close to based on authentication and reputation is best performed close to
the time of message transit, as a message makes its journey the time of message transit, as a message makes its journey
toward a user's inbox, not afterwards. DKIM keys and IP address toward a user's inbox, not afterwards. DKIM keys and IP address
reputations, etc., can change over time or even become invalid, reputations, etc., can change over time or even become invalid,
and users can take a long time to read a message once delivered. and users can take a long time to read a message once delivered.
The value of this work thus degrades, perhaps quickly, once the The value of this work thus degrades, perhaps quickly, once the
delivery process has completed. This seriously diminishes the delivery process has completed. This seriously diminishes the
value of this work when done other than at MTAs. value of this work when done elsewhere than at MTAs.
Many operational choices are possible within an ADMD, including the Many operational choices are possible within an ADMD, including the
venue for performing authentication and/or reputation assessment. venue for performing authentication and/or reputation assessment.
The current specification does not dictate any of those choices. The current specification does not dictate any of those choices.
Rather, it facilitates those cases in which information produced by Rather, it facilitates those cases in which information produced by
one stage of analysis needs to be transported with the message to the one stage of analysis needs to be transported with the message to the
next stage. next stage.
Appendix E. Change Since RFC7001 Appendix D. Changes since RFC 7001
o Apply RFC7410. o Applied RFC 7410.
o Update all the RFC4408 references to RFC7208. o Updated all references to RFC 4408 with RFC 7208.
o Add section explaining "property" values. (Errata #4201) o Added section explaining "property" values. (Addressed Erratum
#4201.)
o Some minor text reorganization. o Did some minor text reorganization.
o Give registry history, enough that this is now the authoritative o Gave registry history -- enough that this is now the authoritative
registry definition. registry definition.
o Add text explaining each of the method-ptype-property tuples o Added 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 Changed the meaning of the "Defined" column of the methods
to be the place where each entry was created and described; it is registry to be the place where each entry was created and
expected that this will then refer to the method's defining described; it is expected that this will then refer to the
document. Provide IANA with corresponding update instructions. method's defining document. Provided IANA with corresponding
update instructions.
o Clean up registry structure and content, and replace all RFC7001 o Cleaned up registry structure and content, and replaced all
references with pointers to this document. references to RFC 7001 with pointers to this document.
o Add references: [DMARC], [PRA], [RFC6008], [RFC6577], [RRVS], o Added references: [DMARC], [PRA], [RFC6008], [RFC6577], [RRVS],
[SMIME-REG]. [SMIME-REG].
o Add description of values that can be extracted from SMTP AUTH o Added description of values that can be extracted from SMTP AUTH
sessions and an example. sessions and an example.
o Much more complete descriptions of reporting DomainKeys results. o Provided much more complete descriptions of reporting DomainKeys
results.
o Add more detail about Sender ID. o Added more detail about Sender ID.
o Mark all ADSP and DomainKeys entries as deprecated since their o Marked all ADSP and DomainKeys entries as deprecated since their
defining documents are as well. defining documents are as well.
o Rework some text around ignoring unknown ptypes. o Reworked some text around ignoring unknown ptypes.
o Completely describe the ptypes registry. o Completely described the ptypes registry.
o EHLO is mapped to HELO for SPF. o Mentioned that EHLO is mapped to HELO for SPF.
o RFC7208 uses all-lowercase result strings now, so adjust prose o RFC 7208 uses all-lowercase result strings now, so adjusted prose
accordingly. accordingly.
o Update list of supported methods, and mention the registries o Updated list of supported methods, and mentioned the registries
immediately below there. immediately below.
o Mention that when a local-part is removed, the "@" goes with it. o Mentioned that when a local-part is removed, the "@" goes with it.
o Refer to RFC7328 in the "iprev" definition. o Referred to RFC 7328 in the "iprev" definition.
o Correction to "smime-part" prose. o Corrected the "smime-part" prose.
o Examples that use SMTP AUTH now claim "with ESMTPA" in the o Updated examples that use SMTP AUTH to claim "with ESMTPA" in the
Received fields. Received fields.
o Minor editorial adjustments. o Made minor editorial adjustments.
Acknowledgments
The author wishes to acknowledge the following individuals for their
review and constructive criticism of this document: Stephane
Bortzmeyer, Scott Kitterman, John Levine, Tom Petch, and Pete
Resnick.
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 United States
EMail: superuser@gmail.com Email: superuser@gmail.com
 End of changes. 151 change blocks. 
370 lines changed or deleted 405 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/