Hi Murray,
At 16:55 31-05-2007, Murray S. Kucherawy wrote:
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.
Some parts of my comments were a rewording.
The above suggestion adds the words "trust domain" as the new header
should only be used to a filter if it trusts the host that added it.
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"?
We can use "MUST NOT" if we do not want implementors to make any
determination based on ordering.
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?
Yes, I reworded your text.
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?
It was a rewording of the last sentence.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html