SM 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.
I'm not sure I agree. I can see legitimacy in the idea of an expert
mode which, if selected, does reveal the raw data.
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.
I guess we're running into a blurring between "sender" and "signer". Is
this a major point of concern? Or is it sufficient simply to define my
use of "sender" to include the "signer" case, perhaps citing DKIM as an
example?
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".
Fixed.
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.
But as you stated, 2822 does say that the order should be preserved.
It's fairly unambiguous about that.
I suggest making the examples RFC 2606 compliant.
Are they not? Your changes alter the IP addresses, but RFC2606 doesn't
say anything about IP addresses. However, I've changed example-isp.com
to example.net as you suggested.
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html