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(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html