Ian Eiloart wrote: > On 16 May 2011, at 14:26, Alessandro Vesely wrote: > >> >> Yes, http://www.opendkim.org/stats/report.html#hdr_canon says >> >> Header canonicalization use: >> canonicalization count domains passed >> simple 653688 6786 591938 >> relaxed 3940377 56621 3640854 > > It does, but how does one interpret that? Certainly the weight of relaxed > versus simple passes implies a user desire for relaxed canonicalisation. > > However, the 90% versus 92% is meaningless without making certain > assumptions. If all these messages were originally properly signed, then the > 2% represents a 20% reduction in false negatives, but only if we assume that > canonicalisation method was selected at random or that choice of > canonicalisation method was statistically independent of the likelihood of > breakage - the latter might be plausible. > > However if some of the messages were never properly signed (whether failed > attempts to spoof, or administrative or technical failure), then that 20% > must be higher. It could even represent 100% reduction in false negatives due > to (otherwise benign) in-flight modifications. >
What it seems to indicate to me is that its the common trait when isolated to the domain or domain organization. IOW, the similar passage rate is a reflection of a domain implementation and verification pattern. For example, a single person subscribed to two list and submitting the same message to two different list (i.e. a CC to a second list): LIST1 - DKIM AWARE, RESIGN LIST2 - DKIM NON-AWARE can expect to see 100% pass with LIST1 but 100% fail with LIST2. This tangent thread started with LIST2 did no body changes except for what it normally did of adding an extra line after the header and before the body. The document editor and others believe this is a MLM BUG. It could be, but we don't know if its really an normal attempt to add HEADER text that was empty: Create List Message for Distribution: Body = EMPTY; Body += AppendText(GetHeaderNoticeForList()) + CRLF; Body += AppendText(GetMessageBody()) + CRLF; Body += AppendText(GetFooterNoticeForList()) + CRLF; We just don't know. Of course, for programmers, one can easily see that there is a "mite" there where extra CRLF will be added. We recognized it with the ending CRLF but "forgot" that list header text was also possible. The key point is for "40" years, it wasn't a problem until a new kid in the block came and now demands MLMs adjust to work with it -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html