draft-ietf-appsawg-rfc7001bis-00.txt   draft-ietf-appsawg-rfc7001bis-01.txt 
Individual submission M. Kucherawy Individual submission M. Kucherawy
Internet-Draft February 18, 2015 Internet-Draft February 19, 2015
Obsoletes: 7001, 7410 Obsoletes: 7001, 7410
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: August 22, 2015 Expires: August 23, 2015
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-appsawg-rfc7001bis-00 draft-ietf-appsawg-rfc7001bis-01
Abstract Abstract
This document specifies a message header field called Authentication- This document specifies a message header field called Authentication-
Results for use with electronic mail messages to indicate the results Results for use with electronic mail messages to indicate the results
of message authentication efforts. Any receiver-side software, such of message authentication efforts. Any receiver-side software, such
as mail filters or Mail User Agents (MUAs), can use this header field as mail filters or Mail User Agents (MUAs), can use this header field
to relay that information in a convenient and meaningful way to users to relay that information in a convenient and meaningful way to users
or to make sorting and filtering decisions. or to make sorting and filtering decisions.
skipping to change at page 1, line 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 August 22, 2015. This Internet-Draft will expire on August 23, 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 24 skipping to change at page 2, line 24
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . 7
1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 8 1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 8
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. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 12 2.3. Property Types (ptypes) . . . . . . . . . . . . . . . . . 12
2.4. Authentication Identifier Field . . . . . . . . . . . . . 13 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 13
2.5. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Properties . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Defined Methods and Result Values . . . . . . . . . . . . 14 2.6. Authentication Identifier Field . . . . . . . . . . . . . 14
2.6.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 15 2.7. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 15
2.6.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 16 2.8. Defined Methods and Result Values . . . . . . . . . . . . 16
2.6.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 17 2.8.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16
2.6.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 17 2.8.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17
2.6.5. Other Registered Codes . . . . . . . . . . . . . . . . 18 2.8.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 18
2.6.6. Extension Methods . . . . . . . . . . . . . . . . . . 18 2.8.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19
2.6.7. Extension Result Codes . . . . . . . . . . . . . . . . 19 2.8.5. Other Registered Codes . . . . . . . . . . . . . . . . 19
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 19 2.8.6. Extension Methods . . . . . . . . . . . . . . . . . . 19
4. Adding the Header Field to a Message . . . . . . . . . . . . . 21 2.8.7. Extension Result Codes . . . . . . . . . . . . . . . . 20
4.1. Header Field Position and Interpretation . . . . . . . . . 22 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 21
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 23 4. Adding the Header Field to a Message . . . . . . . . . . . . . 22
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 23 4.1. Header Field Position and Interpretation . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 24
6.1. The Authentication-Results Header Field . . . . . . . . . 25 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 24
6.2. "Email Authentication Methods" Registry . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.3. "Email Authentication Result Names" Registry . . . . . . . 26 6.1. The Authentication-Results Header Field . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6.2. "Email Authentication Methods" Registry . . . . . . . . . 26
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 26 6.3. "Email Authentication Result Names" Registry . . . . . . . 27
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 28 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 27
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 28 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 29
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 29 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 29
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 29 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 29
7.7. Attacks against Authentication Methods . . . . . . . . . . 29 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 30
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 29 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 30
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 29 7.7. Attacks against Authentication Methods . . . . . . . . . . 30
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 30 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 30
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 30 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 30 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix C. Authentication-Results Examples . . . . . . . . . . . 33 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34
C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 33 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 34
Appendix C. Authentication-Results Examples . . . . . . . . . . . 34
C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 35
C.2. Nearly Trivial Case; Service Provided, but No C.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 34 Authentication Done . . . . . . . . . . . . . . . . . . . 35
C.3. Service Provided, Authentication Done . . . . . . . . . . 35 C.3. Service Provided, Authentication Done . . . . . . . . . . 36
C.4. Service Provided, Several Authentications Done, Single C.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
C.5. Service Provided, Several Authentications Done, C.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 37 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 38
C.6. Service Provided, Multi-Tiered Authentication Done . . . . 39 C.6. Service Provided, Multi-Tiered Authentication Done . . . . 40
C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 40 C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 41
Appendix D. Operational Considerations about Message Appendix D. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 41 Authentication . . . . . . . . . . . . . . . . . . . 42
Appendix E. To Do List . . . . . . . . . . . . . . . . . . . . . 42 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 43
Appendix F. Change History . . . . . . . . . . . . . . . . . . . 42 E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 43
F.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 42 E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 44
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 11, line 12 skipping to change at page 11, line 12
method-version = 1*DIGIT [CFWS] method-version = 1*DIGIT [CFWS]
; indicates which version of the method specification is ; indicates which version of the method specification is
; in use, corresponding to the matching entry in the IANA ; in use, corresponding to the matching entry in the IANA
; "Email Authentication Methods" registry; a value of "1" ; "Email Authentication Methods" registry; a value of "1"
; is assumed if this version string is absent ; is assumed if this version string is absent
result = Keyword result = Keyword
; indicates the results of the attempt to authenticate ; indicates the results of the attempt to authenticate
; the message; see below for details ; the message; see below for details
ptype = "smtp" / "header" / "body" / "policy" ptype = Keyword
; indicates whether the property being evaluated was ; indicates whether the property being evaluated was
; a parameter to an [SMTP] command, was a value taken ; a parameter to an [SMTP] command, was a value taken
; from a message header field, was some property of ; from a message header field, was some property of
; the message body, or was some other property evaluated by ; the message body, or was some other property evaluated by
; the receiving MTA ; the receiving MTA; expected to be one of the "property
; types" explicitly defined as valid, or an extension
; ptype, as defined below
property = special-smtp-verb / Keyword property = special-smtp-verb / Keyword
; if "ptype" is "smtp", this indicates which [SMTP] ; indicates more specifically than "ptype" what the
; command provided the value that was evaluated by the ; source of the evaluated property is; the exact meaning
; authentication scheme being applied; if "ptype" is ; is specific to the method whose result is being reported
; "header", this indicates from which header field the ; and is defined more clearly below
; value being evaluated was extracted; if "ptype" is
; "body", this indicates where in the message body
; a value being evaluated can be found (e.g., a specific
; offset into the message or a reference to a MIME part);
; if "ptype" is "policy", then this indicates the name
; of the policy that caused this header field to be
; added (see below)
special-smtp-verb = "mailfrom" / "rcptto" special-smtp-verb = "mailfrom" / "rcptto"
; special cases of [SMTP] commands that are made up ; special cases of [SMTP] commands that are made up
; of multiple words ; of multiple words
pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name ) pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name )
[CFWS] [CFWS]
; the value extracted from the message property defined ; the value extracted from the message property defined
; by the "ptype.property" construction ; by the "ptype.property" construction
"local-part" is defined in Section 3.4.1 of [MAIL], and "CFWS" is "local-part" is defined in Section 3.4.1 of [MAIL], and "CFWS" is
defined in Section 3.2.2 of [MAIL]. defined in Section 3.2.2 of [MAIL].
"Keyword" is defined in Section 4.1.2 of [SMTP]. "Keyword" is defined in Section 4.1.2 of [SMTP].
The "value" is as defined in Section 5.1 of [MIME]. The "value" is as defined in Section 5.1 of [MIME].
The "domain-name" is as defined in Section 3.5 of [DKIM]. The "domain-name" is as defined in Section 3.5 of [DKIM].
The "Keyword" used in "result" above is further constrained by the The "Keyword" used in "result" above is further constrained by the
necessity of being enumerated in Section 2.6. necessity of being enumerated in Section 2.8.
See Section 2.4 for a description of the authserv-id element. See Section 2.6 for a description of the authserv-id element.
If the value portion of a "pvalue" construction identifies something If the value portion of a "pvalue" construction identifies something
intended to be an e-mail identity, then it MUST use the right hand intended to be an e-mail identity, then it MUST use the right hand
portion of that ABNF definition. portion of that ABNF definition.
The list of commands eligible for use with the "smtp" ptype can be The list of commands eligible for use with the "smtp" ptype can be
found in Section 4.1 of [SMTP]. found in Section 4.1 of [SMTP].
The "propspec" may be omitted if, for example, the method was unable The "propspec" may be omitted if, for example, the method was unable
to extract any properties to do its evaluation yet has a result to to extract any properties to do its evaluation yet has a result to
report. report.
Where an SMTP command name is being reported as a "property", the Where an SMTP command name is being reported as a "property", the
agent generating the header field represents that command by agent generating the header field represents that command by
converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" converting it to lowercase and dropping any spaces (e.g., "MAIL FROM"
becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.).
A "ptype" value of "policy" indicates a policy decision about the A "ptype" value of "policy" indicates a policy decision about the
message not specific to a property of the message that could be message not specific to a property of the message that could be
extracted. See Section 2.3 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. The "policy" ptype 2.3. Property Types (ptypes)
A special ptype value of "policy" is defined. This ptype is provided The "ptype" in the ABNF above indicates the type of property being
to indicate that some local policy mechanism was applied that described by the result being reported, upon which the reported
augments or even replaces (i.e., overrides) the result returned by result was based. Coupled with the "property", it inidcates from
the authentication mechanism. The property and value in this case which part of the message the reported data were extracted.
Legal values of "ptype" are as defined in the IANA "Email
Authentication Property Types" registry, created by
[PTYPES-REGISTRY]. The initial values are as follows, copied from
[RFC7001]:
body: Indicates information that was extracted from the body of the
message. This might be an arbitrary string of bytes, a hash of a
string of bytes, a Uniform Resource Identifier, or some other
content of interest.
header: Indicates information that was extracted from the header of
the message. This might be the value of a header field or some
portion of a header field.
policy: A local policy mechanism was applied that augments or
overrides the result returned by the authentication mechanism.
(See Section 2.4.)
smtp: Indicates information that was extracted from an SMTP command
that was used to relay the message.
When a consumer of this header field encounters a "ptype" that it
does not understand, it ignores the result reported with that
"ptype".
2.4. The "policy" ptype
A special ptype value of "policy" is also defined. This ptype is
provided to indicate that some local policy mechanism was applied
that augments or even replaces (i.e., overrides) the result returned
by the authentication mechanism. The property and value in this case
identify the local policy that was applied and the result it identify the local policy that was applied and the result it
returned. returned.
For example, a DKIM signature is not required to include the Subject For example, a DKIM signature is not required to include the Subject
header field in the set of fields that are signed. An ADMD receiving header field in the set of fields that are signed. An ADMD receiving
such a message might decide that such a signature is unacceptable, such a message might decide that such a signature is unacceptable,
even if it passes, because the content of the Subject header field even if it passes, because the content of the Subject header field
could be altered post-signing without invalidating the signature. could be altered post-signing without invalidating the signature.
Such an ADMD could replace the DKIM "pass" result with a "policy" Such an ADMD could replace the DKIM "pass" result with a "policy"
result and then also include the following in the corresponding result and then also include the following in the corresponding
skipping to change at page 13, line 15 skipping to change at page 13, line 46
normally registered with IANA or otherwise specified apart from normally registered with IANA or otherwise specified apart from
setting syntax restrictions that allow for easy parsing within the setting syntax restrictions that allow for easy parsing within the
rest of the header field. rest of the header field.
This ptype existed in the original specification for this header This ptype existed in the original specification for this header
field, but without a complete description or example of intended use. field, but without a complete description or example of intended use.
As a result, it has not seen any practical use to date that matches As a result, it has not seen any practical use to date that matches
its intended purpose. These added details are provided to guide its intended purpose. These added details are provided to guide
implementers toward proper use. implementers toward proper use.
2.4. Authentication Identifier Field 2.5. Properties
While the "ptype" names the general area from which some data of
interest were extracted to perform authentication, the associated
"property" is more specific. Its meaning, however, can also vary
slightly depeneding on which authentication method's result is being
reported.
Generally, the properties are defined as follows:
header: Indicates from which header field the value being evaluated
was extracted.
body: Indicates where in the message body a value being evaluated
can be found (e.g., a specific offset into the message or a
reference to a MIME part).
policy: Indicates the local name of the policy that caused this
header field to be added (see Section 2.4).
smtp: Indicates which [SMTP] command provided the value that was
evaluated by the authentication scheme being applied.
Entries in the "Email Authentication Methods" registry can define
properties that deviate from these definitions when appropriate. For
example, when reporting the result of a [DKIM] evaluation, it would
be redundant to report the name of the header field from which
details were extracted. Thus, instead, DKIM results use the "header"
property to name the signature tag from which a detail of interest
was extracted.
2.6. Authentication Identifier Field
Every Authentication-Results header field has an authentication Every Authentication-Results header field has an authentication
service identifier field (authserv-id above). Specifically, this is service identifier field (authserv-id above). Specifically, this is
any string intended to identify the authentication service within the any string intended to identify the authentication service within the
ADMD that conducted authentication checks on the message. This ADMD that conducted authentication checks on the message. This
identifier is intended to be machine-readable and not necessarily identifier is intended to be machine-readable and not necessarily
meaningful to users. meaningful to users.
Since agents consuming this field will use this identifier to Since agents consuming this field will use this identifier to
determine whether its contents are of interest (and are safe to use), determine whether its contents are of interest (and are safe to use),
skipping to change at page 14, line 22 skipping to change at page 15, line 34
downstream filter will have access to accurate information for downstream filter will have access to accurate information for
assessing the usability of the header field's content. In assessing the usability of the header field's content. In
particular, consumers of the header field will need to know not particular, consumers of the header field will need to know not
only the current identifier(s) in use but previous ones as well to only the current identifier(s) in use but previous ones as well to
account for delivery latency or later re-assessment of the header account for delivery latency or later re-assessment of the header
field's contents. field's contents.
Examples of valid authentication identifiers are "example.com", Examples of valid authentication identifiers are "example.com",
"mail.example.org", "ms1.newyork.example.com", and "example-auth". "mail.example.org", "ms1.newyork.example.com", and "example-auth".
2.5. Version Tokens 2.7. Version Tokens
The grammar above provides for the optional inclusion of versions on The grammar above provides for the optional inclusion of versions on
both the header field itself (attached to the authserv-id token) and both the header field itself (attached to the authserv-id token) and
on each of the methods being reported. The method version refers to on each of the methods being reported. The method version refers to
the method itself, which is specified in the documents describing the method itself, which is specified in the documents describing
those methods, while the authserv-id version refers to this document those methods, while the authserv-id version refers to this document
and thus the syntax of this header field. and thus the syntax of this header field.
The purpose of including these is to avoid misinterpretation of the The purpose of including these is to avoid misinterpretation of the
results. That is, if a parser finds a version after an authserv-id results. That is, if a parser finds a version after an authserv-id
skipping to change at page 14, line 44 skipping to change at page 16, line 8
trying to parse since what follows might not be in an expected trying to parse since what follows might not be in an expected
format. For a method version, the parser SHOULD ignore a method format. For a method version, the parser SHOULD ignore a method
result if the version is not supported in case the semantics of the result if the version is not supported in case the semantics of the
result have a different meaning than what is expected. For example, result have a different meaning than what is expected. For example,
if a hypothetical DKIM version 2 yielded a "pass" result for if a hypothetical DKIM version 2 yielded a "pass" result for
different reasons than version 1 does, a consumer of this field might different reasons than version 1 does, a consumer of this field might
not want to use the altered semantics. Allowing versions in the not want to use the altered semantics. Allowing versions in the
syntax is a way to indicate this and let the consumer of the header syntax is a way to indicate this and let the consumer of the header
field decide. field decide.
2.6. Defined Methods and Result Values 2.8. Defined Methods and Result Values
Each individual authentication method returns one of a set of Each individual authentication method returns one of a set of
specific result values. The subsections below provide references to specific result values. The subsections below provide references to
the documents defining the authentication methods specifically the documents defining the authentication methods specifically
supported by this document, and their corresponding result values. supported by this document, and their corresponding result values.
Verifiers SHOULD use these values as described below. New methods Verifiers SHOULD use these values as described below. New methods
not specified in this document, but intended to be supported by the not specified in this document, but intended to be supported by the
header field defined here, MUST include a similar result table either header field defined here, MUST include a similar result table either
in their defining documents or in supplementary ones. in their defining documents or in supplementary ones.
2.6.1. DKIM and DomainKeys 2.8.1. DKIM and DomainKeys
DKIM is represented by the "dkim" method and is defined in [DKIM]. DKIM is represented by the "dkim" method and is defined in [DKIM].
DomainKeys is defined in [DOMAINKEYS] and is represented by the DomainKeys is defined in [DOMAINKEYS] and is represented by the
"domainkeys" method. "domainkeys" method.
A signature is "acceptable to the ADMD" if it passes local policy A signature is "acceptable to the ADMD" if it passes local policy
checks (or there are no specific local policy checks). For example, checks (or there are no specific local policy checks). For example,
an ADMD policy might require that the signature(s) on the message be an ADMD policy might require that the signature(s) on the message be
added using the DNS domain present in the From header field of the added using the DNS domain present in the From header field of the
message, thus making third-party signatures unacceptable even if they message, thus making third-party signatures unacceptable even if they
skipping to change at page 16, line 6 skipping to change at page 17, line 20
permerror: The message could not be verified due to some error that permerror: The message could not be verified due to some error that
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] 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.
2.6.2. SPF and Sender ID 2.8.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.5 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 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| none | [RFC4408], Section 2.5.1 | | none | [RFC7208], Section 2.6.1 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| pass | [RFC4408], Section 2.5.3 | | pass | [RFC7208], Section 2.6.3 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| fail | [RFC4408], Section 2.5.4 | | fail | [RFC7208], Section 2.6.4 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| softfail | [RFC4408], Section 2.5.5 | | softfail | [RFC7208], Section 2.6.5 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| policy | [RFC7001], Section 2.6.2 | | policy | [this RFC], Section 2.4 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| neutral | [RFC4408], Section 2.5.2 | | neutral | [RFC7208], Section 2.6.2 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| temperror | [RFC4408], Section 2.5.6 | | temperror | [RFC7208], Section 2.6.6 |
+-----------+--------------------------------+ +-----------+--------------------------------+
| permerror | [RFC4408], Section 2.5.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.
Similarly, the results for Sender ID are listed and described in Similarly, the results for Sender ID are listed and described in
Section 4.2 of [SENDERID], which in turn uses the SPF definitions. Section 4.2 of [SENDERID], which in turn uses the SPF definitions
that now appear in [SPF].
Note that both of those documents specify result codes that use mixed Note that both of those documents specify result codes that use mixed
case, but they are typically used all lowercase in this context. case, but they are typically used all lowercase in this context.
In both cases, an additional result of "policy" is defined, which In both cases, 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
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.
2.6.3. "iprev" 2.8.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
"forward" lookups each produced results, but they were not in "forward" lookups each produced results, but they were not in
agreement, or the "forward" query completed but produced no agreement, or the "forward" query completed but produced no
skipping to change at page 17, line 43 skipping to change at page 19, line 8
completion of the evaluation. A later attempt is unlikely to completion of the evaluation. A later attempt is unlikely to
produce a final result. produce a final result.
There is no "none" for this method since any TCP connection There is no "none" for this method since any TCP connection
delivering email has an IP address associated with it, so some kind delivering email has an IP address associated with it, so some kind
of evaluation will always be possible. of evaluation will always be possible.
For discussion of the format of DNS replies, see "Domain Names - For discussion of the format of DNS replies, see "Domain Names -
Implementation and Specification" ([DNS]). Implementation and Specification" ([DNS]).
2.6.4. SMTP AUTH 2.8.4. SMTP AUTH
SMTP AUTH (defined in [AUTH]) is represented by the "auth" method, SMTP AUTH (defined in [AUTH]) is represented by the "auth" method,
and its result values are as follows: and its result values are as follows:
none: SMTP authentication was not attempted. none: SMTP authentication was not attempted.
pass: The SMTP client authenticated to the server reporting the pass: The SMTP client authenticated to the server reporting the
result using the protocol described in [AUTH]. result using the protocol described in [AUTH].
fail: The SMTP client attempted to authenticate to the server using fail: The SMTP client attempted to authenticate to the server using
skipping to change at page 18, line 29 skipping to change at page 19, line 39
permerror: The SMTP client attempted to authenticate using the permerror: The SMTP client attempted to authenticate using the
protocol described in [AUTH] but was not able to complete the protocol described in [AUTH] but was not able to complete the
attempt due to some error that is likely not transient in nature, attempt due to some error that is likely not transient in nature,
such as a permanent directory service lookup error. A later such as a permanent directory service lookup error. A later
attempt is not likely to produce a final result. attempt is not likely to produce a final result.
An agent making use of the data provided by this header field SHOULD An agent making use of the data provided by this header field SHOULD
consider "fail" and "temperror" to be synonymous in terms of message consider "fail" and "temperror" to be synonymous in terms of message
authentication, i.e., the client did not authenticate in either case. authentication, i.e., the client did not authenticate in either case.
2.6.5. Other Registered Codes 2.8.5. Other Registered Codes
Result codes were also registered in other RFCs for Vouch By Result codes were also registered in other RFCs for Vouch By
Reference (in [AR-VBR], represented by "vbr"), Authorized Third-Party Reference (in [AR-VBR], represented by "vbr"), Authorized Third-Party
Signatures (in [ATPS], represented by "dkim-atps"), and the DKIM- Signatures (in [ATPS], represented by "dkim-atps"), and the DKIM-
related Author Domain Signing Practices (in [ADSP], represented by related Author Domain Signing Practices (in [ADSP], represented by
"dkim-adsp"). "dkim-adsp").
2.6.6. Extension Methods 2.8.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:
1. To allow additional information from new authentication systems 1. To allow additional information from new authentication systems
skipping to change at page 19, line 28 skipping to change at page 20, line 36
Experimental method identifiers MUST only be used within ADMDs that Experimental method identifiers MUST only be used within ADMDs that
have explicitly consented to use them. These method identifiers and have explicitly consented to use them. These method identifiers and
the parameters associated with them are not documented in RFCs. the parameters associated with them are not documented in RFCs.
Therefore, they are subject to change at any time and not suitable Therefore, they are subject to change at any time and not suitable
for production use. Any MTA, MUA, or downstream filter intended for for production use. Any MTA, MUA, or downstream filter intended for
production use SHOULD ignore or delete any Authentication-Results production use SHOULD ignore or delete any Authentication-Results
header field that includes an experimental (unknown) method header field that includes an experimental (unknown) method
identifier. identifier.
2.6.7. Extension Result Codes 2.8.7. Extension Result Codes
Additional result codes (extension results) might be defined in the Additional result codes (extension results) might be defined in the
future by later revisions or extensions to this specification. future by later revisions or extensions to this specification.
Result codes MUST be registered with the Internet Assigned Numbers Result codes MUST be registered with the Internet Assigned Numbers
Authority (IANA) and preferably published in an RFC. See Section 6 Authority (IANA) and preferably published in an RFC. See Section 6
for further details. for further details.
Extension results MUST only be used within ADMDs that have explicitly Experimental results MUST only be used within ADMDs that have
consented to use them. These results and the parameters associated explicitly consented to use them. These results and the parameters
with them are not formally documented. Therefore, they are subject associated with them are not formally documented. Therefore, they
to change at any time and not suitable for production use. Any MTA, are subject to change at any time and not suitable for production
MUA, or downstream filter intended for production use SHOULD ignore use. Any MTA, MUA, or downstream filter intended for production use
or delete any Authentication-Results header field that includes an SHOULD ignore or delete any Authentication-Results header field that
extension result. includes an extension result.
3. The "iprev" Authentication Method 3. The "iprev" Authentication Method
This section defines an additional authentication method called This section defines an additional authentication method called
"iprev". "iprev".
"iprev" is an attempt to verify that a client appears to be valid "iprev" is an attempt to verify that a client appears to be valid
based on some DNS queries, which is to say that the IP address is based on some DNS queries, which is to say that the IP address is
explicitly associated with a domain name. Upon receiving a session explicitly associated with a domain name. Upon receiving a session
initiation of some kind from a client, the IP address of the client initiation of some kind from a client, the IP address of the client
skipping to change at page 20, line 23 skipping to change at page 21, line 33
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.
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 5.5 of [SPF] chose a limit of administrator. As an example, Section 4.6.4 of [SPF] chose a limit
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.
There is some contention regarding the wisdom and reliability of this There is some contention regarding the wisdom and reliability of this
test. For example, in some regions, it can be difficult for this test. For example, in some regions, it can be difficult for this
test ever to pass because the practice of arranging to match the test ever to pass because the practice of arranging to match the
forward and reverse DNS is infrequently observed. Therefore, the forward and reverse DNS is infrequently observed. Therefore, the
precise implementation details of how a verifier performs an "iprev" precise implementation details of how a verifier performs an "iprev"
test are not specified here. The verifier MAY report a successful or test are not specified here. The verifier MAY report a successful or
skipping to change at page 21, line 16 skipping to change at page 22, line 21
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
its own knowledge of what that method evaluates. its own knowledge of what that method evaluates.
Each "method" MUST refer to an authentication method declared in the Each "method" MUST refer to an authentication method declared in the
IANA registry or an extension method as described in Section 2.6.6, IANA registry or an extension method as described in Section 2.8.6,
and each "result" MUST refer to a result code declared in the IANA and each "result" MUST refer to a result code declared in the IANA
registry or an extension result code as defined in Section 2.6.7. registry or an extension result code as defined in Section 2.8.7.
See Section 6 for further information about the registered methods See Section 6 for further information about the registered methods
and result codes. and result codes.
An MTA compliant with this specification adds this header field An MTA compliant with this specification adds this header field
(after performing one or more message authentication tests) to (after performing one or more message authentication tests) to
indicate which MTA or ADMD performed the test, which test got indicate which MTA or ADMD performed the test, which test got
applied, and what the result was. If an MTA applies more than one applied, and what the result was. If an MTA applies more than one
such test, it adds this header field either once per test or once such test, it adds this header field either once per test or once
indicating all of the results. An MTA MUST NOT add a result to an indicating all of the results. An MTA MUST NOT add a result to an
existing header field. existing header field.
skipping to change at page 23, line 37 skipping to change at page 24, line 43
such cases, the border MTA SHOULD issue an SMTP rejection response to such cases, the border MTA SHOULD issue an SMTP rejection response to
the message, rather than adding this header field and allowing the the message, rather than adding this header field and allowing the
message to proceed toward delivery. This is more desirable than message to proceed toward delivery. This is more desirable than
allowing the message to reach an internal host's MTA or spam filter, allowing the message to reach an internal host's MTA or spam filter,
thus possibly generating a local rejection such as a Delivery Status thus possibly generating a local rejection such as a Delivery Status
Notification (DSN) [DSN] to a forged originator. Such generated Notification (DSN) [DSN] to a forged originator. Such generated
rejections are colloquially known as "backscatter". rejections are colloquially known as "backscatter".
The same MAY also be done for local policy decisions overriding the The same MAY also be done for local policy decisions overriding the
results of the authentication methods (e.g., the "policy" result results of the authentication methods (e.g., the "policy" result
codes described in Section 2.6). codes described in Section 2.8).
Such rejections at the SMTP protocol level are not possible if local Such rejections at the SMTP protocol level are not possible if local
policy is enforced at the MUA and not the MTA. policy is enforced at the MUA and not the MTA.
5. Removing Existing Header Fields 5. Removing Existing Header Fields
For security reasons, any MTA conforming to this specification MUST For security reasons, any MTA conforming to this specification MUST
delete any discovered instance of this header field that claims, by delete any discovered instance of this header field that claims, by
virtue of its authentication service identifier, to have been added virtue of its authentication service identifier, to have been added
within its trust boundary but that did not come directly from another within its trust boundary but that did not come directly from another
skipping to change at page 25, line 16 skipping to change at page 26, line 23
[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 has been updated to reference found in [IANA-HEADERS]. That entry has been 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): RFC 7001 Specification document(s): [this RFC]
Related information: Related information:
Requesting review of any proposed changes and additions to Requesting review of any proposed changes and additions to
this field is recommended. this field is recommended.
6.2. "Email Authentication Methods" Registry 6.2. "Email Authentication Methods" Registry
Names of message authentication methods supported by this Names of message authentication methods supported by this
specification are to be registered with IANA, with the exception of specification are to be registered with IANA, with the exception of
experimental names as described in Section 2.6.6. A registry was experimental names as described in Section 2.8.6. A registry was
created by [RFC5451] for this purpose. This document changes the created by [RFC5451] for this purpose. [RFC7001] amended ther rules
rules governing that registry. governing that registry, and also added a "version" field to the
registry.
New entries are assigned only for values that have received Expert New entries are assigned only for values that have received Expert
Review, per [IANA-CONSIDERATIONS]. The designated expert shall be Review, per [IANA-CONSIDERATIONS]. The designated expert shall be
appointed by the IESG. The designated expert has discretion to appointed by the IESG. The designated expert has discretion to
request that a publication be referenced if a clear, concise request that a publication be referenced if a clear, concise
definition of the authentication method cannot be provided such that definition of the authentication method cannot be provided such that
interoperability is assured. Registrations should otherwise be interoperability is assured. Registrations should otherwise be
permitted. The designated expert can also handle requests to mark permitted. The designated expert can also handle requests to mark
any current registration as "deprecated". any current registration as "deprecated".
Each method must register a name, the specification that defines it, Each method must register a name, the specification that defines it,
a version number associated with the method being registered a version number associated with the method being registered
(preferably starting at "1"), zero or more "ptype" values appropriate (preferably starting at "1"), zero or more "ptype" values appropriate
for use with that method, which "property" value(s) should be for use with that method, which "property" value(s) should be
reported by that method, and a description of the "value" to be used reported by that method, and a description of the "value" to be used
with each. with each.
All existing registry entries that reference [RFC5451] have been All existing registry entries that reference [RFC7001] are to be
updated to reference this document, except where entries have already updated to reference this document, except where entries have already
been deprecated. been deprecated.
IANA has also added a "version" field to all existing registry
entries. All current methods are recorded as version "1".
6.3. "Email Authentication Result Names" Registry 6.3. "Email Authentication Result Names" Registry
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.6.7. A registry was experimental codes as described in Section 2.8.7. A registry was
created by [RFC5451] for this purpose. This document changes the created by [RFC5451] for this purpose. [RFC7001] updated the rules
rules governing that registry. 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
Review, per [IANA-CONSIDERATIONS]. The designated expert shall be Review, per [IANA-CONSIDERATIONS]. The designated expert shall be
appointed by the IESG. The designated expert has discretion to appointed by the IESG. The designated expert has discretion to
request that a publication be referenced if a clear, concise request that a publication be referenced if a clear, concise
definition of the authentication result cannot be provided such that definition of the authentication result cannot be provided such that
interoperability is assured. Registrations should otherwise be interoperability is assured. Registrations should otherwise be
permitted. The designated expert can also handle requests to mark permitted. The designated expert can also handle requests to mark
any current registration as "deprecated". any current registration as "deprecated".
All existing registry entries that reference [RFC5451] have been All existing registry entries that reference [RFC7001] are to be
updated to reference this document. updated to reference this document.
The definitions for the SPF and Sender ID authentication methods are The definitions for the SPF and Sender ID authentication methods are
updated using the references found in Section 2.6.2. updated using the references found in Section 2.8.2.
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 28, line 46 skipping to change at page 29, line 51
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 acknowledgement 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 5.5 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
lengths to resolve "A" and "PTR" queries. MUAs or other filters lengths to resolve "A" and "PTR" queries. MUAs or other filters
making use of an "iprev" result specified by this document need to be making use of an "iprev" result specified by this document need to be
aware of the algorithm used by the verifier reporting the result and, aware of the algorithm used by the verifier reporting the result and,
especially, its limitations. especially, its limitations.
7.5. Mitigation of Backscatter 7.5. Mitigation of Backscatter
skipping to change at page 32, line 20 skipping to change at page 33, line 23
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 5226, May 2008. RFCs", BCP 26, RFC 5226, May 2008.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL
- VERSION 4rev1", RFC 3501, March 2003. - VERSION 4rev1", RFC 3501, March 2003.
[POP3] Myers, J. and M. Rose, "Post Office Protocol - [POP3] Myers, J. and M. Rose, "Post Office Protocol -
Version 3", STD 53, RFC 1939, May 1996. Version 3", STD 53, RFC 1939, May 1996.
[PTYPES-REGISTRY] Kucherawy, M., "A Property Types Registry for
the Authentication-Results Header Field",
RFC 7410, December 2014.
[RFC5451] Kucherawy, M., "Message Header Field for [RFC5451] Kucherawy, M., "Message Header Field for
Indicating Message Authentication Status", Indicating Message Authentication Status",
RFC 5451, April 2009. RFC 5451, April 2009.
[RFC7001] Kucherawy, M., "Message Header Field for
Indicating Message Authentication Status",
RFC 7001, September 2013.
[SECURITY] Rescorla, E. and B. Korver, "Guidelines for [SECURITY] Rescorla, E. and B. Korver, "Guidelines for
Writing RFC Text on Security Considerations", Writing RFC Text on Security Considerations",
BCP 72, RFC 3552, July 2003. BCP 72, RFC 3552, July 2003.
[SENDERID] Lyon, J. and M. Wong, "Sender ID: [SENDERID] Lyon, J. and M. Wong, "Sender ID:
Authenticating E-Mail", RFC 4406, April 2006. Authenticating E-Mail", RFC 4406, April 2006.
[SPF] Wong, M. and W. Schlitt, "Sender Policy [SPF] Kitterman, S., "Sender Policy Framework (SPF)
Framework (SPF) for Authorizing Use of Domains for Authorizing Use of Domains in E-Mail,
in E-Mail, Version 1", RFC 4408, April 2006. 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. Acknowledgements
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: (names) review and constructive criticism of this document: (names)
Appendix B. Legacy MUAs Appendix B. Legacy MUAs
skipping to change at page 42, line 37 skipping to change at page 43, 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. To Do List Appendix E. Change History
o Define "property" for each supported authentication scheme. E.1. RFC7001 to -00
(Errata #4201)
o Update all the RFC4408 references to RFC7208. o Remove "Changes since RFC5451" section; add this "Change History"
section.
o Apply RFC7410. o Restore XML to previous format. (No visible changes).
Appendix F. Change History o Reset "Acknowledgments".
F.1. RFC7001 to -00 o Add "To-Do" section.
Remove "Changes since RFC5451" section; add this "Change History" E.2. -00 to -01
section.
Restore XML to previous format. (No visible changes). o Apply RFC7410.
Reset "Acknowledgments". o Update all the RFC4408 references to RFC7208.
Add "To-Do" section. o Add section explaining "property" values. (Errata #4201)
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. 63 change blocks. 
135 lines changed or deleted 201 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/