[mail-vet-discuss] New draft for review

[Murray S. Kucherawy]

SM wrote:
>> 1.1.  Purpose
>>
>>    The header defined in this memo is expected to serve several
>>    purposes:
>>
>>    1.  Convey to MUAs from filters and MTAs the results of various
>>        sender authentication checks being applied;
>
> I suggest:
>
> For filters and MTAs within the same "trust domain" to convey the 
> results of authentication tests being performed to MUAs and other 
> filtering agents.

Is this new information or just a rewording?  I'm not sure what 
different information this imparts.

>>    This new header SHOULD be added at the top of the message as it
>>    transits MTAs which do authentication checks so that some idea of how
>>    far away the checks were done can be inferred.  It therefore also
>>    qualifies in [MAIL] [6] terms as a Trace Header Field, and thus all
>>    of the related definitions in that document apply.
>
> I suggest:
>
> This new header MUST be prepended to the message by the filter or MTA 
> performing the authentication tests so that one may infer where they 
> were carried out.

I went with SHOULD instead of MUST here because I didn't see anyplace in 
RFC2821 or RFC2822 that used MUST when describing where trace headers 
were placed, other than specifically making that a requirement for 
Received: (3.8.2 of RFC2821).  I'm fine with making that change here if 
there's no objection.

>> 4.  Adding The Header To A Message
>>
>>    This specification makes no attempt to evaluate the relative
>>    strengths of various sender authentication methods that may become
>>    available.  As such, the order of the presented authentication
>>    methods and results are not relevant since ultimately the importance
>>    on any given method over another is the decision of the MUA that is
>>    interpreting the value of the header.
>
> This specification makes no attempt to evaluate the relative merits of 
> the various sender authentication methods.  The order of presentation 
> of the methods in this header should not be used to determine the 
> importance of any given method.
Why not MUST NOT instead of "should not"?

>>    An MTA compliant with this specification MUST add this header (after
>>    performing one or more sender authentication tests) to indicate at
>>    which host the test was done, which test got applied and what the
>>    result was.  If an MTA applies more than one such test, it MUST
>>    either add this header once per test, or one header indicating all of
>>    the results.  An MTA MUST NOT add a result to an existing header.
>
> An MTA compliant with this specification MUST add this header to 
> indicate the host which performed the authentication tests, the 
> authentication methods tested and the results of the tests.  If more 
> than one test is done, the MTA MUST either add this header once per 
> test or add one header to convey all the results.  An MTA MUST NOT add 
> the result to an existing header.
Doesn't this also say the same thing?

>>    In the interests of convenience and quicker adaptation, a delivery
>>    MTA might want to consider adding things that are processed by
>>    existing MUAs as well as the header defined by this specification.
>>    One suggestion is to provide a Priority: header with 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
>>    authentication.
>
> Because of the above suggestion, the MTA or filter performing the 
> tests will have to strip out any existing Priority: header.
It's an old suggestion, possibly even a bad one, but I've added a remark 
to this effect already.

>>    MTAs that are relaying mail rather than delivering it MAY perform
>>    sender authentication or even take actions based on the results
>>    found, but MUST NOT add a "Authentication-Results" header if relaying
>>    rather than rejecting or discarding at the gateway.  Conversely, an
>>    MTA doing local delivery MUST add this header prior to delivery the
>>    message in order to be compliant.
>
> Conversely, an MTA MUST add this header prior to the delivery of the 
> message in order to be compliant.
Why that change?

-MSK