tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7601


Message Header Field for Indicating Message Authentication Status

Part 2 of 3, p. 22 to 41
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 22 
3.  The "iprev" Authentication Method

   This section defines an additional authentication method called

   "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

   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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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

   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      Up      ToC       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

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      Up      ToC       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

   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

   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      Up      ToC       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

   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

   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      Up      ToC       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      Up      ToC       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

Top      Up      ToC       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

   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

   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      Up      ToC       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

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      Up      ToC       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      Up      ToC       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      Up      ToC       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

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

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      Up      ToC       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

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,

              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      Up      ToC       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,

              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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part