Subject: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01

From: SM <[email-masked]>
Date: Thu, 30 Sep 2010 18:51:44 -0700

Hello,

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.

Are the participants mentioned in Section 3.1 implementors of RFC 4871?

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?

Section 4 is about deployment.  It provides arguments against pruning 
features from RFC 4871 as they are in use.

The results in Section 4.1.2 mention "Author vs. Third-Party".  That 
is more about ADSP than DKIM.

   "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?

Section 4.2 mentions Originator signatures.  RFC 4871 does not 
mention that type of signature.

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.

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.

Thanks to Murray for collecting and publishing useful data about DKIM.

Regards,
-sm

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

---

From: "Mark Delany" <[email-masked]>
Date: 30 Sep 2010 20:04:42 -0700

On Thu, Sep 30, 2010 at 06:51:44PM -0700, SM allegedly wrote:
> draft-ietf-dkim-implementation-report-01.

Me too.

Thanks very much for writing this up, Murray. Very enlightening. And
that Alt-N - a relatively small company - hosted an event for the big
guys at their expense speaks volumes about the commitment of Arvel and
his crew. We are in their debt.

Mark.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Sep 2010 23:48:01 -0700

> -----Original Message-----
> From: SM [mailto:[email-masked]]
> Sent: Thursday, September 30, 2010 6:52 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Comments on draft-ietf-dkim-implementation-report-01
> 
> Hello,

Hi!

> The information is more about deployment and than implementations

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.

> 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?

> is more about ADSP than DKIM.

True.  It should probably come out.

> Is the 84.7% success rate for "List" mail?

As defined here, yes.

> mention that type of signature.

I'll correct that.

> From: header field is a always signed.

Signing From: is mandatory, so that was expected.

> 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.