-----Original Message-----
From: SM [mailto:sm(_at_)resistor(_dot_)net]
Sent: Thursday, September 30, 2010 6:52 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Cc: Murray S. Kucherawy
Subject: Comments on draft-ietf-dkim-implementation-report-01
Hello,
Hi!
I have a few comments about
draft-ietf-dkim-implementation-report-01. The Abstract Section
mentions that:
"This document contains an implementation report for the IESG
covering
DKIM in support of the advancement of that specification along the
Standards Track."
The Introduction Section mentions:
"Enclosed is a summary of collected interoperability data provided
from sources that are aggregating such information as well as from
a
more formal DKIM interoperability event that took place in October
2007."
The information is more about deployment and than implementations
based on the RFC.
I think the two are inter-related, which is why both are covered. Procedure
requires demonstration of multiple interoperating implementations based on the
RFC, which was done by the 2007 interop event but never really published in a
formal sense other than a press release.
Put another way, "implementation" can be interpreted as "writing code to the
spec" as well as "rolling it out into production". RFC5657/BCP9 actually
mentions both implementation and interoperation specifically.
But also important is discussion about some things we didn't expect to see that
may reveal themselves as the protocol has matured. For example, a flawless
DKIM implementation is still thwarted by the injection of malformed header
fields that are signed and later corrected to spec by downstream MTAs. I
believe that's useful information for the community.
Are the participants mentioned in Section 3.1 implementors of RFC 4871?
Section 3.1 mentions that nearly all of the implementations were developed
independently, so yes. A few were based on a common open source platform, but
the bulk of them were not.
In Section 3.4:
"The handful of interoperability issues described above that
referred
to weaknesses or ambiguities in [DKIM] resulted in several errata
being opened via the RFC Editor web site."
There isn't any description of the interoperability issues in Section
3.3. Could references to the errata be included?
Sure, but are those numbers permanent such that later readers will find the
same data, or should we describe each of the items that came out of the Interop?
The results in Section 4.1.2 mention "Author vs. Third-Party". That
is more about ADSP than DKIM.
True. It should probably come out.
"Pass Rates for Non-List Mail: Where "list mail" is defined as any
mail not bearing one of the header fields defined in [LIST-ID] or
in [LIST-URLS], or a "Precedence: list" field, selecting only for
mail that is not list mail revealed a successful verification rate
of 93.6%; selecting only for list mail produced a 84.7% success
rate."
Is the 84.7% success rate for "List" mail?
As defined here, yes.
Section 4.2 mentions Originator signatures. RFC 4871 does not
mention that type of signature.
I'll correct that.
Section 5.5 of RFC 4871 recommends that the Subject:, Date:,
MIME-Version:, Content-Type: and Message-ID: header fields SHOULD be
included in the signature. It is interesting to note that only the
From: header field is a always signed.
Signing From: is mandatory, so that was expected.
Section 5.5 of RFC 4871 also recomments that the Received: header
field should not be included in the signature. That header field is
signed in 59.7% of the cases observed.
Right, and this perhaps indicates that some implementations elect to sign all
header fields that are present. I believe this was true of earlier versions of
the dkim-milter library, for example. It doesn't violate the specification but
it does show a certain pseudo-popular implementation (or perhaps,
configuration) decision.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html