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

Re: [mail-vet-discuss] New draft for review

2007-05-25 16:01:41
At 11:58 19-05-2007, Murray S. Kucherawy 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.

   4.  Convey the results of sender authentication tests to later
       filtering agents within the same "trust domain", as such agents
       might apply more or less stringent checks based on sender
       authentication results.

The above change would cover this as well.

   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.

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.

   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.


   An MTA adding this header in either form MUST use its own hostname
   only.  It MUST be a fully-qualified domain name.

The hostname used in this header MUST be the fully-qualified domain name of the host where the header is added.

5.1.  Legacy MUAs

   Implementors of this proposal should be aware that many MUAs are
   unlikely to be retrofit to support the new header and its semantics.

Implementors of this proposal should be aware that many MUAs are unlikely to be retrofitted to support the new header and its semantics.

   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.

   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.

Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] Current Thread [Next in Thread>