On Jun 11, 2009, at 11:50 PM, Dave CROCKER wrote:
Existing Introduction text:
This currently leaves signers and assessors with the potential
for having differing -- and therefore non-interoperable --
interpretations of how DKIM operates.
This update resolves this confusion. It defines new labels for
the two values, clarifies their nature, and specifies their
relationship.
Proposed text:
This currently leaves signers and assessors with the potential for
making different interpretations between the two identifiers and may
lead to interoperability problems. A signer could intend one to be
used for reputation, and have a non-reputation intent in setting the
value in the other. However the assessor might choose the wrong
value and produce an unintended (and inaccurate) reputation
assessment.
This update resolves that confusion. It defines additional,
semantic labels for the two values, clarifies their nature and
specifies their relationship. More specifically, it clarifies that
the identifier intended for reputation lookups (such as white lists)
by the assessor is the value of the "d=" tag. However, this does not
prohibit message filtering engines from using the "i=" tag, or any
other information in the message header, for filtering decisions.
Section 6.3 of RFC 4871 indicates that verifier actions are beyond the
scope of the specification. Nevertheless, leaving Appendix D as
written would have been preferred.
IMHO, the "errata" makes an inappropriate change to Appendix D's
expression of intent. Appendix D used the signing identity (the i=
value) to select "on-behalf-of" addresses for annotations by MUAs.
When the i= value is not present, this defaults to "@<d= value>".
The "errata" makes a significant protocol change by suggesting just
the d= value is to be used. Also, it would be wrong to suggest that
reputations should be based upon the d= value, although such practice
will advantage larger domains. The i= value or its default will
better mitigate intra-domain abuses and provide better coverage than
will suggesting that reputation and annotations should be limited to
just domains. The "errata" should not have made this change while
redefining terms.
For signers and assessors that have been using the i= tag for
reputation assessment a software change to using the d= tag is
intended.
This change was unwise. When a domain demonstrates poor stewardship
by signing too many unique and problematic intra-domain sources (i=
values) , it is not difficult for a service to then publish ratings
that apply globally for the entire domain. With respect to services
offering information for intra-domain sources, a signing domain can
always decide what they wish to offer, since the i= parameter is
optional. From an annotation perspective, perhaps only a portion of
the i= value will correspond with signed headers, or perhaps there is
no correspondence. Nevertheless, the i= value (or its default)
remains the preferred annotation (and reputation) reference that
offers the greatest value to recipients.
As SMTP IP address acceptance becomes more constrained, a greater
proportion of abuse will exploit hijacked accounts within large
domains. As such, it is important NOT to make this change to DKIM.
It is far too soon to start drawing conclusions about DKIM reputation
strategies. Larger domains should temper their desire of seeking
advantages and instead take the long view.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html