On 10/14/2010 07:56 AM, Mark Delany wrote:
On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote:
What is essential is that it perform the task of validating and delivering a
signing domain that is associated with a collection of bits. Anything that
defines how to do this is essential. Anything that can make this break
needs to
be covered, especially if there are ways to protect against the breakage.
But isn't the problem that the signing domain is being incorrectly
associated with a different collection of bits?
And just to elaborate on my own point. We went thru a lot of
hand-wringing over canonicalization and the l= tag and so forth
precisely because we were concerned about associating a signing domain
with the wrong bits.
But now it seems that making the wrong association is not treated with
as much concern.
If it is true that the DKIM effort is about associating an identifier
with a collection of bits, it equally must be true that we want to
make a similar effort to ensure that identifier is not associated with
an unrelated collection of bits.
Mark, with a signed bunch of bits you get two prizes for the price
of one: you know which bits are signed, and then you know which bits
aren't. There is no ambiguity in the spec about which bits are signed,
so we're quibbling about the ones that aren't. Isn't this where we
want to have people's secret sauce take over? That is, we want MTA,
MDA, and MUA's to take those two piece of information and make better
decisions about, oh say, rendering? We already know that the DKIM
spec alone is not going to force the hand of recalcitrant or uncaring
MUA's, but it is potentially quite helpful to ones that are receptive.
Unless there's *really* something they can't figure out without protocol
help, I'm not sure what the point of this is. This double added From thing
is trivial to detect with the current spec.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html