draft-ietf-dmarc-rfc7601bis-01.txt   draft-ietf-dmarc-rfc7601bis-02.txt 
DMARC Working Group M. Kucherawy DMARC Working Group M. Kucherawy
Internet-Draft March 20, 2018 Internet-Draft May 9, 2018
Obsoletes: 7601 (if approved) Obsoletes: 7601 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 21, 2018 Expires: November 10, 2018
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-dmarc-rfc7601bis-01 draft-ietf-dmarc-rfc7601bis-02
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 September 21, 2018. This Internet-Draft will expire on November 10, 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 43 skipping to change at page 2, line 43
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 . . . . . . . . . . . . . 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 . . . . . . . . . 28 6.2. "Email Authentication Methods" Registry Description . . . 28
6.3. "Email Authentication Methods" Registry . . . . . . . . . 28 6.3. "Email Authentication Methods" Registry Update . . . . . . 28
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 . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 29 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 30
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 31 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 31
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . 32
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 32 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 . . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 8.1. Normative References . . . . . . . . . . . . . . . . . . . 34
8.2. Informative References . . . . . . . . . . . . . . . . . . 35 8.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 37 Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 37
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 . . . . . . . . . . 38
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,
skipping to change at page 28, line 36 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 6.2. "Email Authentication Methods" Registry Description
No changes are made to this registry. No changes are made to the description of this registry.
6.3. "Email Authentication Methods" Registry 6.3. "Email Authentication Methods" Registry Update
The following entry is added: The following entries are added:
Method: dkim Method: dkim
Definition: [RFC7601] 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
Method: dkim
Definition: [this document]
ptype: header
property: s
Description: value of signature "s" 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 the description of this registry. However, it
that Section 2.3 contains slightly different language than prior should be noted that Section 2.3 contains slightly different language
versions of this document, allowing a broader space from which to than prior versions of this document, allowing a broader space from
extract meaningful identifiers and report them through this which to extract meaningful identifiers and report them through this
mechanism. mechanism.
6.5. "Email Authentication Result Names" Description 6.5. "Email Authentication Result Names" Description
No changes are made to this registry. No changes are made to the description of this registry.
6.6. "Email Authentication Result Names" Update 6.6. "Email Authentication Result Names" Update
No changes are made to this registry. No changes are made to entries in this registry.
7. Security Considerations 7. Security Considerations
The following security considerations apply when adding or processing The following security considerations apply when adding or processing
the Authentication-Results header field: the Authentication-Results header field:
7.1. Forged Header Fields 7.1. Forged Header Fields
An MUA or filter that accesses a mailbox whose messages are handled An MUA or filter that accesses a mailbox whose messages are handled
by a non-conformant MTA, and understands Authentication-Results by a non-conformant MTA, and understands Authentication-Results
skipping to change at page 47, line 36 skipping to change at page 47, line 36
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 RFC7601 Appendix D. Changes Since RFC7601
o Added IANA registration for DKIM "a" property. o Added IANA registration for DKIM "a" and "s" properties.
o Include EAI guidance. 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: Seth Blank, John review and constructive criticism of this document: Seth Blank, John
Levine, Scott Kitterman Levine, Scott Kitterman
Author's Address Author's Address
 End of changes. 19 change blocks. 
23 lines changed or deleted 37 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/