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