> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Ian Eiloart > Sent: Thursday, May 19, 2011 3:21 AM > To: John Levine > Cc: <ietf-dkim@mipassoc.org> > Subject: Re: [ietf-dkim] New canonicalizations > > Probably true, but if the difference between 10% broken and 8% broken > signatures is independent of whether the email is spam, then actually > "relaxed" seems to be producing a 20% reduction in signature breakage. > > I'd argue that a 20% reduction in broken signatures *is* actually "much > better".
That statistic is largely meaningless unless there's a basis for comparison. For example, it would be useful to observe that the same message, sent with each of the four canonicalizations, to the same set of destinations using the same endpoint software, produced different results given that one changing variable. But if domain X only ever tried sending with relaxed/relaxed and generally gets good results, there's nothing in that datum to say that simple/simple would not have worked just as well for the same sender with the same mail. Thus I don't believe there's enough data to support your conclusion. That relaxed/relaxed appears to survive 20% more might be based on the fact that the people using it send clean mail through clean paths, and it's as simple as that. > To determine that, we'd need a pareto analysis of breakage modes. > Presumably lists that aren't re-signing are responsible for some of > this, as are broken signing mechanisms. The questions remaining are, > "is there anything left after excluding those two cases?", and "how > much of that could be fixed easily?". Our stats are unable to tell what the problem is in all cases, but for mail we've received where the signer used the "z=" tag, the biggest signature breaker in terms of header changes is modified To: fields. I suspect that's either rewriting by lists to add the list description as a comment, or improperly quoted comment fields that are corrected along the way. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
