[ietf-dkim] Whither 4871bis?

[Douglas Otis]

On May 9, 2009, at 11:06 PM, Eliot Lear wrote:

> On 5/9/09 2:01 AM, John Levine wrote:
>>> with some editorial changes I guess. I've not seen anyone suggest  
>>> that we add features or remove a raft of features or make other  
>>> substantial changes.
>>>
>> I'm with Steve, I'd like to deprecate the useless stuff.
>
> I like deprecating useless stuff, but before we do that I would like  
> to see broader implementation, and again, specifically in mailing  
> list managers, before we decide what is useless.

Agreed.  It appears merging errata now means explaining once again why  
features were included and why their possible use should be supported,  
even if only to generate clueful error messages.  It may takes years  
before issues being addressed by some feature becomes apparent.  This  
may occur only after greater adoption and MUA integration where  
reliance and annotations make their impact perhaps several years from  
now.

For example, providers may insist upon adding a disclosure  
notifications at the end of emails.  The l=value, when used  
appropriately and is properly supported, could ensure a message  
remains in an state that will not prohibit non-repudiation, by being  
explicit about the body length.  This feature may also allow providers  
a means to escape the hashing large attachments, for example.

DKIM is too new.  Anything looks complex until people get used to it.   
I also fear there are those with conflicted interests which might wish  
to emasculate DKIM to better enable competing strategies.  DKIM needs  
to be better protected from change based upon one's perception of  
complexity.

-Doug