On Oct 7, 2007, at 1:39 PM, Dave Crocker wrote:
Folks,
Last August, Dave Crocker wrote:
I've had a brief exchange, with a few folks recently, that
suggests quite a bit of ambiguity about the DKIM-related
information to be used for assessing reputation/accreditation.
Simply put:
When you validate a DKIM signature, what information do you
(intend to) use for querying your reputation/accreditation
data bases?
The survey produced a useful set of responses. I think they
suggest a clear
consensus for using the d= string, as the basis for any public
reputation
analysis.
(What a receiver chooses to do in the privacy of their own
filtering analysis
engine is, of course, their own business. The question, here, is
about a
common semantic among signers and validators.)
Detailed Results:
d=: 9
i=: 2
i=, but d= if no i= present: 2
s= + d=: 1 (for company-internal signing and use only)
There were some elaborations, with a few folks discussing deeper
analyses,
such as using s=, i= and/or h= for "associative" analysis. I think
this draws
exactly the right distinction between a basic, public semantic
standard,
versus whatever heuristics are added to it privately.
Some comments that were offered struck me as particularly helpful for
capturing basic issues:
The d= domain. It's the only domain that's actually verified.
and
The name of the signing key is inherently more credible than
information that is "protected" by the signing key, including
rfc822.from.
and
The addition of the selector seems particularly useful for segmenting
mail along functional lines (person-to-person, marketing,
transactional,
Discussion:
With the survey results as background, I'll suggest the following:
Generic DKIM statement:
When a DKIM signature is validated, the meaning is that a
particular
domain name's owner is declaring some responsibility for the
message. (This
is offered as
So,
1. That domain name to be used for reputation analysis is contained
in the d=
parameter of the DKIM-Signature header field. It is the parameter
intended to
state the name of the (domain) responsible party.
This assertion will also need to deal with situations where there
are multiple signatures. A signature within an email-address domain
contained by a header that might have originated the message is
likely to be given priority.
2. The s= parameter MUST NOT be used for primary reputation
analysis. It is
explicitly NOT intended for use in responsibility (reputation)
analysis. That
parameter is *only* intended for administrative key management use,
such as
periodically rolling over to a new key. An organization can have
many
different schemes for the way it performs key management. A DKIM
receiver
cannot know what scheme(s) are being used. Any use of s= for
reputation
analysis will defeat the ability to use it for strictly
administrative purposes.
Okay.
3. i= derives from d=. The derivation means that there is a layer of
indirection to its meaning and, possibly, some potential for less-
strict,
stable or less valid use. While possibly useful for secondary,
elaborated
analyses, it MUST NOT be used as the primary string for public
standards-based
reputation analysis.
The i= might not related to any email-address identity within the
message. Take for example your suggestion to use sub-domains to sign
messages when making different assertions. In this case, the i= of
the message would be invalid for any of the originating email
headers. It might be more interesting to discuss the implications
when there are implied sub-domain authorizations of email-addresses.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html