draft-ietf-dmarc-rfc7601bis-05.txt   draft-ietf-dmarc-rfc7601bis-06.txt 
Individual submission M. Kucherawy Individual submission M. Kucherawy
Internet-Draft January 20, 2019 Internet-Draft January 28, 2019
Obsoletes: 7601 (if approved) Obsoletes: 7601 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: July 24, 2019 Expires: August 1, 2019
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-dmarc-rfc7601bis-05 draft-ietf-dmarc-rfc7601bis-06
Abstract Abstract
This document specifies a message header field called Authentication- This document specifies a message header field called Authentication-
Results for use with electronic mail messages to indicate the results Results for use with electronic mail messages to indicate the results
of message authentication efforts. Any receiver-side software, such of message authentication efforts. Any receiver-side software, such
as mail filters or Mail User Agents (MUAs), can use this header field as mail filters or Mail User Agents (MUAs), can use this header field
to relay that information in a convenient and meaningful way to users to relay that information in a convenient and meaningful way to users
or to make sorting and filtering decisions. or to make sorting and filtering decisions.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 24, 2019. This Internet-Draft will expire on August 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1.5.5. Other Terms . . . . . . . . . . . . . . . . . . . . . 9 1.5.5. Other Terms . . . . . . . . . . . . . . . . . . . . . 9
1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 9 1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 9
2. Definition and Format of the Header Field . . . . . . . . . . 10 2. Definition and Format of the Header Field . . . . . . . . . . 10
2.1. General Description . . . . . . . . . . . . . . . . . . . 10 2.1. General Description . . . . . . . . . . . . . . . . . . . 10
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10
2.3. Property Types (ptypes) and Properties . . . . . . . . . . 13 2.3. Property Types (ptypes) and Properties . . . . . . . . . . 13
2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 14 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 14
2.5. Authentication Identifier Field . . . . . . . . . . . . . 15 2.5. Authentication Identifier Field . . . . . . . . . . . . . 15
2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 16 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 16
2.7. Defined Methods and Result Values . . . . . . . . . . . . 16 2.7. Defined Methods and Result Values . . . . . . . . . . . . 16
2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 17 2.7.1. DKIM . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 18 2.7.2. SPF . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 20 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 21 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 20
2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 22 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 21
2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 22 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21
2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 23 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 22
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 23 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 23
4. Adding the Header Field to a Message . . . . . . . . . . . . . 24 4. Adding the Header Field to a Message . . . . . . . . . . . . . 24
4.1. Header Field Position and Interpretation . . . . . . . . . 26 4.1. Header Field Position and Interpretation . . . . . . . . . 25
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 27 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 26
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 27 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6.1. The Authentication-Results Header Field . . . . . . . . . 29 6.1. The Authentication-Results Header Field . . . . . . . . . 28
6.2. "Email Authentication Methods" Registry Description . . . 29 6.2. "Email Authentication Methods" Registry Description . . . 29
6.3. "Email Authentication Methods" Registry Update . . . . . . 30 6.3. "Email Authentication Methods" Registry Update . . . . . . 30
6.3.1. 'header.a' for DKIM . . . . . . . . . . . . . . . . . 31 6.3.1. 'header.a' for DKIM . . . . . . . . . . . . . . . . . 30
6.3.2. 'header.s' for DKIM . . . . . . . . . . . . . . . . . 32 6.3.2. 'header.s' for DKIM . . . . . . . . . . . . . . . . . 31
6.4. "Email Authentication Property Types" Registry 6.4. "Email Authentication Property Types" Registry
Description . . . . . . . . . . . . . . . . . . . . . . . 32 Description . . . . . . . . . . . . . . . . . . . . . . . 31
6.5. "Email Authentication Property Types" Registry Update . . 33 6.5. "Email Authentication Property Types" Registry Update . . 32
6.6. "Email Authentication Result Names" Registry 6.6. "Email Authentication Result Names" Registry
Description . . . . . . . . . . . . . . . . . . . . . . . 33 Description . . . . . . . . . . . . . . . . . . . . . . . 32
6.7. "Email Authentication Result Names" Registry Update . . . 33 6.7. "Email Authentication Result Names" Registry Update . . . 33
6.8. SMTP Enhanced Status Codes . . . . . . . . . . . . . . . . 34 6.8. SMTP Enhanced Status Codes . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 34 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 34
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 36 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 35
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 36 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 36
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 36 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 36
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 37 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 36
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 37 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 36
7.7. Attacks against Authentication Methods . . . . . . . . . . 37 7.7. Attacks against Authentication Methods . . . . . . . . . . 36
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 37 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 37
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 37 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 37
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 38 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 37
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 38 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 38
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. Normative References . . . . . . . . . . . . . . . . . . . 38 8.1. Normative References . . . . . . . . . . . . . . . . . . . 38
8.2. Informative References . . . . . . . . . . . . . . . . . . 39 8.2. Informative References . . . . . . . . . . . . . . . . . . 39
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 43 Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 42
Appendix B. Authentication-Results Examples . . . . . . . . . . . 43 Appendix B. Authentication-Results Examples . . . . . . . . . . . 42
B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 43 B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 43
B.2. Nearly Trivial Case; Service Provided, but No B.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 44 Authentication Done . . . . . . . . . . . . . . . . . . . 43
B.3. Service Provided, Authentication Done . . . . . . . . . . 45 B.3. Service Provided, Authentication Done . . . . . . . . . . 44
B.4. Service Provided, Several Authentications Done, Single B.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.5. Service Provided, Several Authentications Done, B.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 47 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 46
B.6. Service Provided, Multi-tiered Authentication Done . . . . 49 B.6. Service Provided, Multi-tiered Authentication Done . . . . 48
B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 50 B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 49
Appendix C. Operational Considerations about Message Appendix C. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 51 Authentication . . . . . . . . . . . . . . . . . . . 50
Appendix D. Changes since RFC7601 . . . . . . . . . . . . . . . . 52 Appendix D. Changes since RFC7601 . . . . . . . . . . . . . . . . 51
Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . . 53 Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . . 52
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This document describes a header field called Authentication-Results This document describes a header field called Authentication-Results
for electronic mail messages that presents the results of a message for electronic mail messages that presents the results of a message
authentication effort in a machine-readable format. The intent of authentication effort in a machine-readable format. The intent of
the header field is to create a place to collect such data when the header field is to create a place to collect such data when
message authentication mechanisms are in use so that a Mail User message authentication mechanisms are in use so that a Mail User
Agent (MUA) and downstream filters can make filtering decisions Agent (MUA) and downstream filters can make filtering decisions
and/or provide a recommendation to the user as to the validity of the and/or provide a recommendation to the user as to the validity of the
skipping to change at page 4, line 31 skipping to change at page 4, line 31
This document specifies the format of this header field and discusses This document specifies the format of this header field and discusses
the implications of its presence or absence. However, it does not the implications of its presence or absence. However, it does not
discuss how the data contained in the header field ought to be used, discuss how the data contained in the header field ought to be used,
such as what filtering decisions are appropriate or how an MUA might such as what filtering decisions are appropriate or how an MUA might
render those results, as these are local policy and/or user interface render those results, as these are local policy and/or user interface
design questions that are not appropriate for this document. design questions that are not appropriate for this document.
At the time of publication of this document, the following are At the time of publication of this document, the following are
published email authentication methods: published email authentication methods:
o Author Domain Signing Practices ([ADSP]) (Historic)
o SMTP Service Extension for Authentication ([AUTH]) o SMTP Service Extension for Authentication ([AUTH])
o DomainKeys Identified Mail Signatures ([DKIM]) o DomainKeys Identified Mail Signatures ([DKIM])
o Domain-based Message Authentication, Reporting and Conformance o Domain-based Message Authentication, Reporting and Conformance
([DMARC]) ([DMARC])
o Sender Policy Framework ([SPF]) o Sender Policy Framework ([SPF])
o reverse IP address name validation ("iprev", defined in Section 3) o reverse IP address name validation ("iprev", defined in Section 3)
o Require-Recipient-Valid-Since Header Field and SMTP Service o Require-Recipient-Valid-Since Header Field and SMTP Service
Extension ([RRVS]) Extension ([RRVS])
o S/MIME Signature Verification ([SMIME-REG]) o S/MIME Signature Verification ([SMIME-REG])
o Vouch By Reference ([VBR]) o Vouch By Reference ([VBR])
The following historic specifications were previously supported by
this framework, but have since become obsolete:
o Author Domain Signing Practices ([ADSP]) (Historic)
o DomainKeys ([DOMAINKEYS]) (Historic) o DomainKeys ([DOMAINKEYS]) (Historic)
o Sender ID ([SENDERID]) (Experimental)
o Sender ID ([SENDERID]) (Historic)
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.
The goal of this work is to give current and future authentication The goal of this work is to give current and future authentication
schemes a common framework within which to deliver their results to schemes a common framework within which to deliver their results to
downstream agents and discourage the creation of unique header fields downstream agents and discourage the creation of unique header fields
skipping to change at page 8, line 10 skipping to change at page 8, line 10
o "Authorization" is the establishment of permission to use a o "Authorization" is the establishment of permission to use a
resource or represent an identity. In this context, authorization resource or represent an identity. In this context, authorization
indicates that a message from a particular ADMD arrived via a indicates that a message from a particular ADMD arrived via a
route the ADMD has explicitly approved. route the ADMD has explicitly approved.
o "Authentication" is the assertion of validity of a piece of data o "Authentication" is the assertion of validity of a piece of data
about a message (such as the sender's identity) or the message in about a message (such as the sender's identity) or the message in
its entirety. its entirety.
As examples: SPF and Sender ID are authorization mechanisms in that As examples: SPF is an authorization mechanism in that it expresses a
they express a result that shows whether the ADMD that apparently result that shows whether the ADMD that apparently sent the message
sent the message has explicitly authorized the connecting Simple Mail has explicitly authorized the connecting Simple Mail Transfer
Transfer Protocol ([SMTP]) client to relay messages on its behalf, Protocol ([SMTP]) client to relay messages on its behalf, but they do
but they do not actually validate any other property of the message not actually validate any other property of the message itself. By
itself. By contrast, DKIM is agnostic as to the routing of a message contrast, DKIM is agnostic as to the routing of a message but uses
but uses cryptographic signatures to authenticate agents, assign cryptographic signatures to authenticate agents, assign (some)
(some) responsibility for the message (which implies authorization), responsibility for the message (which implies authorization), and
and ensure that the listed portions of the message were not modified ensure that the listed portions of the message were not modified in
in transit. Since the signatures are not tied to SMTP connections, transit. Since the signatures are not tied to SMTP connections, they
they can be added by either the ADMD of origin, intermediate ADMDs can be added by either the ADMD of origin, intermediate ADMDs (such
(such as a mailing list server), other handling agents, or any as a mailing list server), other handling agents, or any combination.
combination.
Rather than create a separate header field for each class of Rather than create a separate header field for each class of
solution, this specification groups them both into a single header solution, this specification groups them both into a single header
field. field.
1.5.4. Email Architecture 1.5.4. Email Architecture
o A "border MTA" is an MTA that acts as a gateway between the o A "border MTA" is an MTA that acts as a gateway between the
general Internet and the users within an organizational boundary. general Internet and the users within an organizational boundary.
(See also Section 1.2.) (See also Section 1.2.)
skipping to change at page 10, line 48 skipping to change at page 10, line 48
The header field can appear more than once in a single message, more The header field can appear more than once in a single message, more
than one result can be represented in a single header field, or a than one result can be represented in a single header field, or a
combination of these can be applied. combination of these can be applied.
2.2. Formal Definition 2.2. Formal Definition
Formally, the header field is specified as shown below using Formally, the header field is specified as shown below using
Augmented Backus-Naur Form ([ABNF]). Examples of valid header fields Augmented Backus-Naur Form ([ABNF]). Examples of valid header fields
with explanations of their semantics can be found in Appendix B. with explanations of their semantics can be found in Appendix B.
authres-header-field = "Authentication-Results:" authres-payload authres-header-field = "Authentication-Results:" authres-payload
authres-payload = [CFWS] authserv-id authres-payload = [CFWS] authserv-id
[ CFWS authres-version ] [ CFWS authres-version ]
( no-result / 1*resinfo ) [CFWS] CRLF ( no-result / 1*resinfo ) [CFWS] CRLF
authserv-id = value authserv-id = value
; see below for a description of this element ; see below for a description of this element
authres-version = 1*DIGIT [CFWS] authres-version = 1*DIGIT [CFWS]
; indicates which version of this specification is in use; ; indicates which version of this specification is in use;
skipping to change at page 17, line 7 skipping to change at page 17, line 7
Each individual authentication method returns one of a set of Each individual authentication method returns one of a set of
specific result values. The subsections below provide references to specific result values. The subsections below provide references to
the documents defining the authentication methods specifically the documents defining the authentication methods specifically
supported by this document, and their corresponding result values. supported by this document, and their corresponding result values.
Verifiers SHOULD use these values as described below. New methods Verifiers SHOULD use these values as described below. New methods
not specified in this document, but intended to be supported by the not specified in this document, but intended to be supported by the
header field defined here, MUST include a similar result table either header field defined here, MUST include a similar result table either
in their defining documents or in supplementary ones. in their defining documents or in supplementary ones.
2.7.1. DKIM and DomainKeys 2.7.1. DKIM
DKIM is represented by the "dkim" method and is defined in [DKIM]. DKIM is represented by the "dkim" method and is defined in [DKIM].
DomainKeys is defined in [DOMAINKEYS] and is represented by the
"domainkeys" method.
Section 3.8 of [DOMAINKEYS] enumerates some possible results of a
DomainKeys evaluation. Those results are not used when generating
this header field; rather, the results returned are listed below.
A signature is "acceptable to the ADMD" if it passes local policy A signature is "acceptable to the ADMD" if it passes local policy
checks (or there are no specific local policy checks). For example, checks (or there are no specific local policy checks). For example,
an ADMD policy might require that the signature(s) on the message be an ADMD policy might require that the signature(s) on the message be
added using the DNS domain present in the From header field of the added using the DNS domain present in the From header field of the
message, thus making third-party signatures unacceptable even if they message, thus making third-party signatures unacceptable even if they
verify. verify.
Both DKIM and DomainKeys use the same result set, as follows: The DKIM result set is as follows:
none: The message was not signed. none: The message was not signed.
pass: The message was signed, the signature or signatures were pass: The message was signed, the signature or signatures were
acceptable to the ADMD, and the signature(s) passed verification acceptable to the ADMD, and the signature(s) passed verification
tests. tests.
fail: The message was signed and the signature or signatures were fail: The message was signed and the signature or signatures were
acceptable to the ADMD, but they failed the verification test(s). acceptable to the ADMD, but they failed the verification test(s).
skipping to change at page 18, line 16 skipping to change at page 18, line 9
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".
Note that in an EAI-formatted message, the values of the "d" and "i" Note that in an EAI-formatted message, the values of the "d" and "i"
properties can be expressed in UTF-8. properties can be expressed in UTF-8.
In addition to previous registrations, this document registers the In addition to previous registrations, this document registers the
DKIM tag "a" (cryptographic algorithm used to sign the message) as a DKIM tags "a" (cryptographic algorithm used to sign the message) and
reportable property. This can be used to aid receivers during post- "s" (selector) as reportable properties. This can be used to aid
verification processing. In particular, [RFC8301] obsoleted use of receivers during post-verification processing. In particular,
the "rsa-sha1" algorithm in DKIM, so it is important to be able to [RFC8301] obsoleted use of the "rsa-sha1" algorithm in DKIM, so it is
distinguish such signatures from those using preferred algorithms. important to be able to distinguish such signatures from those using
preferred algorithms.
The ability to report different DKIM results for a message with The ability to report different DKIM results for a message with
multiple signatures 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 2.7.2. SPF
address of the message is determined. DomainKeys results are thus
reported along with the signing domain name, the sending address of
the message, and the name of the header field from which the latter
was extracted. This means that a DomainKeys result includes a ptype-
property combination of "header.d", plus one of "header.from" and
"header.sender". The sending address extracted from the header is
included with any [MAIL]-style comments removed; moreover, the local-
part of the address and the "@" character are removed if it has not
been authenticated in some way.
2.7.2. SPF and Sender ID
SPF and Sender ID use the "spf" and "sender-id" method names, SPF uses the "spf" method name. The result values for SPF are
respectively. The result values for SPF are defined in Section 2.6 defined in Section 2.6 of [SPF], and those definitions are included
of [SPF], and those definitions are included here by reference: here by reference:
+-----------+------------------------------+ +-----------+------------------------------+
| Code | Meaning | | Code | Meaning |
+-----------+------------------------------+ +-----------+------------------------------+
| none | [SPF], Section 2.6.1 | | none | [SPF], Section 2.6.1 |
+-----------+------------------------------+ +-----------+------------------------------+
| pass | [SPF], Section 2.6.3 | | pass | [SPF], Section 2.6.3 |
+-----------+------------------------------+ +-----------+------------------------------+
| fail | [SPF], Section 2.6.4 | | fail | [SPF], Section 2.6.4 |
+-----------+------------------------------+ +-----------+------------------------------+
skipping to change at page 19, line 38 skipping to change at page 19, line 15
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".)
Note that in an EAI-formatted message, the local-part of the Note that in an EAI-formatted message, the local-part of the
"mailfrom" can be expressed in UTF-8 and the domain part can be "mailfrom" can be expressed in UTF-8 and the domain part can be
expressed as a U-label. expressed as a U-label.
The "sender-id" method is described in [SENDERID]. For this method, For this method, an additional result of "policy" is defined, which
the ptype used is "header" and the property will be the name of the
header field from which the Purported Responsible Address (see [PRA])
was extracted -- namely, one of "Resent-Sender", "Resent-From",
"Sender", or "From".
The results for Sender ID are listed and described in Section 4.2 of
[SENDERID], but for the purposes of this specification, the SPF
definitions enumerated above are used instead. Also, [SENDERID]
specifies result codes that use mixed case, but they are used all
lowercase in this context.
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
the sender's DNS domain according to the authentication method's the sender's DNS domain according to the authentication method's
algorithm, but local policy dictates that the result is unacceptable. algorithm, but local policy dictates that the result is unacceptable.
For example, "policy" might be used if SPF returns a "pass" result, For example, "policy" might be used if SPF returns a "pass" result,
but a local policy check matches the sending DNS domain to one found but a local policy check matches the sending DNS domain to one found
in an explicit list of unacceptable DNS domains (e.g., spammers). in an explicit list of unacceptable DNS domains (e.g., spammers).
If the retrieved sender policies used to evaluate SPF and Sender ID If the retrieved sender policies used to evaluate SPF do not contain
do not contain explicit provisions for authenticating the local-part explicit provisions for authenticating the local-part (see Section
(see Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported 3.4.1 of [MAIL]) of an address, the "pvalue" reported along with
along with results for these mechanisms SHOULD NOT include the local- results for this mechanism SHOULD NOT include the local-part or the
part or the following "@" character. following "@" character.
2.7.3. "iprev" 2.7.3. "iprev"
The result values used by the "iprev" method, defined in Section 3, The result values used by the "iprev" method, defined in Section 3,
are as follows: are as follows:
pass: The DNS evaluation succeeded, i.e., the "reverse" and pass: The DNS evaluation succeeded, i.e., the "reverse" and
"forward" lookup results were returned and were in agreement. "forward" lookup results were returned and were in agreement.
fail: The DNS evaluation failed. In particular, the "reverse" and fail: The DNS evaluation failed. In particular, the "reverse" and
skipping to change at page 25, line 37 skipping to change at page 25, line 8
An MTA adding this header field has to take steps to identify it as An MTA adding this header field has to take steps to identify it as
legitimate to the MUAs or downstream filters that will ultimately legitimate to the MUAs or downstream filters that will ultimately
consume its content. One process to do so is described in Section 5. consume its content. One process to do so is described in Section 5.
Further measures may be necessary in some environments. Some Further measures may be necessary in some environments. Some
possible solutions are enumerated in Section 7.1. This document does possible solutions are enumerated in Section 7.1. This document does
not mandate any specific solution to this issue as each environment not mandate any specific solution to this issue as each environment
has its own facilities and limitations. has its own facilities and limitations.
Most known message authentication methods focus on a particular Most known message authentication methods focus on a particular
identifier to evaluate. SPF and Sender ID differ in that they can identifier to evaluate. SPF differs in that it can yield a result
yield a result based on more than one identifier; specifically, SPF based on more than one identifier; specifically, SPF can evaluate the
can evaluate the RFC5321.HELO parameter or the RFC5321.MailFrom RFC5321.HELO parameter or the RFC5321.MailFrom parameter. When
parameter, and Sender ID can evaluate the RFC5321.MailFrom parameter generating this field to report those results, only the parameter
or the Purported Responsible Address (PRA) identity. When generating that yielded the result is included.
this field to report those results, only the parameter that yielded
the result is included.
For MTAs that add this header field, adding header fields in order For MTAs that add this header field, adding header fields in order
(at the top), per Section 3.6 of [MAIL], is particularly important. (at the top), per Section 3.6 of [MAIL], is particularly important.
Moreover, this header field SHOULD be inserted above any other trace Moreover, this header field SHOULD be inserted above any other trace
header fields such MTAs might prepend. This placement allows easy header fields such MTAs might prepend. This placement allows easy
detection of header fields that can be trusted. detection of header fields that can be trusted.
End users making direct use of this header field might inadvertently End users making direct use of this header field might inadvertently
trust information that has not been properly vetted. If, for trust information that has not been properly vetted. If, for
example, a basic SPF result were to be relayed that claims an example, a basic SPF result were to be relayed that claims an
skipping to change at page 31, line 16 skipping to change at page 30, line 35
| Method | ptype | Property | | Method | ptype | Property |
+------------+--------+----------------------------------+ +------------+--------+----------------------------------+
| auth | smtp | auth | | auth | smtp | auth |
+------------+--------+----------------------------------+ +------------+--------+----------------------------------+
| auth | smtp | mailfrom | | auth | smtp | mailfrom |
+------------+--------+----------------------------------+ +------------+--------+----------------------------------+
| dkim | header | d | | dkim | header | d |
+------------+--------+----------------------------------+ +------------+--------+----------------------------------+
| dkim | header | i | | dkim | header | i |
+------------+--------+----------------------------------+ +------------+--------+----------------------------------+
| domainkeys | header | d |
+------------+--------+----------------------------------+
| domainkeys | header | from |
+------------+--------+----------------------------------+
| domainkeys | header | sender |
+------------+--------+----------------------------------+
| iprev | policy | iprev | | iprev | policy | iprev |
+------------+--------+----------------------------------+ +------------+--------+----------------------------------+
| sender-id | header | name of header field used by PRA |
+------------+--------+----------------------------------+
| spf | smtp | mailfrom | | spf | smtp | mailfrom |
+------------+--------+----------------------------------+ +------------+--------+----------------------------------+
| spf | smtp | helo | | spf | smtp | helo |
+------------+--------+----------------------------------+ +------------+--------+----------------------------------+
In addition, two new entries are added to this registry, as follows: Notably, the DomainKeys and Sender ID entries are not updated to
refer to this revised specification, as they are considered obsolete.
IANA is accordingly asked to change the Status of the "sender-id"
entry in this table to "deprecated".
6.3.1. 'header.a' for DKIM Finally, two new entries are added to this registry, as follows:
6.3.1. 'header.a' for DKIM
Method: dkim Method: dkim
Definition: [this document] Definition: [this document]
ptype: header ptype: header
property: a property: a
Description: value of signature "a" tag Description: value of signature "a" tag
skipping to change at page 33, line 47 skipping to change at page 33, line 12
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.7. "Email Authentication Result Names" Registry Update 6.7. "Email Authentication Result Names" Registry Update
The following entries in this registry are to be updated to reflect The following entries in this registry are to be updated to reflect
new Specifications as follows: this new Specification as follows:
o All "auth" method result codes ("fail", "none", "pass", o All "auth" method result codes ("fail", "none", "pass",
"permerror", "temperror") are now specified in Section 2.7.4 of "permerror", "temperror") are now specified in Section 2.7.4 of
this document. this document.
o All "dkim" method result names ("fail", "neutral", "none", "pass", o All "dkim" method result names ("fail", "neutral", "none", "pass",
"permerror", "policy", "temperror") are now specified in "permerror", "policy", "temperror") are now specified in
Section 2.7.1 of this document. Section 2.7.1 of this document.
o All "iprev" method result names ("fail", "pass", "permerror", o All "iprev" method result names ("fail", "pass", "permerror",
"temperror") are now specified in Section 2.7.3 of this document. "temperror") are now specified in Section 2.7.3 of this document.
o The "sender-id" and "spf" method result names "fail", "neutral", o The "spf" method result names "fail", "neutral", "none", "pass",
"none", "pass", "permerror", "policy", "softfail", and "temperror" "permerror", "policy", "softfail", and "temperror" are now
are now specified in Section 2.7.2 of this document. The specified in Section 2.7.2 of this document. The registration for
registrations for result name "hardfail" are not updated. result name "hardfail" is not updated.
The following entries in this registry are to be updated with a new
Status of "deprecated", with no change to the Specification as they
reference historic protocols:
o All "domainkeys" method result names ("fail", "neutral", "none",
"pass", "permerror", "policy", and "temperror").
o All "sender-id" method result names ("fail", "neutral", "none",
"pass", "permerror", "policy", "softfail", and "temperror").
6.8. SMTP Enhanced Status Codes 6.8. 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 "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes
Registry" is to be updated to refer only to Section 3.3 of [AUTH-ESC] Registry" is to be updated to refer only to Section 3.3 of [AUTH-ESC]
as that is where that registration was done. as that is where that registration was done.
7. Security Considerations 7. Security Considerations
skipping to change at page 41, line 33 skipping to change at page 41, line 9
<http://www.rfc-editor.org/info/rfc8126>. <http://www.rfc-editor.org/info/rfc8126>.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<http://www.rfc-editor.org/info/rfc3501>. <http://www.rfc-editor.org/info/rfc3501>.
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
<http://www.rfc-editor.org/info/rfc1939>. <http://www.rfc-editor.org/info/rfc1939>.
[PRA] Lyon, J., "Purported Responsible Address in E-Mail
Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006,
<http://www.rfc-editor.org/info/rfc4407>.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating [RFC5451] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, DOI 10.17487/ Message Authentication Status", RFC 5451, DOI 10.17487/
RFC5451, April 2009, RFC5451, April 2009,
<https://www.rfc-editor.org/info/rfc5451>. <https://www.rfc-editor.org/info/rfc5451>.
[RFC6008] Kucherawy, M., "Authentication-Results Registration for [RFC6008] Kucherawy, M., "Authentication-Results Registration for
Differentiating among Cryptographic Results", RFC 6008, Differentiating among Cryptographic Results", RFC 6008,
DOI 10.17487/RFC6008, September 2010, DOI 10.17487/RFC6008, September 2010,
<https://www.rfc-editor.org/info/rfc6008>. <https://www.rfc-editor.org/info/rfc6008>.
skipping to change at page 46, line 14 skipping to change at page 45, line 14
B.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; iprev=pass
sender-id=pass header.from=example.net policy.iprev=192.0.2.200
Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6) Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6)
(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 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 "iprev" 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-up connection (example.net) sends mail to a border MTA dial-up connection (example.net) sends mail to a border MTA
(example.com) using SMTP authentication to prove identity. The (example.com) using SMTP authentication to prove identity. The
dial-up provider has been explicitly authorized to relay mail as dial-up provider has been explicitly authorized to relay mail as
example.net, producing "pass" results from the SPF and Sender ID example.net, producing a "pass" result from the SPF check.
checks.
B.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;
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])
by auth-checker.example.com (8.11.6/8.11.6) by auth-checker.example.com (8.11.6/8.11.6)
with ESMTP id i7PK0sH7021929; with ESMTP id i7PK0sH7021929;
Fri, Feb 15 2002 17:19:22 -0800 Fri, Feb 15 2002 17:19:22 -0800
DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com;
t=1188964191; c=simple/simple; h=From:Date:To:Subject: t=1188964191; c=simple/simple; h=From:Date:To:Subject:
Message-Id:Authentication-Results; Message-Id:Authentication-Results;
bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
skipping to change at page 47, line 52 skipping to change at page 46, line 51
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.
The second MTA, auth-checker.example.com, reports that it did a The second MTA, auth-checker.example.com, reports that it did a DKIM
Sender ID test (which failed) and a DKIM test (which passed). Again, test (which passed). Again, additional data about one of the tests
additional data about one of the tests is provided as a comment, is provided as a comment, which the MUA may choose to render. Also
which the MUA may choose to render. Also noteworthy here is the fact noteworthy here is the fact that there is a DKIM signature added by
that there is a DKIM signature added by example.com that assured the example.com that assured the integrity of the lower Authentication-
integrity of the lower Authentication-Results field. 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 a message into
example.com from a user on a dial-up connection example.net. The example.com from a user on a dial-up connection example.net. The
user 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 test authentication at the border MTA using SMTP AUTH. The SPF test
failed since example.com has not granted example.net's dial-up failed since example.com has not granted example.net's dial-up
network authority to relay mail on its behalf. The Sender ID test network authority to relay mail on its behalf. The DKIM test passed
failed since example.com has not granted mail-router.example.com
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 mail-router.example.com used example.com's published public keys and mail-router.example.com used
it to sign the message. it to sign the message.
B.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;
skipping to change at page 53, line 5 skipping to change at page 51, line 48
o Added IANA registration for DKIM "a" and "s" properties. o Added IANA registration for DKIM "a" and "s" properties.
o Include EAI guidance. o Include EAI guidance.
o Adjust some ABNF tokes and names for easier inclusion by other o Adjust some ABNF tokes and names for easier inclusion by other
documents. documents.
o Made minor editorial adjustments. o Made minor editorial adjustments.
o Deprecate entries from RFCs that are now Historic.
Appendix E. Acknowledgments Appendix E. Acknowledgments
The author wishes to acknowledge the following individuals for their The author wishes to acknowledge the following individuals for their
review and constructive criticism of this document: Seth Blank, Tim review and constructive criticism of this document: Kurt Andersen,
Draegen, Scott Kitterman, John Levine, and Alessandro Vesely. Seth Blank, Tim Draegen, Scott Kitterman, John Levine, and Alessandro
Vesely.
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
United States United States
Email: superuser@gmail.com Email: superuser@gmail.com
 End of changes. 51 change blocks. 
146 lines changed or deleted 120 lines changed or added

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