draft-ietf-appsawg-rfc7001bis-05.txt   draft-ietf-appsawg-rfc7001bis-06.txt 
Individual submission M. Kucherawy Individual submission M. Kucherawy
Internet-Draft March 26, 2015 Internet-Draft April 19, 2015
Obsoletes: 7001, 7410 Obsoletes: 7001, 7410
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 27, 2015 Expires: October 21, 2015
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-appsawg-rfc7001bis-05 draft-ietf-appsawg-rfc7001bis-06
Abstract Abstract
This document specifies a message header field called Authentication- This document specifies a message header field called Authentication-
Results for use with electronic mail messages to indicate the results Results for use with electronic mail messages to indicate the results
of message authentication efforts. Any receiver-side software, such of message authentication efforts. Any receiver-side software, such
as mail filters or Mail User Agents (MUAs), can use this header field as mail filters or Mail User Agents (MUAs), can use this header field
to relay that information in a convenient and meaningful way to users to relay that information in a convenient and meaningful way to users
or to make sorting and filtering decisions. or to make sorting and filtering decisions.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 27, 2015. This Internet-Draft will expire on October 21, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 6 1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 6
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7 1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7
1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 7 1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 7 1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 8
1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 8 1.5.4. 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 . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . 17
2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 18 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19
2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . 21 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 22
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22
4. Adding the Header Field to a Message . . . . . . . . . . . . . 23 4. Adding the Header Field to a Message . . . . . . . . . . . . . 23
4.1. Header Field Position and Interpretation . . . . . . . . . 24 4.1. Header Field Position and Interpretation . . . . . . . . . 25
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 25 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 26
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.1. The Authentication-Results Header Field . . . . . . . . . 27 6.1. The Authentication-Results Header Field . . . . . . . . . 27
6.2. "Email Authentication Methods" Registry Description . . . 27 6.2. "Email Authentication Methods" Registry Description . . . 28
6.3. "Email Authentication Methods" Registry Update . . . . . . 28 6.3. "Email Authentication Methods" Registry Update . . . . . . 29
6.4. "Email Authentication Property Types" Registry . . . . . . 30 6.4. "Email Authentication Property Types" Registry . . . . . . 30
6.5. "Email Authentication Result Names" Description . . . . . 30 6.5. "Email Authentication Result Names" Description . . . . . 31
6.6. "Email Authentication Result Names" Update . . . . . . . . 31 6.6. "Email Authentication Result Names" Update . . . . . . . . 31
6.7. SMTP Enhanced Stauts Codes . . . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 32 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 32
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 34 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 34
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 34 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 34
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 34 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 35
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 34 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 35
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 34 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 35
7.7. Attacks against Authentication Methods . . . . . . . . . . 35 7.7. Attacks against Authentication Methods . . . . . . . . . . 35
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 35 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 35
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 35 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 36
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 35 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 36
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 36 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Normative References . . . . . . . . . . . . . . . . . . . 36 8.1. Normative References . . . . . . . . . . . . . . . . . . . 36
8.2. Informative References . . . . . . . . . . . . . . . . . . 36 8.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 39 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 39
Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 39 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 39
Appendix C. Authentication-Results Examples . . . . . . . . . . . 39 Appendix C. Authentication-Results Examples . . . . . . . . . . . 40
C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 40 C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 40
C.2. Nearly Trivial Case; Service Provided, but No C.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 40 Authentication Done . . . . . . . . . . . . . . . . . . . 41
C.3. Service Provided, Authentication Done . . . . . . . . . . 41 C.3. Service Provided, Authentication Done . . . . . . . . . . 42
C.4. Service Provided, Several Authentications Done, Single C.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.5. Service Provided, Several Authentications Done, C.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 43 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 44
C.6. Service Provided, Multi-Tiered Authentication Done . . . . 45 C.6. Service Provided, Multi-Tiered Authentication Done . . . . 46
C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 46 C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 47
Appendix D. Operational Considerations about Message Appendix D. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 47 Authentication . . . . . . . . . . . . . . . . . . . 48
Appendix E. Change History . . . . . . . . . . . . . . . . . . . 48 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 49
E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 48 E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 49
E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 49 E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 49 E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 49 E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.5. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 49 E.5. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.6. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 50 E.6. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 51
E.7. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
This document describes a header field called Authentication-Results This document describes a header field called Authentication-Results
for electronic mail messages that presents the results of a message for electronic mail messages that presents the results of a message
authentication effort in a machine-readable format. The intent of authentication effort in a machine-readable format. The intent of
the header field is to create a place to collect such data when the header field is to create a place to collect such data when
message authentication mechanisms are in use so that a Mail User message authentication mechanisms are in use so that a Mail User
Agent (MUA) and downstream filters can make filtering decisions Agent (MUA) and downstream filters can make filtering decisions
and/or provide a recommendation to the user as to the validity of the and/or provide a recommendation to the user as to the validity of the
skipping to change at page 4, line 34 skipping to change at page 4, line 34
that will then use such data or render it in a human-usable form. that will then use such data or render it in a human-usable form.
This document specifies the format of this header field and discusses This document specifies the format of this header field and discusses
the implications of its presence or absence. However, it does not the implications of its presence or absence. However, it does not
discuss how the data contained in the header field ought to be used, discuss how the data contained in the header field ought to be used,
such as what filtering decisions are appropriate or how an MUA might such as what filtering decisions are appropriate or how an MUA might
render those results, as these are local policy and/or user interface render those results, as these are local policy and/or user interface
design questions that are not appropriate for this document. design questions that are not appropriate for this document.
At the time of publication of this document, the following are At the time of publication of this document, the following are
published, domain-level email authentication methods in common use: published email authentication methods:
o Author Domain Signing Practices ([ADSP]) o Author Domain Signing Practices ([ADSP]) (Historic)
o SMTP Service Extension for Authentication ([AUTH]) o SMTP Service Extension for Authentication ([AUTH])
o DomainKeys Identified Mail Signatures ([DKIM]) o DomainKeys Identified Mail Signatures ([DKIM])
o Sender Policy Framework ([SPF]) o Domain-based Message Authentication, Reporting and Conformance
([DMARC])
o Vouch By Reference ([VBR]) o Sender Policy Framework ([SPF])
o reverse IP address name validation ("iprev", defined in Section 3) o reverse IP address name validation ("iprev", defined in Section 3)
In addition, the following are non-standard methods recognized by o Require-Recipient-Valid-Since Header Field and SMTP Service
this specification that are no longer common: Extension ([RRVS])
o S/MIME Signature Verification ([SMIME-REG])
o Vouch By Reference ([VBR])
o DomainKeys ([DOMAINKEYS]) (Historic) o DomainKeys ([DOMAINKEYS]) (Historic)
o Sender ID ([SENDERID]) (Experimental) o Sender ID ([SENDERID]) (Experimental)
There exist registries for tokens used within this header field that
refer to the specifications listed above. Section 6 describes the
registries and their contents, and specifies the process by which
entries are added or updated. It also updates the existing contents
to match the current states of these specifications.
This specification is not intended to be restricted to domain-based This specification is not intended to be restricted to domain-based
authentication schemes, but the existing schemes in that family have authentication schemes, but the existing schemes in that family have
proven to be a good starting point for implementations. The goal is proven to be a good starting point for implementations. The goal is
to give current and future authentication schemes a common framework to give current and future authentication schemes a common framework
within which to deliver their results to downstream agents and within which to deliver their results to downstream agents and
discourage the creation of unique header fields for each. discourage the creation of unique header fields for each.
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
skipping to change at page 12, line 48 skipping to change at page 13, line 13
Legal values of "ptype" are as defined in the IANA "Email Legal values of "ptype" are as defined in the IANA "Email
Authentication Property Types" registry, created by Authentication Property Types" registry, created by
[PTYPES-REGISTRY]. The initial values and what they typically [PTYPES-REGISTRY]. The initial values and what they typically
indicate are as follows, copied from [RFC7001]: indicate are as follows, copied from [RFC7001]:
body: Information that was extracted from the body of the message. body: Information that was extracted from the body of the message.
This might be an arbitrary string of bytes, a hash of a string of This might be an arbitrary string of bytes, a hash of a string of
bytes, a Uniform Resource Identifier, or some other content of bytes, a Uniform Resource Identifier, or some other content of
interest. The "property" is an indication of where within the interest. The "property" is an indication of where within the
message body the extracted content was found, and can indicate an message body the extracted content was found, and can indicate an
offset, identify a MIME part, or offset, identify a MIME part, etc.
header: Indicates information that was extracted from the header of header: Indicates information that was extracted from the header of
the message. This might be the value of a header field or some the message. This might be the value of a header field or some
portion of a header field. The "property" gives a more precise portion of a header field. The "property" gives a more precise
indication of the place in the header from which the extraction indication of the place in the header from which the extraction
took place. took place.
policy: A local policy mechanism was applied that augments or policy: A local policy mechanism was applied that augments or
overrides the result returned by the authentication mechanism. overrides the result returned by the authentication mechanism.
(See Section 2.4.) (See Section 2.4.)
skipping to change at page 17, line 25 skipping to change at page 17, line 38
will be treated as if it had not been signed. will be treated as if it had not been signed.
Section 3.1 of [DOMAINKEYS] describes a process by which the sending Section 3.1 of [DOMAINKEYS] describes a process by which the sending
address of the message is determined. DomainKeys results are thus address of the message is determined. DomainKeys results are thus
reported along with the signing domain name, the sending address of reported along with the signing domain name, the sending address of
the message, and the name of the header field from which the latter the message, and the name of the header field from which the latter
was extracted. This means that a DomainKeys result includes a ptype- was extracted. This means that a DomainKeys result includes a ptype-
property combination of "header.d", plus one of "header.from" and property combination of "header.d", plus one of "header.from" and
"header.sender". The sending address extracted from the header is "header.sender". The sending address extracted from the header is
included with any [MAIL]-style comments removed; moreover, the local- included with any [MAIL]-style comments removed; moreover, the local-
part of the address is removed if it has not been authenticated in part of the address and the "@" character are removed if it has not
some way. been authenticated in some way.
2.7.2. SPF and Sender ID 2.7.2. SPF and Sender ID
SPF and Sender ID use the "spf" and "sender-id" method names, SPF and Sender ID use the "spf" and "sender-id" method names,
respectively. The result values for SPF are defined in Section 2.6 respectively. The result values for SPF are defined in Section 2.6
of [SPF], and those definitions are included here by reference: of [SPF], and those definitions are included here by reference:
+-----------+--------------------------------+ +-----------+--------------------------------+
| Code | Meaning | | Code | Meaning |
+-----------+--------------------------------+ +-----------+--------------------------------+
skipping to change at page 18, line 39 skipping to change at page 19, line 9
the sender's DNS domain according to the authentication method's the sender's DNS domain according to the authentication method's
algorithm, but local policy dictates that the result is unacceptable. algorithm, but local policy dictates that the result is unacceptable.
For example, "policy" might be used if SPF returns a "pass" result, For example, "policy" might be used if SPF returns a "pass" result,
but a local policy check matches the sending DNS domain to one found but a local policy check matches the sending DNS domain to one found
in an explicit list of unacceptable DNS domains (e.g., spammers). in an explicit list of unacceptable DNS domains (e.g., spammers).
If the retrieved sender policies used to evaluate SPF and Sender ID If the retrieved sender policies used to evaluate SPF and Sender ID
do not contain explicit provisions for authenticating the local-part do not contain explicit provisions for authenticating the local-part
(see Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported (see Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported
along with results for these mechanisms SHOULD NOT include the local- along with results for these mechanisms SHOULD NOT include the local-
part. part or the following "@" character.
2.7.3. "iprev" 2.7.3. "iprev"
The result values used by the "iprev" method, defined in Section 3, The result values used by the "iprev" method, defined in Section 3,
are as follows: are as follows:
pass: The DNS evaluation succeeded, i.e., the "reverse" and pass: The DNS evaluation succeeded, i.e., the "reverse" and
"forward" lookup results were returned and were in agreement. "forward" lookup results were returned and were in agreement.
fail: The DNS evaluation failed. In particular, the "reverse" and fail: The DNS evaluation failed. In particular, the "reverse" and
skipping to change at page 22, line 37 skipping to change at page 22, line 50
query) thus retrieved is done. The response to this second check query) thus retrieved is done. The response to this second check
will typically result in at least one mapping back to the client's IP will typically result in at least one mapping back to the client's IP
address. address.
Expressed as an algorithm: If the client peer's IP address is I, the Expressed as an algorithm: If the client peer's IP address is I, the
list of names to which I maps (after a "PTR" query) is the set N, and list of names to which I maps (after a "PTR" query) is the set N, and
the union of IP addresses to which each member of N maps (after the union of IP addresses to which each member of N maps (after
corresponding "A" and "AAAA" queries) is L, then this test is corresponding "A" and "AAAA" queries) is L, then this test is
successful if I is an element of L. successful if I is an element of L.
Often an MTA receiving a connection that fails this test will simply
reject the connection using the enhanced status code defined in
[AUTH-ESC]. If an operator instead wishes to make this information
available to downstream agents as a factor in handling decisions, it
records a result in accordance with Section 2.7.3.
The response to a PTR query could contain multiple names. To prevent The response to a PTR query could contain multiple names. To prevent
heavy DNS loads, agents performing these queries MUST be implemented heavy DNS loads, agents performing these queries MUST be implemented
such that the number of names evaluated by generation of such that the number of names evaluated by generation of
corresponding A or AAAA queries is limited so as not to be unduly corresponding A or AAAA queries is limited so as not to be unduly
taxing to the DNS infrastructure, though it MAY be configurable by an taxing to the DNS infrastructure, though it MAY be configurable by an
administrator. As an example, Section 4.6.4 of [SPF] chose a limit administrator. As an example, Section 4.6.4 of [SPF] chose a limit
of 10 for its implementation of this algorithm. of 10 for its implementation of this algorithm.
"DNS Extensions to Support IP Version 6" ([DNS-IP6]) discusses the "DNS Extensions to Support IP Version 6" ([DNS-IP6]) discusses the
query formats for the IPv6 case. query formats for the IPv6 case.
skipping to change at page 29, line 21 skipping to change at page 29, line 42
reference shall be removed from the description. reference shall be removed from the description.
3. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf" 3. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf"
method entries shall have their "Defined" fields changed to this method entries shall have their "Defined" fields changed to this
document. document.
4. All "smime" entries have their "Defined" fields changed to 4. All "smime" entries have their "Defined" fields changed to
[SMIME-REG]. [SMIME-REG].
5. The "value" field of the "smime" entry using property "smime- 5. The "value" field of the "smime" entry using property "smime-
part" shall be changed to read "A reference to the MIME body part part" shall be changed to read "The MIME body part reference that
that contains the signature." The redundant reference is thus contains the S/MIME signature." The redundant reference is thus
removed. removed.
6. The following entry is to be added: 6. The following entry is to be added:
Method: auth Method: auth
Defined: [this document] Defined: [this document]
ptype: smtp ptype: smtp
property: auth property: auth
Value: identity confirmed by the AUTH command Value: identity confirmed by the AUTH command
Status: active Status: active
skipping to change at page 29, line 45 skipping to change at page 30, line 20
Value: identity confirmed by the AUTH command Value: identity confirmed by the AUTH command
Status: active Status: active
Version: 1 Version: 1
7. The values of the "domainkeys" entries for ptype "header" are 7. The values of the "domainkeys" entries for ptype "header" are
updated as follows: updated as follows:
from: contents of the [MAIL] From: header field, after removing from: contents of the [MAIL] From: header field, after removing
comments, and removing the local-part if not authenticated comments, and removing the local-part and following "@" if not
authenticated
sender: contents of the [MAIL] Sender: header field, after sender: contents of the [MAIL] Sender: header field, after
removing comments, and removing the local-part if not removing comments, and removing the local-part and following
authenticated "@" if not authenticated
8. All entries for "dkim-adsp" and "domainkeys" shall have their 8. All entries for "dkim-adsp" and "domainkeys" shall have their
Status values changed to "deprecated", reflecting the fact that Status values changed to "deprecated", reflecting the fact that
the corresponding specifications now have Historical status. the corresponding specifications now have Historical status.
6.4. "Email Authentication Property Types" Registry 6.4. "Email Authentication Property Types" Registry
[PTYPES-REGISTRY] created the Email Authentication Property Types [PTYPES-REGISTRY] created the Email Authentication Property Types
registry. registry.
skipping to change at page 32, line 9 skipping to change at page 32, line 35
iprev: [this document] Section 2.7.3 iprev: [this document] Section 2.7.3
o All entries for "dkim-adsp" that are missing an explicit reference o All entries for "dkim-adsp" that are missing an explicit reference
to a defining document shall have [ADSP] added to their to a defining document shall have [ADSP] added to their
Specification fields. Specification fields.
o All entries for "dkim-adsp" and "domainkeys" shall have their o All entries for "dkim-adsp" and "domainkeys" shall have their
Status values changed to "deprecated", reflecting the fact that Status values changed to "deprecated", reflecting the fact that
the corresponding specifications now have Historical status. the corresponding specifications now have Historical status.
6.7. SMTP Enhanced Stauts Codes
The entry for X.7.25 in the Enumerated Status Codes sub-registry of
the SMTP Enhanced Status Codes registry is to be updated to refer to
this document.
7. Security Considerations 7. Security Considerations
The following security considerations apply when adding or processing The following security considerations apply when adding or processing
the Authentication-Results header field: the Authentication-Results header field:
7.1. Forged Header Fields 7.1. Forged Header Fields
An MUA or filter that accesses a mailbox whose messages are handled An MUA or filter that accesses a mailbox whose messages are handled
by a non-conformant MTA, and understands Authentication-Results by a non-conformant MTA, and understands Authentication-Results
header fields, could potentially make false conclusions based on header fields, could potentially make false conclusions based on
skipping to change at page 37, line 15 skipping to change at page 37, line 44
RFC 6212, April 2011. RFC 6212, April 2011.
[ATPS] Kucherawy, M., "DomainKeys Identified Mail [ATPS] Kucherawy, M., "DomainKeys Identified Mail
(DKIM) Authorized Third-Party Signatures", (DKIM) Authorized Third-Party Signatures",
RFC 6541, February 2012. RFC 6541, February 2012.
[AUTH] Siemborski, R. and A. Melnikov, "SMTP Service [AUTH] Siemborski, R. and A. Melnikov, "SMTP Service
Extension for Authentication", RFC 4954, Extension for Authentication", RFC 4954,
July 2007. July 2007.
[AUTH-ESC] Kucherawy, M., "Email Authentication Status
Codes", RFC 7372, September 2014.
[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, [DKIM] Crocker, D., Hansen, T., and M. Kucherawy,
"DomainKeys Identified Mail (DKIM) "DomainKeys Identified Mail (DKIM)
Signatures", STD 76, RFC 6376, September 2011. Signatures", STD 76, RFC 6376, September 2011.
[DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed.,
"Domain-based Message Authentication, "Domain-based Message Authentication,
Reporting and Conformance (DMARC)", RFC 7489, Reporting and Conformance (DMARC)", RFC 7489,
March 2015. March 2015.
[DNS] Mockapetris, P., "Domain names - [DNS] Mockapetris, P., "Domain names -
skipping to change at page 42, line 19 skipping to change at page 43, line 19
checks: checks:
Authentication-Results: example.com; Authentication-Results: example.com;
auth=pass (cram-md5) smtp.auth=sender@example.net; auth=pass (cram-md5) smtp.auth=sender@example.net;
spf=pass smtp.mailfrom=example.net spf=pass smtp.mailfrom=example.net
Authentication-Results: example.com; Authentication-Results: example.com;
sender-id=pass header.from=example.net sender-id=pass header.from=example.net
Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6) Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6)
(dialup-1-2-3-4.example.net [192.0.2.200]) (dialup-1-2-3-4.example.net [192.0.2.200])
by mail-router.example.com (8.11.6/8.11.6) by mail-router.example.com (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489; with ESMTPA id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800 Fri, Feb 15 2002 17:19:07 -0800
Date: Fri, Feb 15 2002 16:54:30 -0800 Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com To: receiver@example.com
From: sender@example.net From: sender@example.net
Message-Id: <12345.abc@example.net> Message-Id: <12345.abc@example.net>
Subject: here's a sample Subject: here's a sample
Hello! Goodbye! Hello! Goodbye!
Example 4: Headers Reporting Results from One MTA Example 4: Headers Reporting Results from One MTA
skipping to change at page 43, line 30 skipping to change at page 44, line 30
t=1188964191; c=simple/simple; h=From:Date:To:Subject: t=1188964191; c=simple/simple; h=From:Date:To:Subject:
Message-Id:Authentication-Results; Message-Id:Authentication-Results;
bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
Authentication-Results: example.com; Authentication-Results: example.com;
auth=pass (cram-md5) smtp.auth=sender@example.com; auth=pass (cram-md5) smtp.auth=sender@example.com;
spf=fail smtp.mailfrom=example.com spf=fail smtp.mailfrom=example.com
Received: from dialup-1-2-3-4.example.net Received: from dialup-1-2-3-4.example.net
(dialup-1-2-3-4.example.net [192.0.2.200]) (dialup-1-2-3-4.example.net [192.0.2.200])
by mail-router.example.com (8.11.6/8.11.6) by mail-router.example.com (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489; with ESMTPA id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800 Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.com From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800 Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com To: receiver@example.com
Message-Id: <12345.abc@example.com> Message-Id: <12345.abc@example.com>
Subject: here's a sample Subject: here's a sample
Hello! Goodbye! Hello! Goodbye!
Example 5: Headers Reporting Results from Multiple MTAs Example 5: Headers Reporting Results from Multiple MTAs
skipping to change at page 50, line 30 skipping to change at page 51, line 30
o Completely describe the ptypes registry. o Completely describe the ptypes registry.
o EHLO is mapped to HELO for SPF. o EHLO is mapped to HELO for SPF.
o RFC7208 uses all-lowercase result strings now, so adjust prose o RFC7208 uses all-lowercase result strings now, so adjust prose
accordingly. accordingly.
o Move the RFC6008 reference up to where the DKIM reporting is o Move the RFC6008 reference up to where the DKIM reporting is
described. described.
E.7. -05 to -06
WGLC feedback:
o Update list of supported methods, and mention the registries
immediately below there.
o Mention that when a local-part is removed, the "@" goes with it.
o Refer to RFC7328 in the "iprev" definition.
o Correction to "smime-part" prose.
o Examples that use SMTP AUTH now claim "with ESMTPA" in the
Received fields.
Author's Address Author's Address
Murray S. Kucherawy Murray S. Kucherawy
270 Upland Drive 270 Upland Drive
San Francisco, CA 94127 San Francisco, CA 94127
US US
EMail: superuser@gmail.com EMail: superuser@gmail.com
 End of changes. 43 change blocks. 
57 lines changed or deleted 102 lines changed or added

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