Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 7601

Message Header Field for Indicating Message Authentication Status

Pages: 53
Obsoletes:  70017410
Obsoleted by:  8601
Part 2 of 3 – Pages 22 to 41
First   Prev   Next

Top   ToC   RFC7601 - Page 22   prevText

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.
Top   ToC   RFC7601 - Page 23
   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

   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.
Top   ToC   RFC7601 - Page 24
   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
Top   ToC   RFC7601 - Page 25
   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 (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
Top   ToC   RFC7601 - Page 26
   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 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 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
Top   ToC   RFC7601 - Page 27
   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 will explicitly trust authentication results
   asserted by upstream host 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:
Top   ToC   RFC7601 - Page 28
     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.
Top   ToC   RFC7601 - Page 29
   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."
Top   ToC   RFC7601 - Page 30
   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

       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:
Top   ToC   RFC7601 - Page 31
   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.
Top   ToC   RFC7601 - Page 32
   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.
Top   ToC   RFC7601 - Page 33
   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:
Top   ToC   RFC7601 - Page 34
   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.
Top   ToC   RFC7601 - Page 35
   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.
Top   ToC   RFC7601 - Page 36

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.
Top   ToC   RFC7601 - Page 37

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, <>. [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, <>. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>. [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <>.
Top   ToC   RFC7601 - Page 38
   [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,

   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,

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, <>. [AR-VBR] Kucherawy, M., "Authentication-Results Registration for Vouch by Reference Results", RFC 6212, DOI 10.17487/RFC6212, April 2011, <>. [ATPS] Kucherawy, M., "DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures", RFC 6541, DOI 10.17487/RFC6541, February 2012, <>. [AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, <>. [AUTH-ESC] Kucherawy, M., "Email Authentication Status Codes", RFC 7372, DOI 10.17487/RFC7372, September 2014, <>. [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, <>. [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <>.
Top   ToC   RFC7601 - Page 39
   [DNS]      Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <>.

   [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,

              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.

              Delany, M., "Domain-Based Email Authentication Using
              Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
              DOI 10.17487/RFC4870, May 2007,

   [DSN]      Moore, K. and G. Vaudreuil, "An Extensible Message Format
              for Delivery Status Notifications", RFC 3464,
              DOI 10.17487/RFC3464, January 2003,

              Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,

              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,

              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,

   [POP3]     Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,

   [PRA]      Lyon, J., "Purported Responsible Address in E-Mail
              Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006,
Top   ToC   RFC7601 - Page 40
   [RFC5451]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 5451,
              DOI 10.17487/RFC5451, April 2009,

   [RFC6008]  Kucherawy, M., "Authentication-Results Registration for
              Differentiating among Cryptographic Results", RFC 6008,
              DOI 10.17487/RFC6008, September 2010,

   [RFC6577]  Kucherawy, M., "Authentication-Results Registration Update
              for Sender Policy Framework (SPF) Results", RFC 6577,
              DOI 10.17487/RFC6577, March 2012,

   [RFC7001]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 7001,
              DOI 10.17487/RFC7001, September 2013,

   [RFC7410]  Kucherawy, M., "A Property Types Registry for the
              Authentication-Results Header Field", RFC 7410,
              DOI 10.17487/RFC7410, December 2014,

   [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,

   [SECURITY] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,

   [SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
              RFC 4406, DOI 10.17487/RFC4406, April 2006,

              Melnikov, A., "Authentication-Results Registration for
              S/MIME Signature Verification", RFC 7281,
              DOI 10.17487/RFC7281, June 2014,
Top   ToC   RFC7601 - Page 41
   [SPF]      Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,

   [VBR]      Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
              Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009,

(next page on part 3)

Next Section