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
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html