draft-ietf-dmarc-rfc7601bis-02.txt   draft-ietf-dmarc-rfc7601bis-03.txt 
DMARC Working Group M. Kucherawy DMARC Working Group M. Kucherawy
Internet-Draft May 9, 2018 Internet-Draft August 22, 2018
Obsoletes: 7601 (if approved) Obsoletes: 7601 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: November 10, 2018 Expires: February 23, 2019
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-dmarc-rfc7601bis-02 draft-ietf-dmarc-rfc7601bis-03
Abstract Abstract
This document specifies a message header field called Authentication- This document specifies a message header field called Authentication-
Results for use with electronic mail messages to indicate the results Results for use with electronic mail messages to indicate the results
of message authentication efforts. Any receiver-side software, such of message authentication efforts. Any receiver-side software, such
as mail filters or Mail User Agents (MUAs), can use this header field as mail filters or Mail User Agents (MUAs), can use this header field
to relay that information in a convenient and meaningful way to users to relay that information in a convenient and meaningful way to users
or to make sorting and filtering decisions. or to make sorting and filtering decisions.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 November 10, 2018. This Internet-Draft will expire on February 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 24 skipping to change at page 2, line 24
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7 1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7
1.5.2. Internationalized Email . . . . . . . . . . . . . . . 7 1.5.2. Internationalized Email . . . . . . . . . . . . . . . 7
1.5.3. Security . . . . . . . . . . . . . . . . . . . . . . . 7 1.5.3. Security . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.4. Email Architecture . . . . . . . . . . . . . . . . . . 8 1.5.4. Email Architecture . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . 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 . . . . . . . . . . 13
2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 13 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 14
2.5. Authentication Identifier Field . . . . . . . . . . . . . 14 2.5. Authentication Identifier Field . . . . . . . . . . . . . 14
2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . 16 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16
2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 18 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 18
2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . 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 . . . . . . . . . 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 . . . . . . . . . . . . . . . 27 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6.1. The Authentication-Results Header Field . . . . . . . . . 28 6.1. The Authentication-Results Header Field . . . . . . . . . 28
6.2. "Email Authentication Methods" Registry Description . . . 28 6.2. "Email Authentication Methods" Registry Description . . . 28
6.3. "Email Authentication Methods" Registry Update . . . . . . 28 6.3. "Email Authentication Methods" Registry Update . . . . . . 28
6.3.1. 'header.a' for DKIM . . . . . . . . . . . . . . . . . 29
6.3.2. 'header.s' for DKIM . . . . . . . . . . . . . . . . . 29
6.4. "Email Authentication Property Types" Registry . . . . . . 29 6.4. "Email Authentication Property Types" Registry . . . . . . 29
6.5. "Email Authentication Result Names" Description . . . . . 29 6.5. "Email Authentication Result Names" Description . . . . . 29
6.6. "Email Authentication Result Names" Update . . . . . . . . 29 6.6. "Email Authentication Result Names" Update . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 30 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 30
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 31 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 32
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 32 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 32
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 32 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 32
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 32 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 32
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 32 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 32
7.7. Attacks against Authentication Methods . . . . . . . . . . 32 7.7. Attacks against Authentication Methods . . . . . . . . . . 33
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 33 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 33
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 33 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 33
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 33 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 33
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 33 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. Normative References . . . . . . . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . . 34
8.2. Informative References . . . . . . . . . . . . . . . . . . 35 8.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 37 Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 38
Appendix B. Authentication-Results Examples . . . . . . . . . . . 38 Appendix B. Authentication-Results Examples . . . . . . . . . . . 38
B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 38 B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 39
B.2. Nearly Trivial Case; Service Provided, but No B.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 39 Authentication Done . . . . . . . . . . . . . . . . . . . 39
B.3. Service Provided, Authentication Done . . . . . . . . . . 40 B.3. Service Provided, Authentication Done . . . . . . . . . . 40
B.4. Service Provided, Several Authentications Done, Single B.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.5. Service Provided, Several Authentications Done, B.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 42 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 42
B.6. Service Provided, Multi-tiered Authentication Done . . . . 44 B.6. Service Provided, Multi-tiered Authentication Done . . . . 44
B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 45 B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 45
Appendix C. Operational Considerations about Message Appendix C. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 46 Authentication . . . . . . . . . . . . . . . . . . . 46
Appendix D. Changes Since RFC7601 . . . . . . . . . . . . . . . . 47 Appendix D. Changes Since RFC7601 . . . . . . . . . . . . . . . . 47
Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . . 47 Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . . 47
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48
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 5, line 12 skipping to change at page 5, line 12
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 The goal of this work is to give current and future authentication
authentication schemes, but the existing schemes in that family have schemes a common framework within which to deliver their results to
proven to be a good starting point for implementations. The goal is downstream agents and discourage the creation of unique header fields
to give current and future authentication schemes a common framework for each.
within which to deliver their results to downstream agents and
discourage the creation of unique header fields for each.
Although SPF defined a header field called "Received-SPF" and the Although SPF defined a header field called "Received-SPF" and the
historic DomainKeys defined one called "DomainKey-Status" for this historic DomainKeys defined one called "DomainKey-Status" for this
purpose, those header fields are specific to the conveyance of their purpose, those header fields are specific to the conveyance of their
respective results only and thus are insufficient to satisfy the respective results only and thus are insufficient to satisfy the
requirements enumerated below. In addition, many SPF implementations requirements enumerated below. In addition, many SPF implementations
have adopted the header field specified here at least as an option, have adopted the header field specified here at least as an option,
and DomainKeys has been obsoleted by DKIM. and DomainKeys has been obsoleted by DKIM.
1.1. Purpose 1.1. Purpose
skipping to change at page 5, line 46 skipping to change at page 5, line 44
results to end users or to use those data to apply more or less results to end users or to use those data to apply more or less
stringent content checks based on authentication results; stringent content checks based on authentication results;
2. Provide a common location within a message for this data; 2. Provide a common location within a message for this data;
3. Create an extensible framework for reporting new authentication 3. Create an extensible framework for reporting new authentication
methods as they emerge. methods as they emerge.
In particular, the mere presence of this header field does not mean In particular, the mere presence of this header field does not mean
its contents are valid. Rather, the header field is reporting its contents are valid. Rather, the header field is reporting
assertions made by one or more authentication schemes (supposedly) assertions made by one or more authentication schemes applied
applied somewhere upstream. For an MUA or downstream filter to treat somewhere upstream. For an MUA or downstream filter to treat the
the assertions as actually valid, there must be an assessment of the assertions as actually valid, there must be an assessment of the
trust relationship among such agents, the validating MTA, and the trust relationship among such agents, the validating MTA, and the
mechanism for conveying the information. mechanism for conveying the information.
1.2. Trust Boundary 1.2. Trust Boundary
This document makes several references to the "trust boundary" of an This document makes several references to the "trust boundary" of an
administrative management domain (ADMD). Given the diversity among administrative management domain (ADMD). Given the diversity among
existing mail environments, a precise definition of this term isn't existing mail environments, a precise definition of this term isn't
possible. possible.
skipping to change at page 7, line 23 skipping to change at page 7, line 23
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
1.5.2. Internationalized Email 1.5.2. Internationalized Email
In this document, there are references to messages formatted to In this document, there are references to messages formatted to
support Email Address Internationalization (EAI). Reference material support Email Address Internationalization (EAI). Reference material
for this can be found in [RFC6530], [RFC6531], and [RFC6532]. for this can be found in [RFC6530], [RFC6531], and [RFC6532].
Generally speaking, these documents allow UTF-8 in most places that Generally speaking, these documents allow UTF-8 in most places that
free-form text can be found, and U-labels where domain names can be free-form text can be found and U-labels where domain names can be
used, and this document extends Authentication-Results accordingly. used, and this document extends Authentication-Results accordingly.
1.5.3. Security 1.5.3. Security
"Guidelines for Writing RFC Text on Security Considerations" "Guidelines for Writing RFC Text on Security Considerations"
([SECURITY]) discusses authentication and authorization and the ([SECURITY]) discusses authentication and authorization and the
conflation of the two concepts. The use of those terms within the conflation of the two concepts. The use of those terms within the
context of recent message security work has given rise to slightly context of recent message security work has given rise to slightly
different definitions, and this document reflects those current different definitions, and this document reflects those current
usages, as follows: usages, as follows:
skipping to change at page 8, line 11 skipping to change at page 8, line 11
the message itself. By contrast, DKIM is agnostic as to the routing the message itself. By contrast, DKIM is agnostic as to the routing
of a message but uses cryptographic signatures to authenticate of a message but uses cryptographic signatures to authenticate
agents, assign (some) responsibility for the message (which implies agents, assign (some) responsibility for the message (which implies
authorization), and ensure that the listed portions of the message authorization), and ensure that the listed portions of the message
were not modified in transit. Since the signatures are not tied to were not modified in transit. Since the signatures are not tied to
SMTP connections, they can be added by either the ADMD of origin, SMTP connections, they can be added by either the ADMD of origin,
intermediate ADMDs (such as a mailing list server), other handling intermediate ADMDs (such as a mailing list server), other handling
agents, or any combination. agents, or any 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 proposal groups them both into a single header field. solution, this specification groups them both into a single header
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.)
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.
skipping to change at page 9, line 29 skipping to change at page 9, line 31
1.6. Trust Environment 1.6. Trust Environment
This header field permits one or more message validation mechanisms This header field permits one or more message validation mechanisms
to communicate output to one or more separate assessment mechanisms. to communicate output to one or more separate assessment mechanisms.
These mechanisms operate within a unified trust boundary that defines These mechanisms operate within a unified trust boundary that defines
an Administrative Management Domain (ADMD). An ADMD contains one or an Administrative Management Domain (ADMD). An ADMD contains one or
more entities that perform validation and generate the header field more entities that perform validation and generate the header field
and one or more that consume it for some type of assessment. The and one or more that consume it for some type of assessment. The
field often contains no integrity or validation mechanism of its own, field often contains no integrity or validation mechanism of its own,
so its presence must be trusted implicitly. Hence, valid use of the so its presence must be trusted implicitly. Hence, valid use of the
header field requires removing any occurrences of it that are present header field requires removing any occurrences of it that claim to be
when the message enters the ADMD. This ensures that later associated with the ADMD when the message enters the ADMD. This
occurrences have been added within the trust boundary of the ADMD. ensures that later occurrences have been added within the trust
boundary of the ADMD.
The authserv-id token defined in Section 2.2 can be used to reference The authserv-id token defined in Section 2.2 can be used to reference
an entire ADMD or a specific validation engine within an ADMD. an entire ADMD or a specific validation engine within an ADMD.
Although the labeling scheme is left as an operational choice, some Although the labeling scheme is left as an operational choice, some
guidance for selecting a token is provided in later sections of this guidance for selecting a token is provided in later sections of this
document. document.
2. Definition and Format of the Header Field 2. Definition and Format of the Header Field
This section gives a general overview of the format of the header This section gives a general overview of the format of the header
field being defined and then provides more formal specification. field being defined and then provides a formal specification.
2.1. General Description 2.1. General Description
The header field specified here is called Authentication-Results. It The header field specified here is called Authentication-Results. It
is a Structured Header Field as defined in Internet Message Format is a Structured Header Field as defined in Internet Message Format
([MAIL]), and thus all of the related definitions in that document ([MAIL]), and thus all of the related definitions in that document
apply. apply.
This header field is added at the top of the message as it transits This header field is added at the top of the message as it transits
MTAs that do authentication checks, so some idea of how far away the MTAs that do authentication checks, so some idea of how far away the
skipping to change at page 12, line 11 skipping to change at page 12, line 15
[CFWS] [CFWS]
; the value extracted from the message property defined ; the value extracted from the message property defined
; by the "ptype.property" construction ; by the "ptype.property" construction
"local-part" is defined in Section 3.4.1 of [MAIL], as modified by "local-part" is defined in Section 3.4.1 of [MAIL], as modified by
[RFC6531]. [RFC6531].
"CFWS" is defined in Section 3.2.2 of [MAIL]. "CFWS" is defined in Section 3.2.2 of [MAIL].
"domain-name" is as defined in Section 3.5 of [DKIM] where the "d=" "domain-name" is as defined in Section 3.5 of [DKIM] where the "d="
tag is defined, with "sob-domain" as modified by by [RFC6531]. tag is defined, with "sub-domain" as modified by [RFC6531].
"Keyword" is defined in Section 4.1.2 of [SMTP]. When used in "Keyword" is defined in Section 4.1.2 of [SMTP]. It is further
"result" above, it is further constrained by the necessity of being constrained by the necessity of being registered in the IANA registry
enumerated in Section 2.7. relevant to the context in which it is used. See Section 2.7,
Section 2.3, and Section 6.
"value" is as defined in Section 5.1 of [MIME]. "value" is as defined in Section 5.1 of [MIME].
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 email 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 still has a result
report. to report. It may also be omitted if the agent generating this
result wishes not to reveal such properties to downstream agents.
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.
skipping to change at page 14, line 15 skipping to change at page 14, line 24
For example, a DKIM signature is not required to include the Subject For example, a DKIM signature is not required to include the Subject
header field in the set of fields that are signed. An ADMD receiving header field in the set of fields that are signed. An ADMD receiving
such a message might decide that such a signature is unacceptable, such a message might decide that such a signature is unacceptable,
even if it passes, because the content of the Subject header field even if it passes, because the content of the Subject header field
could be altered post-signing without invalidating the signature. could be altered post-signing without invalidating the signature.
Such an ADMD could replace the DKIM "pass" result with a "policy" Such an ADMD could replace the DKIM "pass" result with a "policy"
result and then also include the following in the corresponding result and then also include the following in the corresponding
Authentication-Result field: Authentication-Result field:
... dkim=fail policy.dkim-rules=unsigned-subject ... ... dkim=policy policy.dkim-rules=unsigned-subject ...
In this case, the property is "dkim-rules", indicating some local In this case, the property is "dkim-rules", indicating some local
check by that name took place and that check returned a result of check by that name took place and that check returned a result of
"unsigned-subject". These are arbitrary names selected by (and "unsigned-subject". These are arbitrary names selected by (and
presumably used within) the ADMD making use of them, so they are not presumably used within) the ADMD making use of them, so they are not
normally registered with IANA or otherwise specified apart from normally registered with IANA or otherwise specified apart from
setting syntax restrictions that allow for easy parsing within the setting syntax restrictions that allow for easy parsing within the
rest of the header field. rest of the header field.
This ptype existed in the original specification for this header This ptype existed in the original specification for this header
skipping to change at page 15, line 12 skipping to change at page 15, line 22
For simplicity and scalability, the authentication service identifier For simplicity and scalability, the authentication service identifier
SHOULD be a common token used throughout the ADMD. Common practice SHOULD be a common token used throughout the ADMD. Common practice
is to use the DNS domain name used by or within that ADMD, sometimes is to use the DNS domain name used by or within that ADMD, sometimes
called the "organizational domain", but this is not strictly called the "organizational domain", but this is not strictly
necessary. necessary.
For tracing and debugging purposes, the authentication identifier can For tracing and debugging purposes, the authentication identifier can
instead be the specific hostname of the MTA performing the instead be the specific hostname of the MTA performing the
authentication check whose result is being reported. Moreover, some authentication check whose result is being reported. Moreover, some
implementations define a substructure to the identifier; these are implementations define a substructure to the identifier; such
outside of the scope of this specification. structures are outside of the scope of this specification.
Note, however, that using a local, relative identifier like a flat Note, however, that using a local, relative identifier like a flat
hostname, rather than a hierarchical and globally unique ADMD hostname, rather than a hierarchical and globally unique ADMD
identifier like a DNS domain name, makes configuration more difficult identifier like a DNS domain name, makes configuration more difficult
for large sites. The hierarchical identifier permits aggregating for large sites. The hierarchical identifier permits aggregating
related, trusted systems together under a single, parent identifier, related, trusted systems together under a single, parent identifier,
which in turn permits assessing the trust relationship with a single which in turn permits assessing the trust relationship with a single
reference. The alternative is a flat namespace requiring reference. The alternative is a flat namespace requiring
individually listing each trusted system. Since consumers will use individually listing each trusted system. Since consumers will use
the identifier to determine whether to use the contents of the header the identifier to determine whether to use the contents of the header
skipping to change at page 22, line 36 skipping to change at page 22, line 41
the parameters associated with them are not documented in RFCs. the parameters associated with them are not documented in RFCs.
Therefore, they are subject to change at any time and not suitable Therefore, they are subject to change at any time and not suitable
for production use. Any MTA, MUA, or downstream filter intended for for production use. Any MTA, MUA, or downstream filter intended for
production use SHOULD ignore or delete any Authentication-Results production use SHOULD ignore or delete any Authentication-Results
header field that includes an experimental (unknown) method header field that includes an experimental (unknown) method
identifier. identifier.
2.7.7. Extension Result Codes 2.7.7. Extension Result Codes
Additional result codes (extension results) might be defined in the Additional result codes (extension results) might be defined in the
future by later revisions or extensions to this specification. future by later revisions or extensions to this specification. Non-
Result codes MUST be registered with the Internet Assigned Numbers experimental result codes MUST be registered with the Internet
Authority (IANA) and preferably published in an RFC. See Section 6 Assigned Numbers Authority (IANA) and preferably published in an RFC.
for further details. See Section 6 for further details.
Experimental results MUST only be used within ADMDs that have Experimental results MUST only be used within ADMDs that have
explicitly consented to use them. These results and the parameters explicitly consented to use them. These results and the parameters
associated with them are not formally documented. Therefore, they associated with them are not formally documented. Therefore, they
are subject to change at any time and not suitable for production are subject to change at any time and not suitable for production
use. Any MTA, MUA, or downstream filter intended for production use use. Any MTA, MUA, or downstream filter intended for production use
SHOULD ignore or delete any Authentication-Results header field that SHOULD ignore or delete any Authentication-Results header field that
includes an extension result. includes an extension result.
3. The "iprev" Authentication Method 3. The "iprev" Authentication Method
skipping to change at page 24, line 32 skipping to change at page 24, line 38
Each "method" MUST refer to an authentication method declared in the Each "method" MUST refer to an authentication method declared in the
IANA registry or an extension method as described in Section 2.7.6, IANA registry or an extension method as described in Section 2.7.6,
and each "result" MUST refer to a result code declared in the IANA and each "result" MUST refer to a result code declared in the IANA
registry or an extension result code as defined in Section 2.7.7. registry or an extension result code as defined in Section 2.7.7.
See Section 6 for further information about the registered methods See Section 6 for further information about the registered methods
and result codes. and result codes.
An MTA compliant with this specification adds this header field An MTA compliant with this specification adds this header field
(after performing one or more message authentication tests) to (after performing one or more message authentication tests) to
indicate which MTA or ADMD performed the test, which test got indicate which MTA or ADMD performed the test, which test was
applied, and what the result was. If an MTA applies more than one applied, and what the result was. If an MTA applies more than one
such test, it adds this header field either once per test or once such test, it adds this header field either once per test or once
indicating all of the results. An MTA MUST NOT add a result to an indicating all of the results. An MTA MUST NOT add a result to an
existing header field. existing header field.
An MTA MAY add this header field containing only the authentication An MTA MAY add this header field containing only the authentication
identifier portion and the "none" token (see Section 2.2) to indicate identifier portion and the "none" token (see Section 2.2) to indicate
explicitly that no message authentication schemes were applied prior explicitly that no message authentication schemes were applied prior
to delivery of this message. to delivery of this message.
skipping to change at page 25, line 42 skipping to change at page 25, line 49
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 (1) 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 (2) instances of the header field is ultimately read by the MUA, and (2) instances of the header field
that appear 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 of the
appears to be one used within its own ADMD as configured by the user header field is used within the ADMD as configured by the user or
or administrator. 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 "Email Authentication Property Types" "ptype" not listed in the "Email Authentication Property Types"
registry for such values as defined in Section 6. Moreover, such registry for such values as defined in Section 6. Moreover, such
agents MUST ignore a result indicated for any "method" they do not agents MUST ignore a result indicated for any "method" they do not
specifically support. 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
skipping to change at page 27, line 7 skipping to change at page 27, line 12
The same MAY also be done for local policy decisions overriding the The same MAY also be done for local policy decisions overriding the
results of the authentication methods (e.g., the "policy" result results of the authentication methods (e.g., the "policy" result
codes described in Section 2.7). codes described in Section 2.7).
Such rejections at the SMTP protocol level are not possible if local Such rejections at the SMTP protocol level are not possible if local
policy is enforced at the MUA and not the MTA. policy is enforced at the MUA and not the MTA.
5. Removing Existing Header Fields 5. Removing Existing Header Fields
For security reasons, any MTA conforming to this specification MUST To mitigate the impact of forged header fields, any MTA conforming to
delete any discovered instance of this header field that claims, by this specification MUST delete any discovered instance of this header
virtue of its authentication service identifier, to have been added field that claims, by virtue of its authentication service
within its trust boundary but that did not come directly from another identifier, to have been added within its trust boundary but that did
trusted MTA. For example, an MTA for example.com receiving a message not come directly from another trusted MTA. For example, an MTA for
MUST delete or otherwise obscure any instance of this header field example.com receiving a message MUST delete or otherwise obscure any
bearing an authentication service identifier indicating that the instance of this header field bearing an authentication service
header field was added within example.com prior to adding its own identifier indicating that the header field was added within
header fields. This could mean each MTA will have to be equipped example.com prior to adding its own header fields. This could mean
with a list of internal MTAs known to be compliant (and hence each MTA will have to be equipped with a list of internal MTAs known
trustworthy). to be compliant (and hence trustworthy).
For messages that are EAI-formatted messages, this test is done after For messages that are EAI-formatted messages, this test is done after
converting A-labels into U-labels. converting A-labels into U-labels.
For simplicity and maximum security, a border MTA could remove all For simplicity and maximum security, a border MTA could remove all
instances of this header field on mail crossing into its trust instances of this header field on mail crossing into its trust
boundary. However, this may conflict with the desire to access boundary. However, this may conflict with the desire to access
authentication results performed by trusted external service authentication results performed by trusted external service
providers. It may also invalidate signed messages whose signatures providers. It may also invalidate signed messages whose signatures
cover external instances of this header field. A more robust border cover external instances of this header field. A more robust border
skipping to change at page 28, line 42 skipping to change at page 28, line 49
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [this document] Specification document(s): [this document]
Related information: none Related information: none
6.2. "Email Authentication Methods" Registry Description 6.2. "Email Authentication Methods" Registry Description
No changes are made to the description of this registry. No changes are made to the description of this registry.
6.3. "Email Authentication Methods" Registry Update 6.3. "Email Authentication Methods" Registry Update
The following entries are added: The following two entries are added.
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
Status: active Status: active
Version: 1 Version: 1
skipping to change at page 29, line 14 skipping to change at page 29, line 21
ptype: header ptype: header
property: a property: a
Description: value of signature "a" tag Description: value of signature "a" tag
Status: active Status: active
Version: 1 Version: 1
6.3.2. 'header.s' for DKIM
"header.s" for DKIM:
Method: dkim Method: dkim
Definition: [this document] Definition: [this document]
ptype: header ptype: header
property: s property: s
Description: value of signature "s" tag Description: value of signature "s" tag
skipping to change at page 33, line 49 skipping to change at page 34, line 12
after mailbox delivery, MUAs are advised in Section 4.1 to ignore after mailbox delivery, MUAs are advised in Section 4.1 to ignore
such instances within MIME attachments. Moreover, when extracting a such instances within MIME attachments. Moreover, when extracting a
message digest to separate mail store messages or other media, such message digest to separate mail store messages or other media, such
header fields should be removed so that they will never be header fields should be removed so that they will never be
interpreted improperly by MUAs that might later consume them. interpreted improperly by MUAs that might later consume them.
7.11. Reverse Mapping 7.11. Reverse Mapping
Although Section 3 of this memo includes explicit support for the Although Section 3 of this memo includes explicit support for the
"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 specification and agents that use the data
relays are encouraged to become familiar with the issues raised by it 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., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008, RFC5234, January 2008,
skipping to change at page 38, line 18 skipping to change at page 38, line 35
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 (i.e., while this to end users. Until this capability is added (i.e., while this
proposal and its successors are being adopted), other interim means specification and its successors continue to be adopted), other
of conveying authentication results may be necessary. interim means of conveying authentication results may be necessary.
Appendix B. 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.
B.1. Trivial Case; Header Field Not Present B.1. Trivial Case; Header Field Not Present
The trivial case: The trivial case:
skipping to change at page 41, line 47 skipping to change at page 41, line 47
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.com, producing "pass" results from the SPF and Sender ID example.net, producing "pass" results from the SPF and Sender ID
checks. 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; sender-id=fail header.from=example.com;
skipping to change at page 43, line 16 skipping to change at page 43, line 16
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 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 and Sender authentication at the border MTA using SMTP AUTH. The SPF test
ID tests failed since example.com has not granted example.net failed since example.com has not granted example.net's dial-up
network authority to relay mail on its behalf. The Sender ID test
failed since example.com has not granted mail-router.example.com
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 mail-router.example.com used
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;
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"
skipping to change at page 47, line 40 skipping to change at page 47, line 40
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 D. Changes Since RFC7601 Appendix D. Changes Since RFC7601
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 tokens and names for easier inclusion by other
documents.
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, John review and constructive criticism of this document: Seth Blank, Tim
Levine, Scott Kitterman Draegen, John Levine, Scott Kitterman, 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. 40 change blocks. 
71 lines changed or deleted 88 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/