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
