draft-ietf-dmarc-rfc7601bis-00.txt   draft-ietf-dmarc-rfc7601bis-01.txt 
DMARC Working Group M. Kucherawy DMARC Working Group M. Kucherawy
Internet-Draft February 7, 2018 Internet-Draft March 20, 2018
Obsoletes: 7601 (if approved) Obsoletes: 7601 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: August 11, 2018 Expires: September 21, 2018
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-dmarc-rfc7601bis-00 draft-ietf-dmarc-rfc7601bis-01
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 August 11, 2018. This Internet-Draft will expire on September 21, 2018.
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 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 6 1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 6
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7 1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7
1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 7 1.5.2. Internationalized Email . . . . . . . . . . . . . . . 7
1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 8 1.5.3. Security . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 9 1.5.4. Email Architecture . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . 12
2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 13 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 13
2.5. Authentication Identifier Field . . . . . . . . . . . . . 14 2.5. Authentication Identifier Field . . . . . . . . . . . . . 14
2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 15 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 15
2.7. Defined Methods and Result Values . . . . . . . . . . . . 16 2.7. Defined Methods and Result Values . . . . . . . . . . . . 16
2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16
2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 18
2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 20
2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 21 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 21
2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21
2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 22 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 22
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22
4. Adding the Header Field to a Message . . . . . . . . . . . . . 23 4. Adding the Header Field to a Message . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 26 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6.1. The Authentication-Results Header Field . . . . . . . . . 27 6.1. The Authentication-Results Header Field . . . . . . . . . 28
6.2. "Email Authentication Methods" Registry Description . . . 28 6.2. "Email Authentication Methods" Registry . . . . . . . . . 28
6.3. "Email Authentication Methods" Registry Update . . . . . . 28 6.3. "Email Authentication Methods" Registry . . . . . . . . . 28
6.4. "Email Authentication Property Types" Registry . . . . . . 28 6.4. "Email Authentication Property Types" Registry . . . . . . 29
6.5. "Email Authentication Result Names" Description . . . . . 28 6.5. "Email Authentication Result Names" Description . . . . . 29
6.6. "Email Authentication Result Names" Update . . . . . . . . 28 6.6. "Email Authentication Result Names" Update . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 28 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 29
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 30 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 31
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 31 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 31
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 31 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 32
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 31 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 32
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 31 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 32
7.7. Attacks against Authentication Methods . . . . . . . . . . 31 7.7. Attacks against Authentication Methods . . . . . . . . . . 32
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 32 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 32
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 32 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 33
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 32 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 33
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 32 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . . 34 8.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Authentication-Results Examples . . . . . . . . . . . 37 Appendix B. Authentication-Results Examples . . . . . . . . . . . 38
B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 37 B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 38
B.2. Nearly Trivial Case; Service Provided, but No B.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 38 Authentication Done . . . . . . . . . . . . . . . . . . . 39
B.3. Service Provided, Authentication Done . . . . . . . . . . 39 B.3. Service Provided, Authentication Done . . . . . . . . . . 40
B.4. Service Provided, Several Authentications Done, Single B.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.5. Service Provided, Several Authentications Done, B.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 41 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 42
B.6. Service Provided, Multi-tiered Authentication Done . . . . 43 B.6. Service Provided, Multi-tiered Authentication Done . . . . 44
B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 44 B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 45
Appendix C. Operational Considerations about Message Appendix C. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 45 Authentication . . . . . . . . . . . . . . . . . . . 46
Appendix D. Changes since RFC 7001 . . . . . . . . . . . . . . . 46 Appendix D. Changes Since RFC7601 . . . . . . . . . . . . . . . . 47
Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . . 48 Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . . 47
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47
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 7, line 17 skipping to change at page 7, line 17
1.5. Definitions 1.5. Definitions
This section defines various terms used throughout this document. This section defines various terms used throughout this document.
1.5.1. Key Words 1.5.1. Key Words
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. Security 1.5.2. Internationalized Email
In this document, there are references to messages formatted to
support Email Address Internationalization (EAI). Reference material
for this can be found in [RFC6530], [RFC6531], and [RFC6532].
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
used, and this document extends Authentication-Results accordingly.
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:
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
skipping to change at page 8, line 5 skipping to change at page 8, line 13
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 proposal groups them both into a single header field.
1.5.3. 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.
o An "intermediate MTA" is any MTA that is not a delivery MTA and is o An "intermediate MTA" is any MTA that is not a delivery MTA and is
skipping to change at page 9, line 5 skipping to change at page 9, line 12
authentication schemes takes place at a border MTA or a delivery MTA. authentication schemes takes place at a border MTA or a delivery MTA.
This specification is written with that assumption in mind. However, This specification is written with that assumption in mind. However,
there are some sites at which the entire mail infrastructure consists there are some sites at which the entire mail infrastructure consists
of a single host. In such cases, such terms as "border MTA" and of a single host. In such cases, such terms as "border MTA" and
"delivery MTA" might well apply to the same machine or even the very "delivery MTA" might well apply to the same machine or even the very
same agent. It is also possible that some message authentication same agent. It is also possible that some message authentication
tests could take place on an intermediate MTA. Although this tests could take place on an intermediate MTA. Although this
document doesn't specifically describe such cases, they are not meant document doesn't specifically describe such cases, they are not meant
to be excluded. to be excluded.
1.5.4. Other Terms 1.5.5. Other Terms
In this document, the term "producer" refers to any component that In this document, the term "producer" refers to any component that
adds this header field to messages it is handling, and "consumer" adds this header field to messages it is handling, and "consumer"
refers to any component that identifies, extracts, and parses the refers to any component that identifies, extracts, and parses the
header field to use as part of a handling decision. header field to use as part of a handling decision.
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.
skipping to change at page 11, line 46 skipping to change at page 12, line 5
special-smtp-verb = "mailfrom" / "rcptto" special-smtp-verb = "mailfrom" / "rcptto"
; special cases of [SMTP] commands that are made up ; special cases of [SMTP] commands that are made up
; of multiple words ; of multiple words
pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name ) pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name )
[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], and "CFWS" is "local-part" is defined in Section 3.4.1 of [MAIL], as modified by
defined in Section 3.2.2 of [MAIL]. [RFC6531].
"Keyword" is defined in Section 4.1.2 of [SMTP]. "CFWS" is defined in Section 3.2.2 of [MAIL].
The "value" is as defined in Section 5.1 of [MIME]. "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].
The "domain-name" is as defined in Section 3.5 of [DKIM]. "Keyword" is defined in Section 4.1.2 of [SMTP]. When used in
"result" above, it is further constrained by the necessity of being
enumerated in Section 2.7.
The "Keyword" used in "result" above is further constrained by the "value" is as defined in Section 5.1 of [MIME].
necessity of being enumerated in Section 2.7.
See Section 2.5 for a description of the authserv-id element. See Section 2.5 for a description of the authserv-id element.
If the value portion of a "pvalue" construction identifies something If the value portion of a "pvalue" construction identifies something
intended to be an 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].
skipping to change at page 14, line 31 skipping to change at page 14, line 40
2.5. Authentication Identifier Field 2.5. Authentication Identifier Field
Every Authentication-Results header field has an authentication Every Authentication-Results header field has an authentication
service identifier field (authserv-id above). Specifically, this is service identifier field (authserv-id above). Specifically, this is
any string intended to identify the authentication service within the any string intended to identify the authentication service within the
ADMD that conducted authentication checks on the message. This ADMD that conducted authentication checks on the message. This
identifier is intended to be machine-readable and not necessarily identifier is intended to be machine-readable and not necessarily
meaningful to users. meaningful to users.
Note that in an EAI-formatted message, this identifier may be
expressed in UTF-8.
Since agents consuming this field will use this identifier to Since agents consuming this field will use this identifier to
determine whether its contents are of interest (and are safe to use), determine whether its contents are of interest (and are safe to use),
the uniqueness of the identifier MUST be guaranteed by the ADMD that the uniqueness of the identifier MUST be guaranteed by the ADMD that
generates it and MUST pertain to that ADMD. MUAs or downstream generates it and MUST pertain to that ADMD. MUAs or downstream
filters SHOULD use this identifier to determine whether or not the filters SHOULD use this identifier to determine whether or not the
data contained in an Authentication-Results header field ought to be data contained in an Authentication-Results header field ought to be
used or ignored. used or ignored.
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
skipping to change at page 17, line 21 skipping to change at page 17, line 32
is unrecoverable, such as a required header field being absent. A is unrecoverable, such as a required header field being absent. A
later attempt is unlikely to produce a final result. later attempt is unlikely to produce a final result.
DKIM results are reported using a ptype of "header". The property, DKIM results are reported using a ptype of "header". The property,
however, represents one of the tags found in the DKIM-Signature however, represents one of the tags found in the DKIM-Signature
header field rather than a distinct header field. For example, the header field rather than a distinct header field. For example, the
ptype-property combination "header.d" refers to the content of the ptype-property combination "header.d" refers to the content of the
"d" (signing domain) tag from within the signature header field, and "d" (signing domain) tag from within the signature header field, and
not a distinct header field called "d". not a distinct header field called "d".
Note that in an EAI-formatted message, the values of the "d" and "i"
properties can be expressed in UTF-8.
In addition to previous registrations, this document registers the
DKIM tag "a" (cryptographic algorithm used to sign the message) as a
reportable property. This can be used to aid receivers during post-
verification processing. In particular, [RFC8301] obsoleted use of
the "rsa-sha1" algorithm in DKIM, so it is 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 Section 3.1 of [DOMAINKEYS] describes a process by which the sending
skipping to change at page 18, line 34 skipping to change at page 18, line 48
These result codes are used in the context of this specification to These result codes are used in the context of this specification to
reflect the result returned by the component conducting SPF reflect the result returned by the component conducting SPF
evaluation. evaluation.
For SPF, the ptype used is "smtp", and the property is either For SPF, the ptype used is "smtp", and the property is either
"mailfrom" or "helo", since those values are the ones SPF can "mailfrom" or "helo", since those values are the ones SPF can
evaluate. (If the SMTP client issued the EHLO command instead of evaluate. (If the SMTP client issued the EHLO command instead of
HELO, the property used is "helo".) HELO, the property used is "helo".)
Note that in an EAI-formatted message, the "mailfrom" value can be
expressed in UTF-8.
The "sender-id" method is described in [SENDERID]. For this method, The "sender-id" method is described in [SENDERID]. For this method,
the ptype used is "header" and the property will be the name of the the ptype used is "header" and the property will be the name of the
header field from which the Purported Responsible Address (see [PRA]) header field from which the Purported Responsible Address (see [PRA])
was extracted -- namely, one of "Resent-Sender", "Resent-From", was extracted -- namely, one of "Resent-Sender", "Resent-From",
"Sender", or "From". "Sender", or "From".
The results for Sender ID are listed and described in Section 4.2 of The results for Sender ID are listed and described in Section 4.2 of
[SENDERID], but for the purposes of this specification, the SPF [SENDERID], but for the purposes of this specification, the SPF
definitions enumerated above are used instead. Also, [SENDERID] definitions enumerated above are used instead. Also, [SENDERID]
specifies result codes that use mixed case, but they are typically specifies result codes that use mixed case, but they are typically
skipping to change at page 20, line 33 skipping to change at page 21, line 6
such as a permanent directory service lookup error. A later such as a permanent directory service lookup error. A later
attempt is not likely to produce a final result. attempt is not likely to produce a final result.
The result of AUTH is reported using a ptype of "smtp" and a property The result of AUTH is reported using a ptype of "smtp" and a property
of either: of either:
o "auth", in which case the value is the authorization identity o "auth", in which case the value is the authorization identity
generated by the exchange initiated by the AUTH command; or generated by the exchange initiated by the AUTH command; or
o "mailfrom", in which case the value is the mailbox identified by o "mailfrom", in which case the value is the mailbox identified by
the AUTH parameter used with the MAIL FROM command. the AUTH parameter used with the MAIL FROM command. Note that in
an EAI-formatted message, these values can be expressed in UTF-8.
If both identities are available, both can be reported. For example, If both identities are available, both can be reported. For example,
consider this command issued by a client that has completed session consider this command issued by a client that has completed session
authentication with the AUTH command resulting in an authorized authentication with the AUTH command resulting in an authorized
identity of "client@c.example": identity of "client@c.example":
MAIL FROM:<alice@a.example> AUTH=<bob@b.example> MAIL FROM:<alice@a.example> AUTH=<bob@b.example>
This could result in a "resinfo" construction like so: This could result in a "resinfo" construction like so:
skipping to change at page 21, line 21 skipping to change at page 21, line 40
o Authorized Third-Party Signatures (in [ATPS], represented by o Authorized Third-Party Signatures (in [ATPS], represented by
"dkim-atps"); "dkim-atps");
o Author Domain Signing Practices (in [ADSP], represented by "dkim- o Author Domain Signing Practices (in [ADSP], represented by "dkim-
adsp"); adsp");
o Require-Recipient-Valid-Since (in [RRVS], represented by "rrvs"); o Require-Recipient-Valid-Since (in [RRVS], represented by "rrvs");
o S/MIME (in [SMIME-REG], represented by "smime"). o S/MIME (in [SMIME-REG], represented by "smime").
Note that "vbr.mv" and "vbr.md", which are already registered, are
permitted to be UTF-8 in an EAI-formatted message.
2.7.6. Extension Methods 2.7.6. Extension Methods
Additional authentication method identifiers (extension methods) may Additional authentication method identifiers (extension methods) may
be defined in the future by later revisions or extensions to this be defined in the future by later revisions or extensions to this
specification. These method identifiers are registered with the specification. These method identifiers are registered with the
Internet Assigned Numbers Authority (IANA) and, preferably, published Internet Assigned Numbers Authority (IANA) and, preferably, published
in an RFC. See Section 6 for further details. in an RFC. See Section 6 for further details.
Extension methods can be defined for the following reasons: Extension methods can be defined for the following reasons:
skipping to change at page 26, line 45 skipping to change at page 27, line 19
virtue of its authentication service identifier, to have been added virtue of its authentication service identifier, to have been added
within its trust boundary but that did not come directly from another within its trust boundary but that did not come directly from another
trusted MTA. For example, an MTA for example.com receiving a message trusted MTA. For example, an MTA for example.com receiving a message
MUST delete or otherwise obscure any instance of this header field MUST delete or otherwise obscure any instance of this header field
bearing an authentication service identifier indicating that the bearing an authentication service identifier indicating that the
header field was added within example.com prior to adding its own header field was added within example.com prior to adding its own
header fields. This could mean each MTA will have to be equipped header fields. This could mean each MTA will have to be equipped
with a list of internal MTAs known to be compliant (and hence with a list of internal MTAs known to be compliant (and hence
trustworthy). trustworthy).
For messages that are EAI-formatted messages, this test is done after
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
MTA could allow a specific list of authenticating MTAs whose MTA could allow a specific list of authenticating MTAs whose
information is to be admitted, removing the header field originating information is to be admitted, removing the header field originating
from all others. from all others.
skipping to change at page 28, line 14 skipping to change at page 28, line 36
found in [IANA-HEADERS]. That entry will be updated to reference found in [IANA-HEADERS]. That entry will be updated to reference
this document. The following is the registration template: this document. The following is the registration template:
Header field name: Authentication-Results Header field name: Authentication-Results
Applicable protocol: mail ([MAIL]) Applicable protocol: mail ([MAIL])
Status: Standard Status: Standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [this 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
No changes are made to this registry. No changes are made to this registry.
6.3. "Email Authentication Methods" Registry Update 6.3. "Email Authentication Methods" Registry
No changes are made to this registry. The following entry is added:
Method: dkim
Definition: [RFC7601]
ptype: header
property: a
Description: value of signature "a" tag
Status: active
Version: 1
6.4. "Email Authentication Property Types" Registry 6.4. "Email Authentication Property Types" Registry
[RFC7410] created the "Email Authentication Property Types" registry. [RFC7410] created the "Email Authentication Property Types" registry.
No changes are made to this registry. However, it should be noted No changes are made to this registry. However, it should be noted
that Section 2.3 contains slightly different language than prior that Section 2.3 contains slightly different language than prior
versions of this document, allowing a broader space from which to versions of this document, allowing a broader space from which to
extract meaningful identifiers and report them through this extract meaningful identifiers and report them through this
mechanism. mechanism.
skipping to change at page 33, line 14 skipping to change at page 34, line 6
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,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>.
[IANA-HEADERS] [IANA-HEADERS]
Klyne, G., Nottingham, M., and J. Mogul, "Registration Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, DOI 10.17487/RFC3864, September 2004,
<http://www.rfc-editor.org/info/rfc3864>. <http://www.rfc-editor.org/info/rfc3864>.
[KEYWORDS] [KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
skipping to change at page 33, line 45 skipping to change at page 34, line 42
[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>.
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,
February 2012, <https://www.rfc-editor.org/info/rfc6530>.
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email", RFC 6531, DOI 10.17487/RFC6531, February 2012,
<https://www.rfc-editor.org/info/rfc6531>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532,
February 2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC6577] Kucherawy, M., "Authentication-Results Registration Update [RFC6577] Kucherawy, M., "Authentication-Results Registration Update
for Sender Policy Framework (SPF) Results", RFC 6577, for Sender Policy Framework (SPF) Results", RFC 6577,
DOI 10.17487/RFC6577, March 2012, DOI 10.17487/RFC6577, March 2012,
<https://www.rfc-editor.org/info/rfc6577>. <https://www.rfc-editor.org/info/rfc6577>.
[RFC7001] Kucherawy, M., "Message Header Field for Indicating [RFC7001] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7001, DOI 10.17487/ Message Authentication Status", RFC 7001, DOI 10.17487/
RFC7001, September 2013, RFC7001, September 2013,
<https://www.rfc-editor.org/info/rfc7001>. <https://www.rfc-editor.org/info/rfc7001>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating [RFC7601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7601, DOI 10.17487/ Message Authentication Status", RFC 7601, DOI 10.17487/
RFC7601, August 2015, RFC7601, August 2015,
<https://www.rfc-editor.org/info/rfc7601>. <https://www.rfc-editor.org/info/rfc7601>.
[RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage
Update to DomainKeys Identified Mail (DKIM)", RFC 8301,
DOI 10.17487/RFC8301, January 2018,
<https://www.rfc-editor.org/info/rfc8301>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>. <http://www.rfc-editor.org/info/rfc5321>.
8.2. Informative References 8.2. Informative References
[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine,
"DomainKeys Identified Mail (DKIM) Author Domain Signing "DomainKeys Identified Mail (DKIM) Author Domain Signing
Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617, Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617,
August 2009, <http://www.rfc-editor.org/info/rfc5617>. August 2009, <http://www.rfc-editor.org/info/rfc5617>.
skipping to change at page 34, line 42 skipping to change at page 36, line 10
[AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service [AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
Extension for Authentication", RFC 4954, DOI 10.17487/ Extension for Authentication", RFC 4954, DOI 10.17487/
RFC4954, July 2007, RFC4954, July 2007,
<http://www.rfc-editor.org/info/rfc4954>. <http://www.rfc-editor.org/info/rfc4954>.
[AUTH-ESC] [AUTH-ESC]
Kucherawy, M., "Email Authentication Status Codes", Kucherawy, M., "Email Authentication Status Codes",
RFC 7372, DOI 10.17487/RFC7372, September 2014, RFC 7372, DOI 10.17487/RFC7372, September 2014,
<http://www.rfc-editor.org/info/rfc7372>. <http://www.rfc-editor.org/info/rfc7372>.
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>.
[DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>. <http://www.rfc-editor.org/info/rfc7489>.
[DNS] Mockapetris, P., "Domain names - implementation and [DNS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
skipping to change at page 46, line 34 skipping to change at page 47, line 34
delivery process has completed. This seriously diminishes the delivery process has completed. This seriously diminishes the
value of this work when done elsewhere than at MTAs. value of this work when done elsewhere than at MTAs.
Many operational choices are possible within an ADMD, including the Many operational choices are possible within an ADMD, including the
venue for performing authentication and/or reputation assessment. venue for performing authentication and/or reputation assessment.
The current specification does not dictate any of those choices. The current specification does not dictate any of those choices.
Rather, it facilitates those cases in which information produced by Rather, it facilitates those cases in which information produced by
one stage of analysis needs to be transported with the message to the one stage of analysis needs to be transported with the message to the
next stage. next stage.
Appendix D. Changes since RFC 7001 Appendix D. Changes Since RFC7601
o Applied RFC 7410.
o Updated all references to RFC 4408 with RFC 7208.
o Added section explaining "property" values. (Addressed Erratum
#4201.)
o Did some minor text reorganization.
o Gave registry history -- enough that this is now the authoritative
registry definition.
o Added text explaining each of the method-ptype-property tuples
registered by this document.
o Changed the meaning of the "Defined" column of the methods
registry to be the place where each entry was created and
described; it is expected that this will then refer to the
method's defining document. Provided IANA with corresponding
update instructions.
o Cleaned up registry structure and content, and replaced all
references to RFC 7001 with pointers to this document.
o Added references: [DMARC], [PRA], [RFC6008], [RFC6577], [RRVS],
[SMIME-REG].
o Added description of values that can be extracted from SMTP AUTH
sessions and an example.
o Provided much more complete descriptions of reporting DomainKeys
results.
o Added more detail about Sender ID.
o Marked all ADSP and DomainKeys entries as deprecated since their
defining documents are as well.
o Reworked some text around ignoring unknown ptypes.
o Completely described the ptypes registry.
o Mentioned that EHLO is mapped to HELO for SPF.
o RFC 7208 uses all-lowercase result strings now, so adjusted prose
accordingly.
o Updated list of supported methods, and mentioned the registries
immediately below.
o Mentioned that when a local-part is removed, the "@" goes with it.
o Referred to RFC 7328 in the "iprev" definition.
o Corrected the "smime-part" prose.
o Updated examples that use SMTP AUTH to claim "with ESMTPA" in the o Added IANA registration for DKIM "a" property.
Received fields.
o Made minor editorial adjustments. o Include EAI guidance.
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: TBD review and constructive criticism of this document: Seth Blank, John
Levine, Scott Kitterman
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. 41 change blocks. 
122 lines changed or deleted 131 lines changed or added

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