The Authentication-Results header field is completely absent. The MUA may make no conclusion about the validity of the message. This could be the case because the message authentication services were not available at the time of delivery, or no service is provided, or the MTA is not in compliance with this specification.
SPF]. Note that since that method cannot authenticate the local-part, it has been omitted from the result's value. The MUA could extract and relay this extra information if desired.
AUTH], and both SPF and Sender ID checks were done and passed. The MUA could extract and relay this extra information if desired. Two Authentication-Results header fields are not required since the same host did all of the checking. The authenticating agent could have consolidated all the results into one header field. This example illustrates a scenario in which a remote user on a dial- up connection (example.net) sends mail to a border MTA (example.com) using SMTP authentication to prove identity. The dial-up provider has been explicitly authorized to relay mail as example.com, producing "pass" results from the SPF and Sender ID checks.
The second MTA, auth-checker.example.com, reports that it did a Sender ID test (which failed) and a DKIM test (which passed). Again, additional data about one of the tests is provided as a comment, which the MUA may choose to render. Also noteworthy here is the fact that there is a DKIM signature added by example.com that assured the integrity of the lower Authentication-Results field. Since different hosts did the two sets of authentication checks, the header fields cannot be consolidated in this example. This example illustrates more typical transmission of mail into example.com from a user on a dial-up connection example.net. The user appears to be legitimate as he/she had a valid password allowing authentication at the border MTA using SMTP AUTH. The SPF and Sender ID tests failed since example.com has not granted example.net authority to relay mail on its behalf. However, the DKIM test passed because the sending user had a private key matching one of example.com's published public keys and used it to sign the message.
The message was sent from someone at example.com's New York office (newyork.example.com) to a mailing list managed at an intermediary. The message was signed at the origin using DKIM. The message was sent to a mailing list service provider called example.net, which is used by example.com. There, firstname.lastname@example.org is expanded to a long list of recipients, one of whom is at the Chicago office. In this example, we will assume that the trust boundary for chicago.example.com includes the mailing list server at example.net. The mailing list server there first authenticated the message and affixed an Authentication-Results header field indicating such using its DNS domain name for the authserv-id. It then altered the message by affixing some footer text to the body, including some administrivia such as unsubscription instructions. Finally, the mailing list server affixes a second DKIM signature and begins distribution of the message. The border MTA for chicago.example.com explicitly trusts results from mail-router.example.net, so that header field is not removed. It performs evaluation of both signatures and determines that the first (most recent) is a "pass" but, because of the aforementioned modifications, the second is a "fail". However, the first signature included the Authentication-Results header added at mail- router.example.net that validated the second signature. Thus, indirectly, it can be determined that the authentications claimed by both signatures are indeed valid. Note that two styles of presenting metadata about the result are in use here. In one case, the "reason=" clause is present, which is intended for easy extraction by parsers; in the other case, the CFWS production of the ABNF is used to include such data as a header field comment. The latter can be harder for parsers to extract given the varied supported syntaxes of mail header fields.
5. Minimizing change is good. As new authentication and reputation methods emerge, the list of methods supported by this header field would presumably be extended. If MUAs simply consume the contents of this header field rather than actually attempt to do authentication and/or reputation work, then MUAs only need to learn to parse this header field once; emergence of new methods requires only a configuration change at the MUAs and software changes at the MTAs (which are presumably fewer in number). When choosing to implement these functions in MTAs vs. MUAs, the issues of individual flexibility, infrastructure inertia, and scale of effort must be considered. It is typically easier to change a single MUA than an MTA because the modification affects fewer users and can be pursued with less care. However, changing many MUAs is more effort than changing a smaller number of MTAs. 6. For decisions affecting message delivery and display, assessment based on authentication and reputation is best performed close to the time of message transit, as a message makes its journey toward a user's inbox, not afterwards. DKIM keys and IP address reputations, etc., can change over time or even become invalid, and users can take a long time to read a message once delivered. The value of this work thus degrades, perhaps quickly, once the delivery process has completed. This seriously diminishes the value of this work when done elsewhere than at MTAs. Many operational choices are possible within an ADMD, including the venue for performing authentication and/or reputation assessment. The current specification does not dictate any of those choices. Rather, it facilitates those cases in which information produced by one stage of analysis needs to be transported with the message to the next stage. RFC 7410. o Updated all references to RFC 4408 with RFC 7208. o Added section explaining "property" values. (Addressed Erratum #4201.) o Did some minor text reorganization. o Gave registry history -- enough that this is now the authoritative registry definition. o Added text explaining each of the method-ptype-property tuples registered by this document.
o Changed the meaning of the "Defined" column of the methods registry to be the place where each entry was created and described; it is expected that this will then refer to the method's defining document. Provided IANA with corresponding update instructions. o Cleaned up registry structure and content, and replaced all references to RFC 7001 with pointers to this document. o Added references: [DMARC], [PRA], [RFC6008], [RFC6577], [RRVS], [SMIME-REG]. o Added description of values that can be extracted from SMTP AUTH sessions and an example. o Provided much more complete descriptions of reporting DomainKeys results. o Added more detail about Sender ID. o Marked all ADSP and DomainKeys entries as deprecated since their defining documents are as well. o Reworked some text around ignoring unknown ptypes. o Completely described the ptypes registry. o Mentioned that EHLO is mapped to HELO for SPF. o RFC 7208 uses all-lowercase result strings now, so adjusted prose accordingly. o Updated list of supported methods, and mentioned the registries immediately below. o Mentioned that when a local-part is removed, the "@" goes with it. o Referred to RFC 7328 in the "iprev" definition. o Corrected the "smime-part" prose. o Updated examples that use SMTP AUTH to claim "with ESMTPA" in the Received fields. o Made minor editorial adjustments.