Proposed diffs from the -16 draft, based on this discussion so far, are
attached.
Comments?
@@ -72,6 +72,7 @@
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.4. Trust Environment . . . . . . . . . . . . . . . . . . . . 6
2. Definition and Format of the Header . . . . . . . . . . . . . 7
2.1. General Description . . . . . . . . . . . . . . . . . . . 7
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 7
+1.4. Trust Environment
+ This new header field permits one or more message validation
+ mechanisms to communicate its output to one or more separate
+ assessment mechanisms. These mechanisms operate within a unified
+ trust boundary that defines an Administrative Management Domain
+ (ADMD). An ADMD contains one or more entities that perform
+ validation and generate the header field, and one or more that
+ consume it for some type of assessment. The field contains no
+ integrity or validation mechanism of its own, so its presence must be
+ trusted implicitly. Hence, use of the header field depends upon
+ ensuring that mail entering the ADMD has instances of the header
+ field claiming to be valid within this domain removed, so that
+ occurrences of such header fields can be trusted by consumers.
+ The "authserv-id" token defined in Section 2.2 can be used to label
+ an entire ADMD or a specific validation engine with an ADMD. The
+ labeling scheme is left as an operational choice.
@@ -518,7 +518,7 @@
The authentication identifier field provides a unique identifier that
refers to the authenticating service within a given mail
- administrative domain. The uniqueness of the identifier is
+ administrative domain. The uniqueness of the identifier MUST be
guaranteed by the mail administrative domain that generates it and
must pertain to exactly that one mail administrative domain. This
identifier is intended to be machine-readable and not necessarily
@@ -758,7 +758,7 @@
2.4.6. Extension Result Codes
- Additional result codes (extension results) may be defined in the
+ Additional result codes (extension results) might be defined in the
future by later revisions or extensions to this specification.
Extension results beginning with "x-" will never be defined as
standard fields; such names are reserved for experimental use.
@@ -983,6 +983,14 @@
authentication schemes were applied prior to delivery of this
message.
+ An MTA adding this header field must take steps to identify it as
+ legitimate to the MUAs that will ultimately consume its content. One
+ required process to do so is described in Section 5. Further
+ measures may be required in some environments. Some possible
+ solutions are enumerated in Section 8.1. This memo does not mandate
+ any specific solution to this issue as each environment has its own
+ facilities and limitations.
+
4.1. Header Position and Interpretation
In order to ensure non-ambiguous results and avoid the impact of
@@ -1408,15 +1464,15 @@
8.1. Forged Headers
- An MUA that accesses a mailbox whose mail is 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 destination MX for a receiving domain as the hostname token in
- the value of the header, 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.
+ An MUA or filter that accesses a mailbox whose mail is 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 destination MX for a receiving domain 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.
It is for this reason an MUA should not have processing of the
"Authentication-Results" header field enabled by default; instead it
@@ -1427,15 +1483,49 @@
of hostnames whose "Authentication-Results" header fields are
trustworthy; however, this list should initially be empty.
- Proposed alternate solutions to this problem are nascent. Possibly
- the simplest is a digital signature on the header field that can be
- verified by a posted public key. 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. In either
- case, a mechanism needs to exist 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.
+ Proposed alternate solutions to this problem are nascent:
+
+ 1. Possibly the simplest is a digital signature protecting the
+ header field, such as using [DKIM], that can be verified by an
+ MUA using by a posted public key. Although one of the main
+ purposes of this memo 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.
+
+ 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
+ which 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 high barriers-to-entry.
+
+
+
+
+
+Kucherawy Expires April 12, 2009 [Page 27]
+
+Internet-Draft Authentication-Results Header October 2008
+
+
+ 4. On the presumption that internal MTAs are fully compilant with
+ [MAIL], and the compliant internal MTAs are using their own
+ hostnames as the "authserv-id" token, the header field proposed
+ here will always appear adjacent to a Received: header bearing
+ the same name. This can be used as a test for header field
+ validity.
+
+ 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 memo.
8.2. Misleading Results
@@ -1585,8 +1697,8 @@
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
- [MAIL] Resnick, P., "Internet Message Format", RFC 2822,
- April 2001.
+ [MAIL] Resnick, P., "Internet Message Format", RFC 5322,
+ October 2008.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
@@ -1631,8 +1743,7 @@
[IANA-CONSIDERATIONS]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", RFC 5226,
- October 1998.
+ IANA Considerations Section in RFCs", RFC 5226, May 2008.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003.
@@ -1641,8 +1752,8 @@
Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006.
- [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
- April 2001.
+ [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+ October 2008.
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html