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

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

2007-07-23 12:40:54
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(_dot_)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(_dot_)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(_dot_)auth=sender(_at_)example(_dot_)com
        From: sender(_at_)example(_dot_)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(_dot_)mail=sender(_at_)example(_dot_)com;
                  spf=pass smtp(_dot_)mail=sender(_at_)example(_dot_)com
        Authentication-Results: mail-router.example.com;
                  sender-id=pass header(_dot_)from=sender(_at_)example(_dot_)com
        From: sender(_at_)example(_dot_)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(_dot_)from=sender(_at_)example(_dot_)com;
                  dkim=pass (good signature) 
header(_dot_)i=sender(_at_)example(_dot_)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(_dot_)mail=sender(_at_)example(_dot_)com;
                  spf=fail smtp(_dot_)mail=sender(_at_)example(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] Current Thread [Next in Thread>