RFC 7601
Message Header Field for Indicating Message Authentication Status
3. The "iprev" Authentication Method
This section defines an additional authentication method called "iprev". "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 explicitly associated with a domain name. Upon receiving a session initiation of some kind from a client, the IP address of the client peer is queried for matching names (i.e., a number-to-name translation, also known as a "reverse lookup" or a "PTR" record query). Once that result is acquired, a lookup of each of the names (i.e., a name-to-number translation, or an "A" or "AAAA" record query) thus retrieved is done. The response to this second check will typically result in at least one mapping back to the client's IP address. Expressed as an algorithm: If the client peer's IP address is I, the list of names to which I maps (after a "PTR" query) is the set N, and the union of IP addresses to which each member of N maps (after corresponding "A" and "AAAA" queries) is L, then this test is successful if I is an element of L.
Often an MTA receiving a connection that fails this test will simply reject the connection using the enhanced status code defined in [AUTH-ESC]. If an operator instead wishes to make this information available to downstream agents as a factor in handling decisions, it records a result in accordance with Section 2.7.3. The response to a PTR query could contain multiple names. To prevent heavy DNS loads, agents performing these queries MUST be implemented such that the number of names evaluated by generation of 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 administrator. As an example, Section 4.6.4 of [SPF] chose a limit of 10 for its implementation of this algorithm. "DNS Extensions to Support IP Version 6" ([DNS-IP6]) discusses the query formats for the IPv6 case. There is some contention regarding the wisdom and reliability of 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 forward and reverse DNS is infrequently observed. Therefore, the precise implementation details of how a verifier performs an "iprev" test are not specified here. The verifier MAY report a successful or failed "iprev" test at its discretion having done some kind of check of the validity of the connection's identity using DNS. It is incumbent upon an agent making use of the reported "iprev" result to understand what exactly that particular verifier is attempting to report. Extensive discussion of reverse DNS mapping and its implications can be found in "Considerations for the use of DNS Reverse Mapping" ([DNSOP-REVERSE]). In particular, it recommends that applications avoid using this test as a means of authentication or security. Its presence in this document is not an endorsement but is merely acknowledgment that the method remains common and provides the means to relay the results of that test.4. Adding the Header Field to a Message
This specification makes no attempt to evaluate the relative strengths of various message authentication methods that may become available. The methods listed are an order-independent set; their sequence does not indicate relative strength or importance of one method over another. Instead, the MUA or downstream filter consuming this header field is to interpret the result of each method based on its own knowledge of what that method evaluates.
Each "method" MUST refer to an authentication method declared in the IANA registry or an extension method as described in Section 2.7.6, and each "result" MUST refer to a result code declared in the IANA registry or an extension result code as defined in Section 2.7.7. See Section 6 for further information about the registered methods and result codes. An MTA compliant with this specification adds this header field (after performing one or more message authentication tests) to indicate which MTA or ADMD performed the test, which test got 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 indicating all of the results. An MTA MUST NOT add a result to an existing header field. An MTA MAY add this header field containing only the authentication identifier portion and the "none" token (see Section 2.2) to indicate explicitly that no message authentication schemes were applied prior to delivery of this message. An MTA adding this header field has to take steps to identify it as legitimate to the MUAs or downstream filters that will ultimately consume its content. One process to do so is described in Section 5. Further measures may be necessary in some environments. Some possible solutions are enumerated in Section 7.1. This document does not mandate any specific solution to this issue as each environment has its own facilities and limitations. Most known message authentication methods focus on a particular identifier to evaluate. SPF and Sender ID differ in that they can yield a result based on more than one identifier; specifically, SPF can evaluate the RFC5321.HELO parameter or the RFC5321.MailFrom parameter, and Sender ID can evaluate the RFC5321.MailFrom parameter or the Purported Responsible Address (PRA) identity. When generating this field to report those results, only the parameter that yielded the result is included. For MTAs that add this header field, adding header fields in order (at the top), per Section 3.6 of [MAIL], is particularly important. Moreover, this header field SHOULD be inserted above any other trace header fields such MTAs might prepend. This placement allows easy detection of header fields that can be trusted. End users making direct use of this header field might inadvertently trust information that has not been properly vetted. If, for example, a basic SPF result were to be relayed that claims an authenticated addr-spec, the local-part of that addr-spec has actually not been authenticated. Thus, an MTA adding this header
field SHOULD NOT include any data that has not been authenticated by the method(s) being applied. Moreover, MUAs SHOULD NOT render to users such information if it is presented by a method known not to authenticate it.4.1. Header Field Position and Interpretation
In order to ensure non-ambiguous results and avoid the impact of false header fields, MUAs and downstream filters SHOULD NOT interpret this header field unless specifically configured to do so by the user or administrator. That is, this interpretation should not be "on by default". Naturally then, users or administrators ought not activate such a feature unless (1) they are certain the header field will be validly added by an agent within the ADMD that accepts the mail that is ultimately read by the MUA, and (2) instances of the header field that appear to originate within the ADMD but are actually added by foreign MTAs will be removed before delivery. Furthermore, MUAs and downstream filters SHOULD NOT interpret this header field unless the authentication service identifier it bears appears to be one used within its own ADMD as configured by the user or administrator. MUAs and downstream filters MUST ignore any result reported using a "result" not specified in the IANA "Result Code" registry or a "ptype" not listed in the "Email Authentication Property Types" registry for such values as defined in Section 6. Moreover, such agents MUST ignore a result indicated for any "method" they do not specifically support. An MUA SHOULD NOT reveal these results to end users, absent careful human factors design considerations and testing, for the presentation of trust-related materials. For example, an attacker could register examp1e.com (note the digit "1" (one)) and send signed mail to intended victims; a verifier would detect that the signature was valid and report a "pass" even though it's clear the DNS domain name was intended to mislead. See Section 7.2 for further discussion. As stated in Section 2.1, this header field MUST be treated as though it were a trace header field as defined in Section 3.6.7 of [MAIL] and hence MUST NOT be reordered and MUST be prepended to the message, so that there is generally some indication upon delivery of where in the chain of handling MTAs the message authentication was done. Note that there are a few message handlers that are only capable of appending new header fields to a message. Strictly speaking, these handlers are not compliant with this specification. They can still add the header field to carry authentication details, but any signal
about where in the handling chain the work was done may be lost. Consumers SHOULD be designed such that this can be tolerated, especially from a producer known to have this limitation. MUAs SHOULD ignore instances of this header field discovered within message/rfc822 MIME attachments. Further discussion of these topics can be found in Section 7 below.4.2. Local Policy Enforcement
Some sites have a local policy that considers any particular authentication policy's non-recoverable failure results (typically "fail" or similar) as justification for rejecting the message. In such cases, the border MTA SHOULD issue an SMTP rejection response to the message, rather than adding this header field and allowing the message to proceed toward delivery. This is more desirable than allowing the message to reach an internal host's MTA or spam filter, thus possibly generating a local rejection such as a Delivery Status Notification (DSN) [DSN] to a forged originator. Such generated rejections are colloquially known as "backscatter". The same MAY also be done for local policy decisions overriding the results of the authentication methods (e.g., the "policy" result codes described in Section 2.7). Such rejections at the SMTP protocol level are not possible if local policy is enforced at the MUA and not the MTA.5. Removing Existing Header Fields
For security reasons, any MTA conforming to this specification MUST delete any discovered instance of this header field that claims, by virtue of its authentication service identifier, to have been added within its trust boundary but that did not come directly from another trusted MTA. For example, an MTA for example.com receiving a message MUST delete or otherwise obscure any instance of this header field bearing an authentication service identifier indicating that the header field was added within example.com prior to adding its own header fields. This could mean each MTA will have to be equipped with a list of internal MTAs known to be compliant (and hence trustworthy). For simplicity and maximum security, a border MTA could remove all instances of this header field on mail crossing into its trust boundary. However, this may conflict with the desire to access authentication results performed by trusted external service providers. It may also invalidate signed messages whose signatures
cover external instances of this header field. A more robust border MTA could allow a specific list of authenticating MTAs whose information is to be admitted, removing the header field originating from all others. As stated in Section 1.2, a formal definition of "trust boundary" is deliberately not made here. It is entirely possible that a border MTA for example.com will explicitly trust authentication results asserted by upstream host example.net even though they exist in completely disjoint administrative boundaries. In that case, the border MTA MAY elect not to delete those results; moreover, the upstream host doing some authentication work could apply a signing technology such as [DKIM] on its own results to assure downstream hosts of their authenticity. An example of this is provided in Appendix B. Similarly, in the case of messages signed using [DKIM] or other message-signing methods that sign header fields, this removal action could invalidate one or more signatures on the message if they covered the header field to be removed. This behavior can be desirable since there's little value in validating the signature on a message with forged header fields. However, signing agents MAY therefore elect to omit these header fields from signing to avoid this situation. An MTA SHOULD remove any instance of this header field bearing a version (express or implied) that it does not support. However, an 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 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 its ADMD.6. IANA Considerations
IANA has registered the defined header field and created tables as described below. These registry actions were originally defined by [RFC5451] and updated by [RFC6577] and [RFC7001]. The created registries are being further updated here to increase their completeness.6.1. The Authentication-Results Header Field
[RFC5451] added the Authentication-Results header field to the IANA "Permanent Message Header Field Names" registry, per the procedure found in [IANA-HEADERS]. That entry has been updated to reference this document. The following is the registration template:
Header field name: Authentication-Results
Applicable protocol: mail ([MAIL])
Status: Standard
Author/Change controller: IETF
Specification document(s): RFC 7601
Related information: none
6.2. "Email Authentication Methods" Registry Description
Names of message authentication methods supported by this
specification have been registered with IANA, with the exception of
experimental names as described in Section 2.7.6. Along with each
method is recorded the properties that accompany the method's result.
The "Email Authentication Parameters" group, and within it the "Email
Authentication Methods" registry, were created by [RFC5451] for this
purpose. [RFC6577] added a "status" field for each entry. [RFC7001]
amended the rules governing that registry and also added a "version"
field to the registry.
The reference for that registry has been updated to reference this
document.
New entries are assigned only for values that have received Expert
Review, per [IANA-CONSIDERATIONS]. The designated expert shall be
appointed by the IESG. The designated expert has discretion to
request that a publication be referenced if a clear, concise
definition of the authentication method cannot be provided such that
interoperability is assured. Registrations should otherwise be
permitted. The designated expert can also handle requests to mark
any current registration as "deprecated".
No two entries can have the same combination of method, ptype, and
property.
An entry in this registry contains the following:
Method: the name of the method.
Definition: a reference to the document that created this entry, if
any (see below).
ptype: a "ptype" value appropriate for use with that method.
property: a "property" value matching that "ptype" also appropriate
for use with that method.
Value: a brief description of the value to be supplied with that
method/ptype/property tuple.
Status: the status of this entry, which is either:
active: The entry is in current use.
deprecated: The entry is no longer in current use.
Version: a version number associated with the method (preferably
starting at "1").
The "Definition" field will typically refer to a permanent document,
or at least some descriptive text, where additional information about
the entry being added can be found. This might in turn reference the
document where the method is defined so that all of the semantics
around creating or interpreting an Authentication-Results header
field using this method, ptype, and property can be understood.
6.3. "Email Authentication Methods" Registry Update
The following changes have been made to this registry per this
document:
1. The "Defined" field has been renamed "Definition", to be
consistent with the other registries in this group.
2. The entry for the "dkim" method, "header" ptype, and "b" property
now reference [RFC6008] as the defining document, and the
reference has be removed from the description.
3. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf"
method entries have had their "Definition" fields changed to
refer to this document, as this document contains a complete
description of the registry and these corresponding values.
4. All "smime" entries have had their "Definition" fields changed to
[SMIME-REG].
5. The "value" field of the "smime" entry using property "smime-
part" has been changed to read: "The MIME body part reference
that contains the S/MIME signature. See Section 3.2.1 of RFC
7281 for full syntax."
6. The single entry for the "auth" method was intended to reflect
the identity indicated by the "AUTH" parameter to the SMTP "MAIL
FROM" command verb. However, there is also an "AUTH" command
verb. To clarify this ambiguity, the entry for the "auth" method
has had its "property" field changed to "mailfrom", and its
"Definition" field changed to this document.
7. The following entry has been added:
Method: auth
Definition: this document (RFC 7601)
ptype: smtp
property: auth
Value: identity confirmed by the AUTH command
Status: active
Version: 1
8. The values of the "domainkeys" entries for ptype "header" have
been updated as follows:
from: contents of the [MAIL] From: header field, after removing
comments, and removing the local-part and following "@" if not
authenticated
sender: contents of the [MAIL] Sender: header field, after
removing comments, and removing the local-part and following
"@" if not authenticated
9. For all entries for "dkim-adsp" and "domainkeys", their Status
values have been changed to "deprecated", reflecting the fact
that the corresponding specifications now have Historic status.
Their "Definition" fields have also been modified to include a
reference to this document.
6.4. "Email Authentication Property Types" Registry
[RFC7410] created the "Email Authentication Property Types" 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.
As this is a complete restatement of the definition and rules for
this registry, IANA has updated 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. References to
[RFC7001] and [RFC7410] have been removed.
6.5. "Email Authentication Result Names" Description
Names of message authentication result codes supported by this
specification must be registered with IANA, with the exception of
experimental codes as described in Section 2.7.7. A registry was
created by [RFC5451] for this purpose. [RFC6577] added the "status"
column and [RFC7001] updated the rules governing that registry.
New entries are assigned only for values that have received Expert
Review, per [IANA-CONSIDERATIONS]. The designated expert shall be
appointed by the IESG. The designated expert has discretion to
request that a publication be referenced if a clear, concise
definition of the authentication result cannot be provided such that
interoperability is assured. Registrations should otherwise be
permitted. The designated expert can also handle requests to mark
any current registration as "deprecated".
No two entries can have the same combination of method and code.
An entry in this registry contains the following:
Auth Method: an authentication method for which results are being
returned using the header field defined in this document.
Code: a result code that can be returned for this authentication
method.
Specification: either free form text explaining the meaning of this
method-code combination, or a reference to such a definition.
Status: the status of this entry, which is either:
active: The entry is in current use.
deprecated: The entry is no longer in current use.
6.6. "Email Authentication Result Names" Update
This document includes a complete description of the registry,
obsoleting [RFC7001]. Accordingly, the following changes have been
made to this registry per this document:
o The "Defined" field has been removed.
o The "Meaning" field has been renamed "Specification", as described
above.
o The "Auth Method" field now appears before the "Code" field.
o For easier searching, the table has been arranged such that it is
sorted first by Auth Method, then by Code within each Auth Method
grouping.
o All entries for the "dkim", "domainkeys", "spf", "sender-id",
"auth", and "iprev" methods have had their "Specification" fields
replaced as follows:
dkim: Section 2.7.1 of this document (RFC 7601)
domainkeys: Section 2.7.1 of this document (RFC 7601)
spf: for "hardfail", Section 2.4.2 of [RFC5451]; for all others,
Section 2.7.2 of this document (RFC 7601)
sender-id: for "hardfail", Section 2.4.2 of [RFC5451]; for all
others, Section 2.7.2 of this document (RFC 7601)
auth: Section 2.7.4 of this document (RFC 7601)
iprev: Section 2.7.3 of this document (RFC 7601)
o All entries for "dkim-adsp" that were missing an explicit
reference to a defining document now reference [ADSP] in their
"Specification" fields.
o All entries for "dmarc" have had their "Specification" fields
changed to reference Section 11.2 of [DMARC].
o All entries for "dkim-adsp" and "domainkeys" have had their Status
values changed to "deprecated", reflecting the fact that the
corresponding specifications now have Historic status. Their
"Specification" fields have also been modified to include a
reference to this document.
6.7. SMTP Enhanced Status Codes
The entry for X.7.25 in the "Enumerated Status Codes" sub-registry of
the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes
Registry" has been updated to refer to this document instead of
[RFC7001].
7. Security Considerations
The following security considerations apply when adding or processing
the Authentication-Results header field:
7.1. Forged Header Fields
An MUA or filter that accesses a mailbox whose messages are handled
by a non-conformant MTA, and understands Authentication-Results
header fields, could potentially make false conclusions based on
forged header fields. A malicious user or agent could forge a header
field using the DNS domain of a receiving ADMD as the authserv-id
token in the value of the header field and, with the rest of the
value, claim that the message was properly authenticated. The non-
conformant MTA would fail to strip the forged header field, and the
MUA could inappropriately trust it.
For this reason, it is best not to have processing of the
Authentication-Results header field enabled by default; instead, it
should be ignored, at least for the purposes of enacting filtering
decisions, unless specifically enabled by the user or administrator
after verifying that the border MTA is compliant. It is acceptable
to have an MUA aware of this specification but have an explicit list
of hostnames whose Authentication-Results header fields are
trustworthy; however, this list should initially be empty.
Proposed alternative solutions to this problem were made some time
ago and are listed below. To date, they have not been developed due
to lack of demand but are documented here should the information be
useful at some point in the future:
1. Possibly the simplest is a digital signature protecting the
header field, such as using [DKIM], that can be verified by an
MUA by using a posted public key. Although one of the main
purposes of this document is to relieve the burden of doing
message authentication work at the MUA, this only requires that
the MUA learn a single authentication scheme even if a number of
them are in use at the border MTA. Note that [DKIM] requires
that the From header field be signed, although in this
application, the signing agent (a trusted MTA) likely cannot
authenticate that value, so the fact that it is signed should be
ignored. Where the authserv-id is the ADMD's domain name, the
authserv-id matching this valid internal signature's "d=" DKIM
value is sufficient.
2. Another would be a means to interrogate the MTA that added the
header field to see if it is actually providing any message
authentication services and saw the message in question, but this
isn't especially palatable given the work required to craft and
implement such a scheme.
3. Yet another might be a method to interrogate the internal MTAs
that apparently handled the message (based on Received header
fields) to determine whether any of them conform to Section 5 of
this memo. This, too, has potentially high barriers to entry.
4. Extensions to [IMAP], [SMTP], and [POP3] could be defined to
allow an MUA or filtering agent to acquire the authserv-id in use
within an ADMD, thus allowing it to identify which
Authentication-Results header fields it can trust.
5. On the presumption that internal MTAs are fully compliant with
Section 3.6 of [MAIL] and the compliant internal MTAs are using
their own hostnames or the ADMD's DNS domain name as the
authserv-id token, the header field proposed here should always
appear above a Received header added by a trusted MTA. This can
be used as a test for header field validity.
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
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
this delivery. Given the variety of messaging environments deployed
today, consensus appears to be that specifying a particular mechanism
for doing so is not appropriate for this document.
Mitigation of the forged header field attack can also be accomplished by moving the authentication results data into metadata associated with the message. In particular, an [SMTP] extension could be established to communicate authentication results from the border MTA to intermediate and delivery MTAs; the latter of these could arrange to store the authentication results as metadata retrieved and rendered along with the message by an [IMAP] client aware of a similar extension in that protocol. The delivery MTA would be told 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 is no vector in such an arrangement for forgery of authentication data by an outside agent.7.2. Misleading Results
Until some form of service for querying the reputation of a sending agent is widely deployed, the existence of this header field indicating a "pass" does not render the message trustworthy. It is possible for an arriving piece of spam or other undesirable mail to pass checks by several of the methods enumerated above (e.g., a piece of spam signed using [DKIM] by the originator of the spam, which might be a spammer or a compromised system). In particular, this issue is not resolved by forged header field removal discussed above. Hence, MUAs and downstream filters must take some care with use of this header even after possibly malicious headers are scrubbed.7.3. Header Field Position
Despite the requirements of [MAIL], header fields can sometimes be reordered en route by intermediate MTAs. The goal of requiring header field addition only at the top of a message is an acknowledgment that some MTAs do reorder header fields, but most do not. Thus, in the general case, there will be some indication of which MTAs (if any) handled the message after the addition of the header field defined here.7.4. Reverse IP Query Denial-of-Service Attacks
Section 4.6.4 of [SPF] describes a DNS-based denial-of-service attack for verifiers that attempt DNS-based identity verification of arriving client connections. A verifier wishing to do this check and report this information needs to take care not to go to unbounded lengths to resolve "A" and "PTR" queries. MUAs or other filters 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, especially, its limitations.
7.5. Mitigation of Backscatter
Failing to follow the instructions of Section 4.2 can result in a denial-of-service attack caused by the generation of [DSN] messages (or equivalent) to addresses that did not send the messages being rejected.7.6. Internal MTA Lists
Section 5 describes a procedure for scrubbing header fields that may contain forged authentication results about a message. A compliant installation will have to include, at each MTA, a list of other MTAs known to be compliant and trustworthy. Failing to keep this list current as internal infrastructure changes may expose an ADMD to attack.7.7. Attacks against Authentication Methods
If an attack becomes known against an authentication method, clearly then the agent verifying that method can be fooled into thinking an inauthentic message is authentic, and thus the value of this header field can be misleading. It follows that any attack against the authentication methods supported by this document is also a security consideration here.7.8. Intentionally Malformed Header Fields
It is possible for an attacker to add an Authentication-Results header field that is extraordinarily large or otherwise malformed in an attempt to discover or exploit weaknesses in header field parsing code. Implementers must thoroughly verify all such header fields received from MTAs and be robust against intentionally as well as unintentionally malformed header fields.7.9. Compromised Internal Hosts
An internal MUA or MTA that has been compromised could generate mail with a forged From header field and a forged Authentication-Results header field that endorses it. Although it is clearly a larger concern to have compromised internal machines than it is to prove the value of this header field, this risk can be mitigated by arranging that internal MTAs will remove this header field if it claims to have been added by a trusted border MTA (as described above), yet the [SMTP] connection is not coming from an internal machine known to be running an authorized MTA. However, in such a configuration, legitimate MTAs will have to add this header field when legitimate internal-only messages are generated. This is also covered in Section 5.
7.10. Encapsulated Instances
MIME messages can contain attachments of type "message/rfc822", which contain other messages. Such an encapsulated message can also contain an Authentication-Results header field. Although the processing of these is outside of the intended scope of this document (see Section 1.3), some early guidance to MUA developers is appropriate here. Since MTAs are unlikely to strip Authentication-Results header fields after mailbox delivery, MUAs are advised in Section 4.1 to ignore such instances within MIME attachments. Moreover, when extracting a message digest to separate mail store messages or other media, such header fields should be removed so that they will never be interpreted improperly by MUAs that might later consume them.7.11. Reverse Mapping
Although Section 3 of this memo includes explicit support for the "iprev" method, its value as an authentication mechanism is limited. Implementers of both this proposal and agents that use the data it relays are encouraged to become familiar with the issues raised by [DNSOP-REVERSE] when deciding whether or not to include support for "iprev".8. References
8.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.8.2. Informative References
[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617, August 2009, <http://www.rfc-editor.org/info/rfc5617>. [AR-VBR] Kucherawy, M., "Authentication-Results Registration for Vouch by Reference Results", RFC 6212, DOI 10.17487/RFC6212, April 2011, <http://www.rfc-editor.org/info/rfc6212>. [ATPS] Kucherawy, M., "DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures", RFC 6541, DOI 10.17487/RFC6541, February 2012, <http://www.rfc-editor.org/info/rfc6541>. [AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, <http://www.rfc-editor.org/info/rfc4954>. [AUTH-ESC] Kucherawy, M., "Email Authentication Status Codes", RFC 7372, DOI 10.17487/RFC7372, September 2014, <http://www.rfc-editor.org/info/rfc7372>. [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <http://www.rfc-editor.org/info/rfc6376>. [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <http://www.rfc-editor.org/info/rfc7489>.
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>. [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, DOI 10.17487/RFC3596, October 2003, <http://www.rfc-editor.org/info/rfc3596>. [DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for the use of DNS Reverse Mapping", Work in Progress, draft-ietf-dnsop- reverse-mapping-considerations-06, March 2008. [DOMAINKEYS] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, DOI 10.17487/RFC4870, May 2007, <http://www.rfc-editor.org/info/rfc4870>. [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, <http://www.rfc-editor.org/info/rfc3464>. [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>. [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>. [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, <http://www.rfc-editor.org/info/rfc1939>. [PRA] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006, <http://www.rfc-editor.org/info/rfc4407>.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, DOI 10.17487/RFC5451, April 2009, <http://www.rfc-editor.org/info/rfc5451>. [RFC6008] Kucherawy, M., "Authentication-Results Registration for Differentiating among Cryptographic Results", RFC 6008, DOI 10.17487/RFC6008, September 2010, <http://www.rfc-editor.org/info/rfc6008>. [RFC6577] Kucherawy, M., "Authentication-Results Registration Update for Sender Policy Framework (SPF) Results", RFC 6577, DOI 10.17487/RFC6577, March 2012, <http://www.rfc-editor.org/info/rfc6577>. [RFC7001] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, DOI 10.17487/RFC7001, September 2013, <http://www.rfc-editor.org/info/rfc7001>. [RFC7410] Kucherawy, M., "A Property Types Registry for the Authentication-Results Header Field", RFC 7410, DOI 10.17487/RFC7410, December 2014, <http://www.rfc-editor.org/info/rfc7410>. [RRVS] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- Since Header Field and SMTP Service Extension", RFC 7293, DOI 10.17487/RFC7293, July 2014, <http://www.rfc-editor.org/info/rfc7293>. [SECURITY] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <http://www.rfc-editor.org/info/rfc3552>. [SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, DOI 10.17487/RFC4406, April 2006, <http://www.rfc-editor.org/info/rfc4406>. [SMIME-REG] Melnikov, A., "Authentication-Results Registration for S/MIME Signature Verification", RFC 7281, DOI 10.17487/RFC7281, June 2014, <http://www.rfc-editor.org/info/rfc7281>.
[SPF] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <http://www.rfc-editor.org/info/rfc7208>. [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009, <http://www.rfc-editor.org/info/rfc5518>.
(next page on part 3)
