draft-ietf-appsawg-rfc7001bis-08.txt   draft-ietf-appsawg-rfc7001bis-09.txt 
Individual submission M. Kucherawy Individual submission M. Kucherawy
Internet-Draft May 5, 2015 Internet-Draft May 11, 2015
Obsoletes: 7001, 7410 Obsoletes: 7001, 7410
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: November 6, 2015 Expires: November 12, 2015
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-appsawg-rfc7001bis-08 draft-ietf-appsawg-rfc7001bis-09
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 November 6, 2015. This Internet-Draft will expire on November 12, 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
skipping to change at page 2, line 48 skipping to change at page 2, line 48
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 . . . . . . . . . . . . . . . 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 . . . 28 6.2. "Email Authentication Methods" Registry Description . . . 28
6.3. "Email Authentication Methods" Registry Update . . . . . . 29 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 . . . . . 31 6.5. "Email Authentication Result Names" Description . . . . . 31
6.6. "Email Authentication Result Names" Update . . . . . . . . 32 6.6. "Email Authentication Result Names" Update . . . . . . . . 32
6.7. SMTP Enhanced Stauts Codes . . . . . . . . . . . . . . . . 33 6.7. SMTP Enhanced Status Codes . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 33 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 33
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 35 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 35
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 35 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 35
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 35 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 35
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 35 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 35
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 35 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 35
7.7. Attacks against Authentication Methods . . . . . . . . . . 36 7.7. Attacks against Authentication Methods . . . . . . . . . . 36
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 36 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 36
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 36 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 36
skipping to change at page 3, line 31 skipping to change at page 3, line 31
Authentication Done . . . . . . . . . . . . . . . . . . . 41 Authentication Done . . . . . . . . . . . . . . . . . . . 41
C.3. Service Provided, Authentication Done . . . . . . . . . . 42 C.3. Service Provided, Authentication Done . . . . . . . . . . 42
C.4. Service Provided, Several Authentications Done, Single C.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.5. Service Provided, Several Authentications Done, C.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 44 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 44
C.6. Service Provided, Multi-Tiered Authentication Done . . . . 46 C.6. Service Provided, Multi-Tiered Authentication Done . . . . 46
C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 47 C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 47
Appendix D. Operational Considerations about Message Appendix D. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 48 Authentication . . . . . . . . . . . . . . . . . . . 48
Appendix E. Change History . . . . . . . . . . . . . . . . . . . 49 Appendix E. Change Since RFC7001 . . . . . . . . . . . . . . . . 49
E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 49
E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.5. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.6. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 51
E.7. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 51
E.8. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 51
E.9. -07 to -08 . . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This document describes a header field called Authentication-Results This document describes a header field called Authentication-Results
for electronic mail messages that presents the results of a message for electronic mail messages that presents the results of a message
authentication effort in a machine-readable format. The intent of authentication effort in a machine-readable format. The intent of
the header field is to create a place to collect such data when the header field is to create a place to collect such data when
message authentication mechanisms are in use so that a Mail User message authentication mechanisms are in use so that a Mail User
Agent (MUA) and downstream filters can make filtering decisions Agent (MUA) and downstream filters can make filtering decisions
and/or provide a recommendation to the user as to the validity of the and/or provide a recommendation to the user as to the validity of the
skipping to change at page 33, line 5 skipping to change at page 33, line 5
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.
Their "Specification" fields shall also be modified to include a Their "Specification" fields shall also be modified to include a
reference to this document. reference to this document.
6.7. SMTP Enhanced Stauts Codes 6.7. SMTP Enhanced Status Codes
The entry for X.7.25 in the Enumerated Status Codes sub-registry of The entry for X.7.25 in the Enumerated Status Codes sub-registry of
the SMTP Enhanced Status Codes registry is to be updated to refer to the SMTP Enhanced Status Codes registry is to be updated to refer to
this document instead of [RFC7001]. this document instead of [RFC7001].
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:
skipping to change at page 49, line 37 skipping to change at page 49, line 37
delivery process has completed. This seriously diminishes the delivery process has completed. This seriously diminishes the
value of this work when done other than at MTAs. value of this work when done other 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 E. Change History Appendix E. Change Since RFC7001
E.1. RFC7001 to -00
o Remove "Changes since RFC5451" section; add this "Change History"
section.
o Restore XML to previous format. (No visible changes).
o Reset "Acknowledgments".
o Add "To-Do" section.
E.2. -00 to -01
o Apply RFC7410. o Apply RFC7410.
o Update all the RFC4408 references to RFC7208. o Update all the RFC4408 references to RFC7208.
o Add section explaining "property" values. (Errata #4201) o Add section explaining "property" values. (Errata #4201)
o Remove "To-Do" section. o Some minor text reorganization.
E.3. -01 to -02
o Consolidate new sections.
E.4. -02 to -03
o Move the DKIM exception text down to where the DKIM results are
defined, and add a forward reference to them.
o More detail about registry creation and previous augmentations. o Give registry history, enough that this is now the authoritative
registry definition.
o Add text explaining each of the method-ptype-property tuples o Add text explaining each of the method-ptype-property tuples
registered by this document. registered by this document.
o Change the meaning of the "Defined" column of the methods registry o Change the meaning of the "Defined" column of the methods registry
to be the place where each entry was created and described; it is to be the place where each entry was created and described; it is
expected that this will then refer to the method's defining expected that this will then refer to the method's defining
document. Provide IANA with corresponding update instructions. document. Provide IANA with corresponding update instructions.
o Add references: [DMARC], [PRA], [RFC6577], [RRVS], [SMIME-REG]. o Clean up registry structure and content, and replace all RFC7001
references with pointers to this document.
E.5. -03 to -04
o Add specific update instructions for the "dkim"/"header"/"b" entry o Add references: [DMARC], [PRA], [RFC6008], [RFC6577], [RRVS],
in IANA Considerations. [SMIME-REG].
o Add description of values that can be extracted from SMTP AUTH o Add description of values that can be extracted from SMTP AUTH
sessions and an example. sessions and an example.
o Much more complete descriptions of reporting DomainKeys results. o Much more complete descriptions of reporting DomainKeys results.
o Minor editorial adjustments.
o Fix up "smime" entries.
o Update current definitions for the Email Authentication Property
Types registry to point to this document.
o Rework the Email Authentication Result Names registry.
o Add more detail about Sender ID. o Add more detail about Sender ID.
o Mark all ADSP and DomainKeys entries as deprecated since their o Mark all ADSP and DomainKeys entries as deprecated since their
defining documents are as well. defining documents are as well.
o Add references: [RFC6008].
E.6. -04 to -05
o Fix typos.
o Rework some text around ignoring unknown ptypes. o Rework some text around ignoring unknown ptypes.
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
described.
E.7. -05 to -06
WGLC feedback:
o Update list of supported methods, and mention the registries o Update list of supported methods, and mention the registries
immediately below there. immediately below there.
o Mention that when a local-part is removed, the "@" goes with it. o Mention that when a local-part is removed, the "@" goes with it.
o Refer to RFC7328 in the "iprev" definition. o Refer to RFC7328 in the "iprev" definition.
o Correction to "smime-part" prose. o Correction to "smime-part" prose.
o Examples that use SMTP AUTH now claim "with ESMTPA" in the o Examples that use SMTP AUTH now claim "with ESMTPA" in the
Received fields. Received fields.
E.8. -06 to -07 o Minor editorial adjustments.
o Wording around the S/MIME results.
E.9. -07 to -08
o Clarifications in IANA Considerations.
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. 16 change blocks. 
75 lines changed or deleted 16 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/