[dkim-dev] Choosing sets of headers to sign

[Douglas Otis]

On Jan 12, 2007, at 2:58 PM, Hector Santos wrote:

> Douglas Otis wrote:
>> On Jan 12, 2007, at 12:44 PM, Hector Santos wrote:
>> Consider this: Spammers will be the first to implement a change.
>
> Actual, bad guys do not have to change because DKIM-BASE is not  
> forcing signature requirements.

Bad actors are sure to leverage assurances offered messages with  
validated signatures.

>> 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?
>
> I doubt this will have any impact on the email world any time soon,  
> if ever.  Don't assume vendors are going to willy nilly add things  
> that are illogical and risk breaking across many fronts.  The FROM:  
> is one of them.  So from my standpoint, it doesn't apply.

The issue of "breaking" is covered with a "downgrade" process,  
however convoluted this might become.

> Besides passthrus/routers shouldn't be changing anything in route  
> and EAI is basically the realm of the initial creator and MDA  
> backend and/or MUA supporting it which is BEFORE and AFTER the  
> fact.  Not the transports where DKIM is currently designed for.   
> EAI may be a problem for your MUA DKIM ambitions but it isn't for  
> transports.

DKIM as currently designed breaks when the SMTP transport changes.   
DKIM can be flexible, provide better protection, and reduced  
administrative costs by accommodating a method of association rather  
than seeking to incorporate a series of burdensome restrictions.  The  
familiar matrix of conditions met before a message is accepted is not  
how spam is prevented or anyone protected.  Tangible benefits that  
might be realized could be lost should DKIM prove problematic as a  
result.

Deciding upon what to sign based upon what the recipient sees?  What  
does it mean when the recipient sees two dissimilar domains within  
the header?  How has that helped the recipient?  What can be safely  
deduced when the one domain they see is encoded using UTF-8?

Basing header inclusion decisions upon what the recipient might see  
has extremely limited value.  This basis is foolhardy at best and  
irresponsible at worst.  The basis should consider what will improve  
email delivery and integrity, even when this requires annotation.   
When will it be acknowledged by the DKIM experts that DKIM requires  
annotation in order to protect recipients based upon what they see?

EAI downgrading will support legacy handling for an extended period  
time.  The SMTP client detects when the SMTP server does not support  
the "UTF8SMTP" option.  This is an SMTP transport and a DKIM issue,  
especially as related to which headers are signed.  Things will be  
changing in route where multiple domains might be offered as  
interchangeable identities.  Confirming these identities requires an  
ability to generate ACE labels from a UTF-8 form.  An associative  
approach does not demand that domains match, and can easily  
accommodate this EAI change.  DKIM, as it is currently specified, can  
not.

For a large portion of the world, ASCII is not the preferred method  
to convey identities.  This very large segment will implement the EAI  
change, and there is a desire for the ASCII and non-ASCII world to  
still communicate.  So this does affect which headers are signed,  
what might be involved with respect to DKIM signature verification,  
and of course what might be communicated to the recipient.

-Doug