[dkim-dev] Choosing sets of headers to sign

[Douglas Otis]

On Jan 12, 2007, at 12:44 PM, Hector Santos wrote:

>
> Doug, two things are clear.
>
> One, your design philosophy for DKIM is counter that of the current  
> consensus and direction; two, I don't think I will go wrong with  
> sticking with the what has been the standard electronic  
> communications variables in any environment since the dawn of time,  
> WHO ARE YOU? (From:), ARE YOU TALKING TO ME? (To:) , ABOUT WHAT  
> (Subject:) and WHEN (Date:).
>
> Any new "altering" system being consider is a FOREIGN concept and  
> should follow a "reversibility" rule of thumb that is the standard  
> consideration in all transformations.
>
> In short, if you can secure these four fundamental message  
> variables, From:, To: Subject: and Date: then nothing will work  
> right, never mind DKIM.
>
> Dave asked a simple question and as it is TODAY and has been for  
> multiple decades of years, these variables are pretty sound across  
> the board.  Thats obvious and they will be our defaults.

DKIM does not answer either "Who" or "To", which is information  
carried within the envelope.  There might be an obvious association  
between some message header domain and the signing domain only when  
the same domain is shared by these two functions.  The recipient  
might care about "who" and they can assume the "to", but that is not  
answered by DKIM.  If knowing "who" was the goal, then OpenPGP or S/ 
MIME should be used.

DKIM creates an invisible entity that assures abuse feedback  
reporting, perhaps even DSNs when an association can be determined.  
Perhaps annotations can also be added  as an assurance based upon the  
signature along with a reduction in the false positive rate of anti- 
phishing filtering.  The signature does not need to match the domain  
found within the header when the signing-domain and email-address  
domain are combined together as a trusted element.

For DKIM to be useful to the recipient, the message must be annotated  
when the "identity" within the header is recognized by the  
recipient's MDA or MUA and associated with the signing domain in some  
manner.  How an entity is recognized is beyond the scope of DKIM.

Protecting recipients must avoid constraints that are  
administratively prohibitive.  DKIM should take an opportunistic  
approach to be practical.

Consider this: Spammers will be the first to implement a change.

So should a header containing "<utf8 at utf-8 [ascii at ascii]>" be signed?

What heuristics are reasonable to recover from a downgraded  
<utf8 at utf-8 [ascii at ascii]> or <utf-8 at utf-8> header?

How many trial iterations are reasonable?

Which domain will the recipient trust based upon signature verification?

A restrictive policy used to solve these issues will reduce DKIM's  
delivery integrity.  A associative policy solving this problem will  
increase DKIM's delivery integrity and even permit better  
protection.  Unfortunately, the current header signing requirements  
will create an immediate reliability problem that will surely be  
exploited.

-Doug