draft-ietf-appsawg-rfc7001bis-04.txt   draft-ietf-appsawg-rfc7001bis-05.txt 
Individual submission M. Kucherawy Individual submission M. Kucherawy
Internet-Draft March 23, 2015 Internet-Draft March 26, 2015
Obsoletes: 7001, 7410 Obsoletes: 7001, 7410
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 24, 2015 Expires: September 27, 2015
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-appsawg-rfc7001bis-04 draft-ietf-appsawg-rfc7001bis-05
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 24, 2015. This Internet-Draft will expire on September 27, 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 47 skipping to change at page 2, line 47
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 . . . . . . . . . 24
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 25 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 25
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 . . . 27
6.3. "Email Authentication Methods" Registry Update . . . . . . 28 6.3. "Email Authentication Methods" Registry Update . . . . . . 28
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 . . . . . 30
6.6. "Email Authentication Result Names" Update . . . . . . . . 30 6.6. "Email Authentication Result Names" Update . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 31 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 32
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 33 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 34
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 33 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 . . . . . . . . 34
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 34 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 34
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 34 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 34
7.7. Attacks against Authentication Methods . . . . . . . . . . 34 7.7. Attacks against Authentication Methods . . . . . . . . . . 35
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 34 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 35
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 35 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 35
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 35 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 35
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 35 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Normative References . . . . . . . . . . . . . . . . . . . 35 8.1. Normative References . . . . . . . . . . . . . . . . . . . 36
8.2. Informative References . . . . . . . . . . . . . . . . . . 36 8.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 39
Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 38 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 39
Appendix C. Authentication-Results Examples . . . . . . . . . . . 39 Appendix C. Authentication-Results Examples . . . . . . . . . . . 39
C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 39 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 . . . . . . . . . . . . . . . . . . . 40
C.3. Service Provided, Authentication Done . . . . . . . . . . 41 C.3. Service Provided, Authentication Done . . . . . . . . . . 41
C.4. Service Provided, Several Authentications Done, Single C.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
C.5. Service Provided, Several Authentications Done, C.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 43 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 43
C.6. Service Provided, Multi-Tiered Authentication Done . . . . 45 C.6. Service Provided, Multi-Tiered Authentication Done . . . . 45
C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 46 C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 46
Appendix D. Operational Considerations about Message Appendix D. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 47 Authentication . . . . . . . . . . . . . . . . . . . 47
Appendix E. Change History . . . . . . . . . . . . . . . . . . . 48 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 48
E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 48 E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 48
E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 49 E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 49
E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 49 E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 49
E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 49 E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 49
E.5. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 49 E.5. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 49
E.6. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 50
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 12, line 30 skipping to change at page 12, line 30
extracted. See Section 2.4 for details. extracted. See Section 2.4 for details.
Examples of complete messages using this header field can be found in Examples of complete messages using this header field can be found in
Appendix C. Appendix C.
2.3. Property Types (ptypes) and Properties 2.3. Property Types (ptypes) and Properties
The "ptype" in the ABNF above indicates the general type of property The "ptype" in the ABNF above indicates the general type of property
being described by the result being reported, upon which the reported being described by the result being reported, upon which the reported
result was based. Coupled with the "property", which is more result was based. Coupled with the "property", which is more
specific, they inidcate from which particular part of the message the specific, they indicate from which particular part of the message the
reported data were extracted. reported data were extracted.
Combinations of ptypes and properties are registered and described in Combinations of ptypes and properties are registered and described in
the "Email Authentication Methods" registry, coupled with the the "Email Authentication Methods" registry, coupled with the
authentication methods with which they are used. This is further authentication methods with which they are used. This is further
described in Section 6. described in Section 6.
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
skipping to change at page 13, line 19 skipping to change at page 13, line 19
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.)
smtp: Indicates information that was extracted from an SMTP command smtp: Indicates information that was extracted from an SMTP command
that was used to relay the message. The "property" indicates that was used to relay the message. The "property" indicates
which SMTP command included the extracted content as a parameter. which SMTP command included the extracted content as a parameter.
When a consumer of this header field encounters a "ptype" that it Results reported using unknown ptypes MUST NOT be used in making
does not understand, it ignores the result reported with that handling decisions. They can be safely ignored by consumers.
"ptype".
Entries in the "Email Authentication Methods" registry can define Entries in the "Email Authentication Methods" registry can define
properties that deviate from these definitions when appropriate. properties that deviate from these definitions when appropriate.
Such deviations need to be clear in the registry and/or in the Such deviations need to be clear in the registry and/or in the
defining document. See Section 2.7.1 for an example. defining document. See Section 2.7.1 for an example.
2.4. The "policy" ptype 2.4. The "policy" ptype
A special ptype value of "policy" is also defined. This ptype is A special ptype value of "policy" is also defined. This ptype is
provided to indicate that some local policy mechanism was applied provided to indicate that some local policy mechanism was applied
skipping to change at page 17, line 8 skipping to change at page 17, line 8
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".
The ability to report different DKIM results for a multiply-signed
message 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
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
skipping to change at page 18, line 7 skipping to change at page 18, line 10
+-----------+--------------------------------+ +-----------+--------------------------------+
| temperror | [RFC7208], Section 2.6.6 | | temperror | [RFC7208], Section 2.6.6 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| permerror | [RFC7208], Section 2.6.7 | | permerror | [RFC7208], Section 2.6.7 |
+-----------+--------------------------------+ +-----------+--------------------------------+
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 any of For SPF, the ptype used is "smtp", and the property is either
"mailfrom", "helo", and "ehlo", since those values are the ones SPF "mailfrom" or "helo", since those values are the ones SPF can
can evaluate. evaluate. (If the SMTP client issued the EHLO command instead of
HELO, the property used is "helo".)
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. definitions enumerated above are used instead. Also, [SENDERID]
specifies result codes that use mixed case, but they are typically
Note that both of those documents specify result codes that use mixed used all lowercase in this context.
case, but they are typically used all lowercase in this context.
For both methods, an additional result of "policy" is defined, which For both methods, an additional result of "policy" is defined, which
means the client was authorized to inject or relay mail on behalf of means the client was authorized to inject or relay mail on behalf of
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
skipping to change at page 20, line 46 skipping to change at page 21, line 9
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").
o The ability to report different DKIM results for a multiply-signed
message (in [RFC6008]).
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 23, line 13 skipping to change at page 23, line 17
of the validity of the connection's identity using DNS. It is of the validity of the connection's identity using DNS. It is
incumbent upon an agent making use of the reported "iprev" result to incumbent upon an agent making use of the reported "iprev" result to
understand what exactly that particular verifier is attempting to understand what exactly that particular verifier is attempting to
report. report.
Extensive discussion of reverse DNS mapping and its implications can Extensive discussion of reverse DNS mapping and its implications can
be found in "Considerations for the use of DNS Reverse Mapping" be found in "Considerations for the use of DNS Reverse Mapping"
([DNSOP-REVERSE]). In particular, it recommends that applications ([DNSOP-REVERSE]). In particular, it recommends that applications
avoid using this test as a means of authentication or security. Its avoid using this test as a means of authentication or security. Its
presence in this document is not an endorsement but is merely presence in this document is not an endorsement but is merely
acknowledgement that the method remains common and provides the means acknowledgment that the method remains common and provides the means
to relay the results of that test. to relay the results of that test.
4. Adding the Header Field to a Message 4. Adding the Header Field to a Message
This specification makes no attempt to evaluate the relative This specification makes no attempt to evaluate the relative
strengths of various message authentication methods that may become strengths of various message authentication methods that may become
available. The methods listed are an order-independent set; their available. The methods listed are an order-independent set; their
sequence does not indicate relative strength or importance of one sequence does not indicate relative strength or importance of one
method over another. Instead, the MUA or downstream filter consuming method over another. Instead, the MUA or downstream filter consuming
this header field is to interpret the result of each method based on this header field is to interpret the result of each method based on
skipping to change at page 27, line 12 skipping to change at page 27, line 15
An MTA SHOULD remove any instance of this header field bearing a An MTA SHOULD remove any instance of this header field bearing a
version (express or implied) that it does not support. However, an version (express or implied) that it does not support. However, an
MTA MUST remove such a header field if the [SMTP] connection relaying MTA MUST remove such a header field if the [SMTP] connection relaying
the message is not from a trusted internal MTA. This means the MTA the message is not from a trusted internal MTA. This means the MTA
needs to be able to understand versions of this header field at least needs to be able to understand versions of this header field at least
as late as the ones understood by the MUAs or other consumers within as late as the ones understood by the MUAs or other consumers within
its ADMD. its ADMD.
6. IANA Considerations 6. IANA Considerations
IANA has registered the defined header field and created two tables IANA has registered the defined header field and created tables as
as described below. These registry actions were originally defined described below. These registry actions were originally defined by
by [RFC5451] and updated by [RFC6577] and [RFC7001]. The created [RFC5451] and updated by [RFC6577] and [RFC7001]. The created
registries are being further updated here to increase their registries are being further updated here to increase their
completeness. completeness.
6.1. The Authentication-Results Header Field 6.1. The Authentication-Results Header Field
[RFC5451] added the Authentication-Results header field to the IANA [RFC5451] added the Authentication-Results header field to the IANA
"Permanent Message Header Field Names" registry, per the procedure "Permanent Message Header Field Names" registry, per the procedure
found in [IANA-HEADERS]. That entry is to be updated to reference found in [IANA-HEADERS]. That entry is to be updated to reference
this document. The following is the registration template: this document. The following is the registration template:
skipping to change at page 30, line 8 skipping to change at page 30, line 12
removing comments, and removing the local-part if not removing comments, and removing the local-part if not
authenticated 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. IANA shall update this registry to show Section 2.3 of registry.
this document as the current definitions for the "body", "header",
"policy" and "smtp" entries of that registry. Entries in this registry are subject to the Expert Review rules as
described in [IANA-CONSIDERATIONS]. Each entry in the registry
requires the following values:
ptype: The name of the ptype being registered, which must fit within
the ABNF described in Section 2.2.
Definition: An optional reference to a defining specification.
Description: A brief description of what sort of information this
"ptype" is meant to cover.
For new entries, the Designated Expert needs to assure that the
description provided for the new entry adequately describes the
intended use. An example would be helpful to include in the entry's
defining document, if any, although entries in the "Email
Authentication Methods" registry or the "Email Authentication Result
Names" registry might also serve as examples of intended use.
IANA shall update this registry to show Section 2.3 of this document
as the current definitions for the "body", "header", "policy" and
"smtp" entries of that registry.
6.5. "Email Authentication Result Names" Description 6.5. "Email Authentication Result Names" Description
Names of message authentication result codes supported by this Names of message authentication result codes supported by this
specification must be registered with IANA, with the exception of specification must be registered with IANA, with the exception of
experimental codes as described in Section 2.7.7. A registry was experimental codes as described in Section 2.7.7. A registry was
created by [RFC5451] for this purpose. [RFC6577] added the "status" created by [RFC5451] for this purpose. [RFC6577] added the "status"
column, and [RFC7001] updated the rules governing that registry. column, and [RFC7001] updated the rules governing that registry.
New entries are assigned only for values that have received Expert New entries are assigned only for values that have received Expert
skipping to change at page 33, line 16 skipping to change at page 33, line 38
Support for some of these is being considered for future work. Support for some of these is being considered for future work.
In any case, a mechanism needs to exist for an MUA or filter to In any case, a mechanism needs to exist for an MUA or filter to
verify that the host that appears to have added the header field (a) verify that the host that appears to have added the header field (a)
actually did so and (b) is legitimately adding that header field for actually did so and (b) is legitimately adding that header field for
this delivery. Given the variety of messaging environments deployed this delivery. Given the variety of messaging environments deployed
today, consensus appears to be that specifying a particular mechanism today, consensus appears to be that specifying a particular mechanism
for doing so is not appropriate for this document. for doing so is not appropriate for this document.
Mitigation of the forged header field attack can also be accomplished Mitigation of the forged header field attack can also be accomplished
by moving the authentication results data into metadata associated by moving the authentication results data into meta-data associated
with the message. In particular, an [SMTP] extension could be with the message. In particular, an [SMTP] extension could be
established to communicate authentication results from the border MTA established to communicate authentication results from the border MTA
to intermediate and delivery MTAs; the latter of these could arrange to intermediate and delivery MTAs; the latter of these could arrange
to store the authentication results as metadata retrieved and to store the authentication results as meta-data retrieved and
rendered along with the message by an [IMAP] client aware of a rendered along with the message by an [IMAP] client aware of a
similar extension in that protocol. The delivery MTA would be told similar extension in that protocol. The delivery MTA would be told
to trust data via this extension only from MTAs it trusts, and border to trust data via this extension only from MTAs it trusts, and border
MTAs would not accept data via this extension from any source. There MTAs would not accept data via this extension from any source. There
is no vector in such an arrangement for forgery of authentication is no vector in such an arrangement for forgery of authentication
data by an outside agent. data by an outside agent.
7.2. Misleading Results 7.2. Misleading Results
Until some form of service for querying the reputation of a sending Until some form of service for querying the reputation of a sending
skipping to change at page 33, line 47 skipping to change at page 34, line 24
issue is not resolved by forged header field removal discussed above. issue is not resolved by forged header field removal discussed above.
Hence, MUAs and downstream filters must take some care with use of Hence, MUAs and downstream filters must take some care with use of
this header even after possibly malicious headers are scrubbed. this header even after possibly malicious headers are scrubbed.
7.3. Header Field Position 7.3. Header Field Position
Despite the requirements of [MAIL], header fields can sometimes be Despite the requirements of [MAIL], header fields can sometimes be
reordered en route by intermediate MTAs. The goal of requiring reordered en route by intermediate MTAs. The goal of requiring
header field addition only at the top of a message is an header field addition only at the top of a message is an
acknowledgement that some MTAs do reorder header fields, but most do acknowledgment that some MTAs do reorder header fields, but most do
not. Thus, in the general case, there will be some indication of not. Thus, in the general case, there will be some indication of
which MTAs (if any) handled the message after the addition of the which MTAs (if any) handled the message after the addition of the
header field defined here. header field defined here.
7.4. Reverse IP Query Denial-of-Service Attacks 7.4. Reverse IP Query Denial-of-Service Attacks
Section 4.6.4 of [SPF] describes a DNS-based denial-of-service attack Section 4.6.4 of [SPF] describes a DNS-based denial-of-service attack
for verifiers that attempt DNS-based identity verification of for verifiers that attempt DNS-based identity verification of
arriving client connections. A verifier wishing to do this check and arriving client connections. A verifier wishing to do this check and
report this information needs to take care not to go to unbounded report this information needs to take care not to go to unbounded
skipping to change at page 36, line 49 skipping to change at page 37, line 21
[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.
[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)", Reporting and Conformance (DMARC)", RFC 7489,
I-D draft-kucherawy-dmarc-base, February 2015. March 2015.
[DNS] Mockapetris, P., "Domain names - [DNS] Mockapetris, P., "Domain names -
Implementation and Specification", STD 13, Implementation and Specification", STD 13,
RFC 1035, November 1987. RFC 1035, November 1987.
[DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M.
Souissi, "DNS Extensions to Support IP Version Souissi, "DNS Extensions to Support IP Version
6", RFC 3596, October 2003. 6", RFC 3596, October 2003.
[DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for [DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for
skipping to change at page 38, line 36 skipping to change at page 39, line 8
Registration for S/MIME Signature Registration for S/MIME Signature
Verification", RFC 7281, June 2014. Verification", RFC 7281, June 2014.
[SPF] Kitterman, S., "Sender Policy Framework (SPF) [SPF] Kitterman, S., "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, for Authorizing Use of Domains in E-Mail,
Version 1", RFC 7208, April 2014. Version 1", RFC 7208, April 2014.
[VBR] Hoffman, P., Levine, J., and A. Hathcock, [VBR] Hoffman, P., Levine, J., and A. Hathcock,
"Vouch By Reference", RFC 5518, April 2009. "Vouch By Reference", RFC 5518, April 2009.
Appendix A. Acknowledgements Appendix A. 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: Stephane review and constructive criticism of this document: Stephane
Bortzmeyer, Scott Kitterman, John Levine, and Tom Petch. Bortzmeyer, Scott Kitterman, John Levine, Tom Petch, and Pete
Resnick.
Appendix B. Legacy MUAs Appendix B. Legacy MUAs
Implementers of this protocol should be aware that many MUAs are Implementers of this protocol should be aware that many MUAs are
unlikely to be retrofitted to support the new header field and its unlikely to be retrofitted to support the new header field and its
semantics. In the interests of convenience and quicker adoption, a semantics. In the interests of convenience and quicker adoption, a
delivery MTA might want to consider adding things that are processed delivery MTA might want to consider adding things that are processed
by existing MUAs in addition to the Authentication-Results header by existing MUAs in addition to the Authentication-Results header
field. One suggestion is to include a Priority header field, on field. One suggestion is to include a Priority header field, on
messages that don't already have such a header field, containing a messages that don't already have such a header field, containing a
skipping to change at page 46, line 32 skipping to change at page 46, line 32
The border MTA for chicago.example.com explicitly trusts results from The border MTA for chicago.example.com explicitly trusts results from
mail-router.example.net, so that header field is not removed. It mail-router.example.net, so that header field is not removed. It
performs evaluation of both signatures and determines that the first performs evaluation of both signatures and determines that the first
(most recent) is a "pass" but, because of the aforementioned (most recent) is a "pass" but, because of the aforementioned
modifications, the second is a "fail". However, the first signature modifications, the second is a "fail". However, the first signature
included the Authentication-Results header added at mail- included the Authentication-Results header added at mail-
router.example.net that validated the second signature. Thus, router.example.net that validated the second signature. Thus,
indirectly, it can be determined that the authentications claimed by indirectly, it can be determined that the authentications claimed by
both signatures are indeed valid. both signatures are indeed valid.
Note that two styles of presenting metadata about the result are in Note that two styles of presenting meta-data about the result are in
use here. In one case, the "reason=" clause is present, which is use here. In one case, the "reason=" clause is present, which is
intended for easy extraction by parsers; in the other case, the CFWS intended for easy extraction by parsers; in the other case, the CFWS
production of the ABNF is used to include such data as a header field production of the ABNF is used to include such data as a header field
comment. The latter can be harder for parsers to extract given the comment. The latter can be harder for parsers to extract given the
varied supported syntaxes of mail header fields. varied supported syntaxes of mail header fields.
C.7. Comment-Heavy Example C.7. Comment-Heavy Example
The formal syntax permits comments within the content in a number of The formal syntax permits comments within the content in a number of
places. For the sake of illustration, this example is also legal: places. For the sake of illustration, this example is also legal:
skipping to change at page 50, line 14 skipping to change at page 50, line 14
o Rework the Email Authentication Result Names registry. 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]. o Add references: [RFC6008].
E.6. -04 to -05
o Fix typos.
o Rework some text around ignoring unknown ptypes.
o Completely describe the ptypes registry.
o EHLO is mapped to HELO for SPF.
o RFC7208 uses all-lowercase result strings now, so adjust prose
accordingly.
o Move the RFC6008 reference up to where the DKIM reporting is
described.
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. 27 change blocks. 
46 lines changed or deleted 84 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/