Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7601

Message Header Field for Indicating Message Authentication Status

Pages: 53
Obsoletes:  70017410
Obsoleted by:  8601
Part 3 of 3 – Pages 42 to 53
First   Prev   None

Top   ToC   RFC7601 - Page 42   prevText

Appendix A. Legacy MUAs

Implementers of this protocol should be aware that many MUAs are unlikely to be retrofitted to support the new header field and its semantics. In the interests of convenience and quicker adoption, a delivery MTA might want to consider adding things that are processed by existing MUAs in addition to the Authentication-Results header field. One suggestion is to include a Priority header field, on messages that don't already have such a header field, containing a value that reflects the strength of the authentication that was accomplished, e.g., "low" for weak or no authentication, "normal" or "high" for good or strong authentication. Some modern MUAs can already filter based on the content of this header field. However, there is keen interest in having MUAs make some kind of graphical representation of this header field's meaning to end users. Until this capability is added (i.e., while this proposal and its successors are being adopted), other interim means of conveying authentication results may be necessary.

Appendix B. Authentication-Results Examples

This section presents some examples of the use of this header field to indicate authentication results.

B.1. Trivial Case; Header Field Not Present

The trivial case: Received: from mail-router.example.com (mail-router.example.com [192.0.2.1]) by server.example.org (8.11.6/8.11.6) with ESMTP id g1G0r1kA003489; Fri, Feb 15 2002 17:19:07 -0800 From: sender@example.com Date: Fri, Feb 15 2002 16:54:30 -0800 To: receiver@example.org Message-Id: <12345.abc@example.com> Subject: here's a sample Hello! Goodbye! Example 1: Trivial Case
Top   ToC   RFC7601 - Page 43
   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.

B.2. Nearly Trivial Case; Service Provided, but No Authentication Done

A message that was delivered by an MTA that conforms to this specification but provides no actual message authentication service: Authentication-Results: example.org 1; none Received: from mail-router.example.com (mail-router.example.com [192.0.2.1]) by server.example.org (8.11.6/8.11.6) with ESMTP id g1G0r1kA003489; Fri, Feb 15 2002 17:19:07 -0800 From: sender@example.com Date: Fri, Feb 15 2002 16:54:30 -0800 To: receiver@example.org Message-Id: <12345.abc@example.com> Subject: here's a sample Hello! Goodbye! Example 2: Header Present but No Authentication Done The Authentication-Results header field is present, showing that the delivering MTA conforms to this specification. It used its DNS domain name as the authserv-id. The presence of "none" (and the absence of any method or result tokens) indicates that no message authentication was done. The version number of the specification to which the field's content conforms is explicitly provided.
Top   ToC   RFC7601 - Page 44

B.3. Service Provided, Authentication Done

A message that was delivered by an MTA that conforms to this specification and applied some message authentication: Authentication-Results: example.com; spf=pass smtp.mailfrom=example.net Received: from dialup-1-2-3-4.example.net (dialup-1-2-3-4.example.net [192.0.2.200]) by mail-router.example.com (8.11.6/8.11.6) with ESMTP id g1G0r1kA003489; Fri, Feb 15 2002 17:19:07 -0800 From: sender@example.net Date: Fri, Feb 15 2002 16:54:30 -0800 To: receiver@example.com Message-Id: <12345.abc@example.net> Subject: here's a sample Hello! Goodbye! Example 3: Header Reporting Results The Authentication-Results header field is present, indicating that the border MTA conforms to this specification. The authserv-id is once again the DNS domain name. Furthermore, the message was authenticated by that MTA via the method specified in [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.
Top   ToC   RFC7601 - Page 45

B.4. Service Provided, Several Authentications Done, Single MTA

A message that was relayed inbound via a single MTA that conforms to this specification and applied three different message authentication checks: Authentication-Results: example.com; auth=pass (cram-md5) smtp.auth=sender@example.net; spf=pass smtp.mailfrom=example.net Authentication-Results: example.com; sender-id=pass header.from=example.net Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6) (dialup-1-2-3-4.example.net [192.0.2.200]) by mail-router.example.com (8.11.6/8.11.6) with ESMTPA id g1G0r1kA003489; Fri, Feb 15 2002 17:19:07 -0800 Date: Fri, Feb 15 2002 16:54:30 -0800 To: receiver@example.com From: sender@example.net Message-Id: <12345.abc@example.net> Subject: here's a sample Hello! Goodbye! Example 4: Headers Reporting Results from One MTA The Authentication-Results header field is present, indicating that the delivering MTA conforms to this specification. Once again, the receiving DNS domain name is used as the authserv-id. Furthermore, the sender authenticated herself/himself to the MTA via a method specified in [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.
Top   ToC   RFC7601 - Page 46

B.5. Service Provided, Several Authentications Done, Different MTAs

A message that was relayed inbound by two different MTAs that conform to this specification and applied multiple message authentication checks: Authentication-Results: example.com; sender-id=fail header.from=example.com; dkim=pass (good signature) header.d=example.com Received: from mail-router.example.com (mail-router.example.com [192.0.2.1]) by auth-checker.example.com (8.11.6/8.11.6) with ESMTP id i7PK0sH7021929; Fri, Feb 15 2002 17:19:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; t=1188964191; c=simple/simple; h=From:Date:To:Subject: Message-Id:Authentication-Results; bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= Authentication-Results: example.com; auth=pass (cram-md5) smtp.auth=sender@example.com; spf=fail smtp.mailfrom=example.com Received: from dialup-1-2-3-4.example.net (dialup-1-2-3-4.example.net [192.0.2.200]) by mail-router.example.com (8.11.6/8.11.6) with ESMTPA id g1G0r1kA003489; Fri, Feb 15 2002 17:19:07 -0800 From: sender@example.com Date: Fri, Feb 15 2002 16:54:30 -0800 To: receiver@example.com Message-Id: <12345.abc@example.com> Subject: here's a sample Hello! Goodbye! Example 5: Headers Reporting Results from Multiple MTAs The Authentication-Results header field is present, indicating conformance to this specification. Once again, the authserv-id used is the recipient's DNS domain name. The header field is present twice because two different MTAs in the chain of delivery did authentication tests. The first MTA, mail-router.example.com, reports that SMTP AUTH and SPF were both used and that the former passed while the latter failed. In the SMTP AUTH case, additional information is provided in the comment field, which the MUA can choose to render if desired.
Top   ToC   RFC7601 - Page 47
   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.
Top   ToC   RFC7601 - Page 48

B.6. Service Provided, Multi-tiered Authentication Done

A message that had authentication done at various stages, one of which was outside the receiving ADMD: Authentication-Results: example.com; dkim=pass reason="good signature" header.i=@mail-router.example.net; dkim=fail reason="bad signature" header.i=@newyork.example.com Received: from mail-router.example.net (mail-router.example.net [192.0.2.250]) by chicago.example.com (8.11.6/8.11.6) for <recipient@chicago.example.com> with ESMTP id i7PK0sH7021929; Fri, Feb 15 2002 17:19:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; s=furble; d=mail-router.example.net; t=1188964198; c=relaxed/simple; h=From:Date:To:Message-Id:Subject:Authentication-Results; bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=; b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= Authentication-Results: example.net; dkim=pass (good signature) header.i=@newyork.example.com Received: from smtp.newyork.example.com (smtp.newyork.example.com [192.0.2.220]) by mail-router.example.net (8.11.6/8.11.6) with ESMTP id g1G0r1kA003489; Fri, Feb 15 2002 17:19:07 -0800 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=newyork.example.com; t=1188964191; c=simple/simple; h=From:Date:To:Message-Id:Subject; bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= From: sender@newyork.example.com Date: Fri, Feb 15 2002 16:54:30 -0800 To: meetings@example.net Message-Id: <12345.abc@newyork.example.com> Subject: here's a sample Example 6: Headers Reporting Results from Multiple MTAs in Different ADMDs In this example, we see multi-tiered authentication with an extended trust boundary.
Top   ToC   RFC7601 - Page 49
   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,
   meetings@example.net 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.

B.7. Comment-Heavy Example

The formal syntax permits comments within the content in a number of places. For the sake of illustration, this example is also legal: Authentication-Results: foo.example.net (foobar) 1 (baz); dkim (Because I like it) / 1 (One yay) = (wait for it) fail policy (A dot can go here) . (like that) expired (this surprised me) = (as I wasn't expecting it) 1362471462 Example 7: A Very Comment-Heavy but Perfectly Legal Example
Top   ToC   RFC7601 - Page 50

Appendix C. Operational Considerations about Message Authentication

This protocol is predicated on the idea that authentication (and presumably in the future, reputation) work is typically done by border MTAs rather than MUAs or intermediate MTAs; the latter merely make use of the results determined by the former. Certainly this is not mandatory for participation in electronic mail or message authentication, but this protocol and its deployment to date are based on that model. The assumption satisfies several common ADMD requirements: 1. Service operators prefer to resolve the handling of problem messages as close to the border of the ADMD as possible. This enables, for example, rejection of messages at the SMTP level rather than generating a DSN internally. Thus, doing any of the authentication or reputation work exclusively at the MUA or intermediate MTA renders this desire unattainable. 2. Border MTAs are more likely to have direct access to external sources of authentication or reputation information since modern MUAs are more likely to be heavily firewalled. Thus, some MUAs might not even be able to complete the task of performing authentication or reputation evaluations without complex proxy configurations or similar burdens. 3. MUAs rely upon the upstream MTAs within their trust boundaries to make correct (as much as is possible) evaluations about the message's envelope, header, and content. Thus, MUAs don't need to know how to do the work that upstream MTAs do; they only need the results of that work. 4. Evaluations about the quality of a message, from simple token matching (e.g., a list of preferred DNS domains) to cryptanalysis (e.g., public/private key work), do have a cost and thus need to be minimized. To that end, performing those tests at the border MTA is far preferred to doing that work at each MUA that handles a message. If an ADMD's environment adheres to common messaging protocols, a reputation query or an authentication check performed by a border MTA would return the same result as the same query performed by an MUA. By contrast, in an environment where the MUA does the work, a message arriving for multiple recipients would thus cause authentication or reputation evaluation to be done more than once for the same message (i.e., at each MUA), causing needless amplification of resource use and creating a possible denial-of-service attack vector.
Top   ToC   RFC7601 - Page 51
   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.

Appendix D. Changes since RFC 7001

o Applied 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.
Top   ToC   RFC7601 - Page 52
   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.
Top   ToC   RFC7601 - Page 53

Acknowledgments

The author wishes to acknowledge the following individuals for their review and constructive criticism of this document: Stephane Bortzmeyer, Scott Kitterman, John Levine, Tom Petch, and Pete Resnick.

Author's Address

Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 United States Email: superuser@gmail.com