On Feb 3, 2009, at 11:47 AM, Dave CROCKER wrote:
ps. FWIW, my intent in included SDID was that the particular naming
scheme is outside of DKIM semantics. So marketing.example.com and
hq.example.com, versus newsletter.example.org and
invoices.example.org are significantly different naming schemes, but
the semantics behind them is opaque to DKIM semantics and,
therefore, to the Identity Assessor.
I agree with Tony. The goal of DKIM is to identify domains.
A domain verified as having handled a message is an important
identifier clearly within DKIM semantics. The d= value is assured by
signature verification, whereas the entire i= value is not. The d=
value constrains what might be included within the i= parameter.
Even when the i= value is opaque, it may play a critical role in
limiting the impact of various types of source specific abuse handled
by the domain. When done in a consistent fashion, the source may
remain anonymous, but the identifier itself can be of great value.
The specifics of handling consistency are unimportant.
When the i= value is not opaque, it may match a From header field
email-address, but the email-address must be within d= value. When d=
big-bank.com, it would be safe to highlight this domain within signed
headers containing email-addresses within this domain.
As such, the domain identity remains transparent since it relates to
the introduction of the message into the mail stream. The i=value,
even when opaque, might allow the mitigation of source specific abuse
handled by the domain. Both values are important, but only the i=
value could be considered opaque.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html