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
