Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: DMARC

RFC 8601

Message Header Field for Indicating Message Authentication Status

Pages: 54
Proposed STD
Obsoletes:  7601
Part 3 of 4 – Pages 23 to 39
First   Prev   Next

Top   ToC   RFC8601 - Page 23   prevText
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
Top   ToC   RFC8601 - Page 24
   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.

   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.
Top   ToC   RFC8601 - Page 25
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 was
   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
   service 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 differs in that it can yield a result
   based on more than one identifier; specifically, SPF can evaluate the
   RFC5321.HELO parameter or the RFC5321.MailFrom parameter.  When
   generating this field to report those results, only the parameter
   that yielded the result is included.
Top   ToC   RFC8601 - Page 26
   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 have 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 of the
   header field is used within the ADMD as configured by the user or

   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.  The exception to this is experimental methods
   as discussed in Section 2.7.6.

   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
Top   ToC   RFC8601 - Page 27
   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

   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.  They are likely to contain the
   results of authentication checks done in the past, possibly long ago,
   and have no contemporary value.  Due caution therefore needs to be
   taken when choosing to consume them.

   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.
Top   ToC   RFC8601 - Page 28
5.  Removing Existing Header Fields

   To mitigate the impact of forged header fields, 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 internal MTA will need to be configured with a list of other
   known, trusted MTAs that are thus expected to be using that same

   In the case of EAI-formatted messages, this test is done after
   converting A-labels into U-labels.

   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 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.
Top   ToC   RFC8601 - Page 29
   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 [SMTP]
   relaying the message is not from a trusted internal MTA.  (As
   discussed above, this too can result in invalidation of signatures.)
   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 registries
   as described below.  These registry actions were originally defined
   by [RFC5451] and updated by [RFC6577] and [RFC7001].  The created
   registries were further updated in [RFC7601] to make them more

   Each registry has two related sections below.  The first describes
   the registry and its update procedures, which are unchanged from
   [RFC7601].  The second enumerates changes to entries that are
   relevant to this document.

6.1.  The Authentication-Results Header Field

   The Authentication-Results header field was added 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 8601
      Related information: none
Top   ToC   RFC8601 - Page 30
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 are recorded the properties that accompany the method's

   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.

   Value:  a brief description of the value to be supplied with that
      method/ptype/property tuple.
Top   ToC   RFC8601 - Page 31
   Status:  the status of this entry, which is one of the following:

      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 entries in this registry have been updated to replace
   [RFC7601] with this document:

     |   Method   | ptype  | Property                         |
     |    auth    |  smtp  | auth                             |
     |    auth    |  smtp  | mailfrom                         |
     |    dkim    | header | d                                |
     |    dkim    | header | i                                |
     |   iprev    | policy | iprev                            |
     |    spf     |  smtp  | mailfrom                         |
     |    spf     |  smtp  | helo                             |

   Notably, the DomainKeys and Sender ID entries are not updated to
   refer to this revised specification, as they are considered obsolete.
   Accordingly, IANA has changed the "Status" field of the "sender-id"
   entry in this table to "deprecated".
Top   ToC   RFC8601 - Page 32
   Finally, two new entries have been added to this registry, as

6.3.1.  "header.a" for DKIM

   Method:  dkim

   Definition:  RFC 8601

   ptype:  header

   Property:  a

   Value:  value of signature "a" tag

   Status:  active

   Version:  1

6.3.2.  "header.s" for DKIM

   Method:  dkim

   Definition:  RFC 8601

   ptype:  header

   Property:  s

   Value:  value of signature "s" tag

   Status:  active

   Version:  1

6.4.  "Email Authentication Property Types" Registry Description

   [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.
Top   ToC   RFC8601 - Page 33
   Description:  a brief description of what sort of information this
      "ptype" is meant to cover.

   For new entries, the designated expert needs to ensure 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.

6.5.  "Email Authentication Property Types" Registry Update

   All current entries in this registry have been updated to replace
   [RFC7601] with this document.

6.6.  "Email Authentication Result Names" Registry 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.

   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

   Specification:  either free-form text explaining the meaning of this
      method-code combination or a reference to such a definition.
Top   ToC   RFC8601 - Page 34
   Status:  the status of this entry, which is one of the following:

      active:  The entry is in current use.

      deprecated:  The entry is no longer in current use.

6.7.  "Email Authentication Result Names" Registry Update

   For the following entries in this registry, the new "Specification"
   field has been set as follows:

   o  All "auth" method result codes ("fail", "none", "pass",
      "permerror", and "temperror") are now specified in Section 2.7.4
      of this document.

   o  All "dkim" method result names ("fail", "neutral", "none", "pass",
      "permerror", "policy", and "temperror") are now specified in
      Section 2.7.1 of this document.

   o  All "iprev" method result names ("fail", "pass", "permerror", and
      "temperror") are now specified in Section 2.7.3 of this document.

   o  The "spf" method result names "fail", "neutral", "none", "pass",
      "permerror", "policy", "softfail", and "temperror" are now
      specified in Section 2.7.2 of this document.  The registration for
      result name "hardfail" is not updated.

   The following entries in this registry have been updated with a new
   "Status" field set to "deprecated", and with no change to the
   "Specification" field as they reference historic protocols:

   o  All "domainkeys" method result names ("fail", "neutral", "none",
      "pass", "permerror", "policy", and "temperror").

   o  All "sender-id" method result names ("fail", "neutral", "none",
      "pass", "permerror", "policy", "softfail", and "temperror").

6.8.  SMTP Enhanced Status Codes

   The entry for X.7.25 in the "Enumerated Status Codes" subregistry of
   the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes
   Registry" has been updated to refer only to Section 3.3 of
   [AUTH-ESC], as that is where that registration was done.
Top   ToC   RFC8601 - Page 35
7.  Security Considerations

   The following security considerations apply when adding or processing
   the Authentication-Results header field:

7.1.  Forged Header Fields

   An MTA not applying the filtering discussed in Section 5 exposes MUAs
   to 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.
Top   ToC   RFC8601 - Page 36
   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, this header field 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 [SMTP] 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 [IMAP] 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
Top   ToC   RFC8601 - Page 37
   might be a spammer or a compromised system).  In particular, this
   issue is not resolved by forged header field removal (discussed

   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] observes that limits are necessary on
   recursive evaluations of SPF records in order to avoid abuse of or
   attacks on the DNS when verifying 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
   [DSN] (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
Top   ToC   RFC8601 - Page 38
7.7.  Attacks against Authentication Methods

   If an attack against an authentication method becomes known, 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

   As with any other header field found in the message, 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 [SMTP] 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 simple guidance to MUA developers is
   appropriate here.

   Since MTAs are generally unlikely to strip Authentication-Results
   header fields during mailbox delivery, normative language exists in
   Section 4.1 cautioning MUAs to ignore such instances within MIME
   attachments, as might be included when a message is forwarded.
   Moreover, when extracting a message digest to separate mail store
Top   ToC   RFC8601 - Page 39
   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.

   There can be cases where these header fields included as part of
   encapsulated messages might actually be of value, such as when they
   are taken from messages within the same ADMD where they will be
   consumed.  Caution must be taken to ensure that the consumer fully
   understands the semantics of what the header field is indicating and
   the message's handling history before ascribing any value, positive
   or negative, to such data.

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 specification 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

(page 39 continued on part 4)

Next Section