On 09/29/2010 10:58 PM, Murray S. Kucherawy wrote:
I've posted a new issue of the DKIM implementation report. The most
interesting changes are the inclusion of a day of sample data from AOL and a
revision of the data summary reported by the OpenDKIM stats project using the
updated schema, which allows a few interesting new observations.
(You'll just have to read it to find out what they are!)
excellent work, Murray! One remark, one question.
Remark: I'd suggest to transform the AOL data to also contain
percentages, just like the results of the other (OpenDKIM statistics)
project. It will make it easier to compare (the results of) the two
'projects' and in general, percentages give a better view on what was
measured.
Question: regarding what you wrote:
That the "To" field is the one most often associated with
verification failures suggests some MTAs handling the message are
correcting cases where the field is improperly formed. A common case
is failing to quote the comment portion of that field when required
to do so by [MAIL]. Such corrections cause signatures to become
If this is the #1 reason that verifications fail, would there be room
for a new canonicalization scheme, to improve verification rates? I know
there are MTA's, implementing the principle of 'garbage in - garbage
out', just like there are MTA's implementing the principle of 'be
liberal in what you accept, be strict in what you emit'; the latter may
add a missing Date field, or correct a syntactically wrong Date field,
or modify To fields to match RFC5322 etc. This has been discussed
before, and it is impossible to come up with a canonicalization scheme
that addresses 100% of these modifications, but if we can address the
top 5 or top 10 types of modifications (and hence reasons for
verification failure), we might be able to further improve the
verification score, dont' we? Murray, do we have any figures about the
total percentage of DKIM signatures, which were invalidated by header
modifications, and a complete list of which headers were modified? Are
we talking about 5%, 1%, 0.1%, 0.01%?
This raises another question: a DKIM verification failure in itself is
not a problem: a spammer signing with an incorrect signature, or
replaying old (DKIM) message headers with new spam content will cause
verification failures, which is how it is supposed to be. However,
another category of DKIM verification failures may have to do with
header modifications by downstream MTA's, invalidating DKIM signatures.
The question here is: how can we gather statistics about these two (and
maybe there are more) different categories of verification failures, or
how can we differentiate between these two (or more) categories?
IMHO working on improvements to have more correct DKIM signatures
survive 'transport' is important to get industry momentum for DKIM. The
MLM problem is only one aspect of that problem. This is in line with a
question I got this week from a customer: what is the value of a
protocol (and why should I invest in it) if it is reliable in only 90%
of all cases? And even if we tell him, the real figure is maybe 95%,
then he's still asking for something in the order of 99% or 99,5%.
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html