[mail-vet-discuss] Preview of draft-09

[SM]

At 16:11 01-11-2007, Murray S. Kucherawy wrote:
>1.2.  Requirements
>
>    This memo establishes no new requirements on existing protocols or
>    servers, as there is currently no standard place for the described
>    data to be collected or presented.

If this memo replaces the Received-SPF header, then it changes the 
requirements on an existing protocol.

>    For tracing and debugging purposes, the authentication identifier
>
>
>
>Kucherawy                  Expires May 4, 2008                  [Page 8]
>
>Internet-Draft        Authentication-Results Header        November 2007
>
>
>    SHOULD be the domain name of the MTA performing the authentication
>    check whose result is being reported.

I suggest changing that to a recommendation as follows:

   It is RECOMMENDED that the authentication identifier be the domain 
name of the MTA
   performing the authentication check to guarantee uniqueness and 
for ease of tracing and
   debugging.

That allows the implementor to choose an authentication identifier 
while providing some guidance.

>    An MUA MUST ignore any result reported using a "result" or "ptype"
>    not enumerated by this specification or a later amendment to it.

I suggest using the following text.  It covers any later amendment to 
the specification.

   A MUA MUST ignore any results reported using a "result" not 
enumerated in this
   specification or "ptype" not in the Email Authentication Method 
Name Registry.

>8.3.  Other Protocols
>
>    Mitigation of the forged header attack can also be accomplished by
>    moving the authentication results data into meta-data associated with
>    the message.  In particular, an [SMTP] extension could be established
>    which is used 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 meta-data retrieved
>    and rendered along with the message by an [IMAP] client 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.
>
>    It is the intention of the author to follow this proposal with drafts
>    proposing the above two extensions.

The last sentence could be a note to be removed at publication time 
as it doesn't pertain to this draft.

>C.2.  Nearly-trivial case; service provided, but no authentication done
>
>    A message that was delivered by an MTA that conforms to this standard
>    but provides no actual message authentication service:

Could you use "conforms to this specification" instead of "conforms 
to this standard" in the example cases (C2 and C3)?  It's not a standard yet.

Regards,
-sm