The Value of Reputation (was Re: [ietf-dkim] Re: WG Review:Domain Keys Identified Mail (dkim))

Douglas Otis dotis at mail-abuse.org
Wed Dec 28 10:12:14 PST 2005


On Dec 28, 2005, at 1:55 AM, Hector Santos wrote:
> "Douglas Otis" <dotis at mail-abuse.org> wrote:
>>
>> I see the base DKIM draft forming a solid basis to identify email  
>> sources.  The ill considered SSP draft will seriously hinder the  
>> DKIM effort.
>
> The bottom line is "for me" is NO SSP, NO DKIM. I won't bother. I  
> won't waste my time.  Call it want you want SSP or whatever, the  
> process must be consistent, and if there is NO HIGH reliable  
> DETERMINISTIC (not HEURISTIC) verification concept of a newly  
> introduced entity into the process, then its isn't worth anything.   
> What's the point?  We will get swamped with YAHOO junk mail anyway  
> and until the day YAHOO declares a specific POLICY on how to handle  
> its domain mail, the DKIM/DK overhead will not be added. PERIOD.

The dkim-options draft provides the 'w=?' signature extension:

  w=b  Always signed by MSA, broad ass. across email-domain
  w=n  Always signed by MSA, narrow ass. with email-address
  w=d  Signed by MSA, broad association across email-domain
  w=a  Signed by MSA, narrow association with email-address
  w=o  Signed by MSA, association with Opaque-Identifier
  none Signed by MSA, no association assured
  w=B  Always signed by Mediator, broad ass. across email-domain
  w=N  Always signed by Mediator, narrow ass. with email-address
  w=D  Signed by Mediator, broad association across email-domain
  w=A  Signed by Mediator, narrow association with email-address
  w=O  Signed by Mediator, association with Opaque-Identifier
  w=M  Signed by Mediator, no association assured
  w=X  Signed by MDA, no association assured

Most of this information should prove valuable for the MUA, and not  
the MTA.  The exception could be 'w=b'.

When an MTA sees the 'w=b' within a signature, for bigbank.com as  
example, where the email-address domain is also within the signature  
domain, this can be captured in a local-list as a (wildcard) domain- 
name (in a zone) with a pointer to where this assertion can be later  
confirmed.  When a message is accepted, email-addresses may be  
quickly queried against this local list.  When the message has an  
originating email-address domain found within this local-list, but is  
not signed by this domain, once the 'w=b' assurance is confirmed, the  
message would be refused.  This involves only a single cached query  
that occurs only when a spoof has been attempted.

Compare that to SSP, where Jim suggested in the threat draft every  
 From email-address domain may have the tree climbed looking for an  
SSP policy record.  Few of these lookups would be cached when these  
records do not exist.  These records also increase the domain's  
exposure to unfair reputation harm, unless the record expressed  
essentially the same assurances as 'w=b'.  If a domain like Yahoo  
still allowed their users the freedom to send their email-address  
through other providers, there would be no exclusion obtained.   
However, when Yahoo signs their messages and includes an Opaque- 
Identifier, the recipient would be able to recognize when the email  
source used by a particular Yahoo author changed.  The value of the  
DKIM signature does not depend upon excluding messages at the MTA, or  
being from a major corporation that assures exclusive use of their  
domain name.

The value of DKIM is fully realized when MUAs utilize the signature  
to recognize prior correspondents.  Highlighting such messages would  
be a safe and useful indication shown to recipients.  (Offering any  
indication that a message was authorized by an SSP record would put  
the recipient in serious jeopardy of being mislead.)  With DKIM and  
recognition built into the MUA, look-alike domains exploits, and  
other spoofing attempts could become a problem of the past.  BATV  
would still be needed to handle DSN exploits, and CSV would be needed  
to offer DoS protections and replay mitigations.  : )

-Doug



More information about the ietf-dkim mailing list