[mail-vet-discuss] Draft as of 7/17/2007

[SM]

Hi Murray,
At 15:10 17-07-2007, Murray S. Kucherawy wrote:

>    An MUA should not reveal these results to naive end users unless the
>    results are accompanied by, at a minimum, some associated reputation
>    data about the sender that was authenticated.

I suggest dropping the "naive" in that paragraph.

In Section 3, it is stated that:

    "An MTA compliant with this specification MUST add this header field
    (after performing one or more sender authentication tests)"

I assume that you mean the sending mailbox was authenticated.  If so, 
that would not cover DKIM where a signing domain claims responsibility.



>    As stated in Section 2.1, this header field SHOULD be treated as
>    though it were a trace header field as defined in section 3.6 of
>    [MAIL], and hence MUST not be reordered and MUST be prepended to the
>    message, so that there is generally some indication upon delivery of
>    where in the chain of handling MTAs the sender authentcation was
>    done.

There's a typo for "authentication".

>7.2.  Header Position
>
>    Despite the requirements of [MAIL], header fields can sometimes be
>    reordered enroute by intermediate MTAs.  The goal of requiring header
>    field addition only at the top of a message is an acknowledgement
>    that some MTAs do reorder header fields, but most do not.  Thus, in
>    the general case, there will be some indication of which MTAs (if
>    any) handled the message after the addition of the header field
>    defined here.

Although Section 3.6 of RFC 2822 mentions that headers should not be 
reordered, it does say that trace fields should be kept in 
blocks.  The first sentence of the paragraph is technically 
correct.  However, when it is viewed with the other sentences, it may 
be seen as stating that actual order of all header fields should not 
be changed according to RFC 2822.

I suggest making the examples RFC 2606 compliant.

>C.1.  Trivial case; header field not present
>
>    The trivial case:
>
>         From: sender at example.com
>         Received: from mail-router.example.com
>                       (mail-router.example.com [1.2.3.4])
>                   by server.sendmail.com (8.11.6/8.11.6)
>                       with ESMTP id g1G0r1kA003489;

          Received: from mail-router.example.com
                       (mail-router.example.com [192.0.2.4])

>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 sender authentication service:
>
>         Authentication-Results: mail-router.example.com
>         From: sender at example.com
>         Received: from mail-router.example.com
>                       (mail-router.example.com [1.2.3.4])

>         Received: from mail-router.example.com
>                       (mail-router.example.com [192.0.2.4])


>C.3.  Service provided, authentication done
>
>    A message that was delivered by an MTA that conforms to this standard
>    and applied some sender authentication:
>
>         Authentication-Results: mail-router.example.com;
>                   auth=pass (cram-md5) smtp.auth=sender at example.com
>         From: sender at example.com
>         Received: from dialup-1-2-3-4.example-isp.com
>                       (dialup-1-2-3-4.example-isp.com [1.2.3.4])

>         Received: from dialup-192-0-2-4.example.net
>                       (dialup-192-0-2-4.example.net [192.0.2.4])


>C.4.  Service provided, several authentications done, single MTA
>
>    A message that was relayed inbound via a single MTA that conforms to
>    this specification and applied three different sender authentication
>    checks:
>
>         Authentication-Results: mail-router.example.com;
>                   auth=pass (cram-md5) smtp.mail=sender at example.com;
>                   spf=pass smtp.mail=sender at example.com
>         Authentication-Results: mail-router.example.com;
>                   sender-id=pass header.from=sender at example.com
>         From: sender at example.com
>         Received: from mail-router.example.com
>                       (mail-router.example.com [1.2.3.4])
>                   by dialup-1-2-3-4.example-isp.com (8.11.6/8.11.6)

         Received: from mail-router.example.com
                       (mail-router.example.com [192.0.2.4])
                   by dialup-1-2-3-4.example.net (8.11.6/8.11.6)

>C.5.  Service provided, several authentications done, different MTAs
>
>    A message that was relayed inbound by two different MTAs that conform
>    to this specification and applied multiple sender authentication
>    checks:
>
>         Authentication-Results: auth-checker.example.com;
>                   sender-id=pass header.from=sender at example.com;
>                   dkim=pass (good signature) header.i=sender at example.com
>         Received: from mail-router.example.com
>                       (mail-router.example.com [10.11.12.13])
>                   by auth-checker.example.com (8.11.6/8.11.6)
>                       with ESMTP id i7PK0sH7021929;
>                   Fri, Feb 15 2002 17:19:22 -0800
>         Authentication-Results: mail-router.example.com;
>                   auth=pass (cram-md5) smtp.mail=sender at example.com;
>                   spf=fail smtp.mail=sender at example.com
>         Received: from dialup-1-2-3-4.example-isp.com
>                       (dialup-1-2-3-4.example-isp.com [1.2.3.4])
>                   by mail-router.example.com (8.11.6/8.11.6)
>                       with ESMTP id g1G0r1kA003489;
>                   Fri, Feb 15 2002 17:19:07 -0800

         Received: from dialup-192-0-2-4.example.net
                       (dialup-192-0-2-4.example.net [192.0.2.4])
                   by mail-router.example.com (8.11.6/8.11.6)
                       with ESMTP id g1G0r1kA003489;
                   Fri, Feb 15 2002 17:19:07 -0800

Regards,
-sm