> -----Original Message----- > From: SM [mailto:s...@resistor.net] > Sent: Thursday, September 30, 2010 6:52 PM > To: ietf-dkim@mipassoc.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
