[ietf-dkim] Re: Role of Sender header as signing domain

[Douglas Otis]

On Dec 7, 2006, at 12:46 AM, John Glube wrote:

> DKIM is not path based. It is a lightweight cryptographic method  
> for "validating an identity that is associated with a message,  
> during the time it is transferred over the Internet. That identity  
> then can be held accountable for the message."

DKIM does not encompass the envelope.  While it might be possible to  
hold signers accountable for content, this MUST exclude unsolicited  
message status.  This eliminates DKIM for white-listing or block- 
listing, because either is easily abused.  While DKIM is not path  
based, white-listing MUST be protected from replay abuse.  Before a  
message obtains a "white-listed" status, a prerequisite should  
include associating SMTP clients with the signing-domain.  The same  
strategy protects MailFrom, "third-party" signing, and establishes  
policy for all other headers.

For illustrative examples see:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt

> I quote from the mission statement found at
> http://www.dkim.org/
>
> This means to me that the entity responsible for injecting the  
> email into the Internet can say, "Yes, I am an identity that is  
> associated with that email and can be held accountable."

It would be nice to think a DKIM signature is indicative of the  
entity transmitting the message.  If so, DKIM would then help in  
resolving abuse issues.  Alas, an expectation that providers use  
their customer's private keys removes this feature. : (

> For an e-mail application service provider, (ESP), one way to do  
> this is for that entity to sign the RFC 2822 sender header.

Fully agree. : )


> By doing so, the ESP says "I, ESP am the entity sending this email  
> on behalf of my client, List (identified in the RFC 2822 from  
> header) and as such an identity that is associated with that email  
> and can be held accountable."
>
> This approach is consistent with best practice and is specifically  
> allowed for in DK.

It could also be allowed in DKIM when protection is obtained by  
annotation of email-addresses associated with the signing-domain.   
With millions of new domains created at no cost for bad actors each  
day, marking message "known" (through non-visual comparison) allows  
DKIM to prevent spoofing.  DKIM can not prevent abuse, although not  
being on a "white-list" might limit the volume.  Many of the larger  
domains are often block-listed due to acts of a few.  While these  
domains are also easy targets of replay abuse, safe "white-listing"  
of these domains remains possible only when the SMTP client can be  
associated with the signing-domain.

> Am I now to understand that no, you may only sign the RFC 2822 from  
> header and nothing else, if you want to: (i) publish a sender  
> signing policy; or (ii) take advantage of any reputation proposals  
> such as the Domain Assurance Council, which although out of scope,  
> is one of the perceived benefits of DKIM?

Without a means to associate a signing-domain with other email- 
originating-identities, yes!  Some suggest abuse can be blocked after  
"everyone" publishes highly restrictive policies that "break" email,  
AND after everyone searches the domain label tree for rare highly  
restrictive policy statements.  Of course this overlooks a sizable  
problem of visual recognition and perhaps why UTF-8 remains ignored.

-Doug