Subject: [ietf-dkim] Results of survey on DKIM Reputation string use

From: Dave Crocker <[email-masked]>
Date: Sun, 07 Oct 2007 13:39:23 -0700

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.

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.

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.

Comments?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 8 Oct 2007 10:36:53 -0700

On Oct 7, 2007, at 1:39 PM, 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:

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.

> analysis will defeat the ability to use it for strictly  

Okay.

> analyses, it MUST NOT be used as the primary string for public  

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