mail-vet-discuss
[Top] [All Lists]

Re: [mail-vet-discuss] Last Call: draft-kucherawy-sender-auth-header (Message Header Field for Indicating Message Authentication Status) to Proposed Standard

2008-11-23 16:49:50

Dave Crocker forwarded the below to a list we are on:

    From: The IESG <iesg-secretary(_at_)ietf(_dot_)org>
    To: IETF-Announce <ietf-announce(_at_)ietf(_dot_)org>

    - 'Message Header Field for Indicating Message Authentication Status '
        <draft-kucherawy-sender-auth-header-17.txt> as a Proposed Standard

    The IESG plans to make a decision in the next few weeks, and solicits
    final comments on this action.  Please send substantive comments to the
    ietf(_at_)ietf(_dot_)org mailing lists by 2008-12-02.

I've not previously looked at this in detail, so please pardon my lack
of historical perspective. In reading the draft, I have two primary
concerns. In this message (to avoid thread confusion) I'd like to tackle
just the first one (which I consider to be the most significant):

Section 2.3 defines the semantics of the "authserv-id" element.

    * It is expected to be a domain-name, or at least syntactically
      like a domain-name.

    * It is required to be a unique identifier for the "authenticating
      service" within a given ADMD.

    * MUAs use this identifier to determine whether a particular instance
      of the "Authentication-Result" header is trusted.

it goes on to say:

   For tracing and debugging purposes, the authentication identifier
   SHOULD be the hostname of the MTA performing the authentication check
   whose result is being reported.

this is re-enforced just above section 4.1:

   For MTAs that add this header field, adding header fields in order
   (at the top) per [MAIL] section 3.6.7 is particularly important.
   Furthermore, MTAs SHOULD use their own hostnames as the authserv-id
   token as well as the same value in Received header fields.  This
   allows easy detection of header fields that can be trusted.

then in 8.1:

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

but, in contrast, "alternative solution" 4 of 8.1:

   4.  Extensions to [IMAP], [SMTP] and [POP3] could be defined which
       allow an MUA or filtering agent to acquire the "authserv-id" in
                                                  --------------------
       use within an administrative domain, thus allowing it to identify
       -----------------------------------
       which Authentication-Results header fields it can trust.

So, on the one hand, the draft strongly suggests that each MTA in a
multi-MTA environment should generate a unique (per-host) "authserv-id",
and suggests that MUAs somehow keep a current list of suitably trusted
MTAs. On the other hand as afterthought in "alternative solution" 4,
we see a reference to *the* "authserv-id" in use within and ADMD.

Is there a consensus about whether the "authserv-id" is a single id for
the whole ADMD, or a unique id for each MTA? If not, why the SHOULD in
Section 2.3?

If the "alternative 4" is just a hypothetical scenario, and uniqueness
per-MTA is to be taken seriously, it should be noted that only will MUAs
need to compare the "authserv-id" against the current list of active MTAs
in an ADMD, but when reading long-ago delivered mail, MUAs will need to
known which MTAs were trusted at the time the message was in transit.

I am at a loss to see how one can in practice keep tens of thousands of
installed MUAs configured correctly with the full history of the trusted
MTA set.

While we are looking at the above excerpts, it should I think be made
clear the "Authentication-Result" should go not *only* above headers
received from the previous hop, but also above locally added "Received:"
headers, and in 8.1 "alternative 5" the phrase "adjacent to" should be
"above".

Speaking of "Received" headers in C.4 the names of the "from <host>"
and "by <host>" parts of the relevant Received header are accidentally
reversed.

--  
        Viktor.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html 

<Prev in Thread] Current Thread [Next in Thread>