ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New canonicalizations

2011-05-23 05:59:10

On 19 May 2011, at 18:19, Murray S. Kucherawy wrote:

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Ian Eiloart
Sent: Thursday, May 19, 2011 3:21 AM
To: John Levine
Cc: <ietf-dkim(_at_)mipassoc(_dot_)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.

Well, nor do I really. I'm just pointing out that IF IF IF the 10% and 8% 
figures are real then it's the 10% and 8% that you need to be comparing (that's 
a 20% improvement) not the 90% and 92% (a trivial improvement).

However, someone else pointed out that spammers and non-spammers seem to have 
similar patterns of using simple and relaxed. If that's the case, then we've 
eliminated one potential problem with the data.

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.

True. Though I've found that maybe one third of messages that I see with a bad 
signature also carry a good signature. 

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.

For May, so far, I see these canonicalisations for good signatures:
206136 c=relaxed/relaxed
55748 c=relaxed/simple
   1 c=simple/relaxed
29207 c=simple/simple

I also see these problems:
5816 invalid - public key record (currently?) unavailable
        364 signing domains
3772 invalid - syntax error in public key record
        93 signing domains


And these for bad signatures:
22577 c=relaxed/relaxed (9.9%)
        but 6087 (27%) of these are from yahoogroups.com, and almost all also 
carry a good signature!
4065 c=relaxed/simple (6.7%)
   6 c=simple/relaxed 
3094 c=simple/simple (9.6%)

And these are the failure reasons:
simple/simple:
1992  body hash mismatch (body probably modified in transit)]
1102  signature did not verify (headers probably modified in transit)]

relaxed/simple:
2796  body hash mismatch (body probably modified in transit)]
1269  signature did not verify (headers probably modified in transit)]

relaxed/relaxed:
1824  body hash mismatch (body probably modified in transit)]
20753  signature did not verify (headers probably modified in transit)]

d=yahoogroups.com:
  9  body hash mismatch (body probably modified in transit)]
5949  signature did not verify (headers probably modified in transit)]
-- 
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html