[ietf-dkim] drop requirement to sign "From" or other "originator" headers?

[Eric Allman]

Mark,

Frankly, my main reason for doing it this way right now is that 
saying you don't have to sign anything puts us in the weird position 
that the spec then says you have to sign /some header/ but doesn't 
mandate any, and that seems to be a source of latent problems.  I 
don't have any serious objection to removing From, but at the same 
time in order for it to make sense we should make an empty h= list a 
possibility.  That's a big enough change that I think we should think 
it through more carefully.

As for whether we protect MUAs, my answer is no, but maybe yes.  That 
is, protecting MUAs isn't DKIM's primary intent, but the verifier 
might want to use information conveyed by DKIM to in some way protect 
the MUA --- or more precisely, the MUA might want to use the DKIM 
information to protect the end user.  But that doesn't make it a 
MUST, just a good idea.

So, keeping From: in is just a matter of yielding to pragmatics, 
specifically in avoiding an edge condition that I think we should 
think through a bit more.  I'm happy to change it in -05 if we decide 
we can manage the situation.

eric



--On July 14, 2006 5:51:55 AM +0000 Mark Delany 
<MarkD+dkim at yahoo-inc.com> wrote:

>> Eric Allman wrote:
>> > Folks OK with that?
>
> -1
>
> If a verifier has a verified email with a d= what is the fundamental
> value-add on insisting that From: is a signed header? After all, a
> minimalist verifier is going to query some database to ask the
> question: Do I like d=?
>
> Will that query be influenced by a From: header? I'd think not. A
> minimalist verifier could care less. All they want to know is, who
> is the responsible domain and how much do I like them?
>
> It still seems to me that enforcing a From: is a vestigial attempt
> to protect MUAs. But I thought we had decided that we weren't in the
> business of solving that problem? Is that true?
>
> If we are truly out of the business of protecting MUAs, then I see
> no rationale for enforcing From: signing.
>
> If we are in the business of protecting MUAs then we need to
> re-visit that whole can of worms around Sender: and Resent: and all
> those other potential MUA originators and triggers.
>
>
> Mark.
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>