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
