I'm going to reply to this point in both threads, so people who just read the charter thread see it. Please continue any discussion of it here, in this thread.
On Wed, Sep 30, 2009 at 2:01 PM, Franck Martin <[email protected]> wrote: > Seems to me something is missing: gather data to establish if DKIM > specifications have in any way alleviated any misuse of the email system, > in particular but not limited to spam, phishing attacks and fraud. On Mon, Oct 5, 2009 at 8:27 AM, Franck Martin <[email protected]> wrote: > I just had the feeling, seeing all the presentations, blogs ,etc... about DKIM > that we have forgotten why it was created on the first instance, and I just > wanted to put it back there where it belongs. > > Like now each RFC must have a security consideration chapter, should > email(and other messaging) related RFCs have a spam consideration chapter? > > So as for the workgroup charter, it seemed all for refining the DKIM specs, > forgetting the original goal, but then I also realize the goal of reducing > spam > was skilfully removed from the original charter (yeah, I should read the past > charters first ;) ) It's not a question of skill, though thanks for the vote of confidence there. :-) It really was a question of focus: DKIM has never been meant to address spam directly, but to be a tool to enable other mechanisms to address spam. That's reflected in the charter, both the old one and the proposed new one. I like the idea of having spam considerations in email-related documents, actually. I think the right place for that is in the Security Considerations, and I think the Apps ADs should be the ones responsible for making sure that spam-related considerations are in there when appropriate. Good idea. To the point of gathering data, two things: 1. I agree that it's very important to do the data collection and analysis. It's also something that people are doing: I know that Cisco is keeping track of various DKIM stats, and has shared partially anonymized versions with us before. Dave is collecting data, through his surveys, on the deployment and use of DKIM. Both Dave, as MAAWG technical advisor, and I, as IETF liaison to MAAWG, will be getting data, over time, from MAAWG members who use DKIM. 2. The IETF standards track has specific emphasis at the different maturity levels (see RFC 2026). For Proposed Standard, we need rough consensus that a protocol will be useful, will interoperate, and is well designed. For Draft Standard, we need to demonstrate that it does interoperate, and that we have "sufficient operational experience". Note that RFC 2026 says, "A Draft Standard may still require additional or more widespread field experience, since it is possible for implementations based on Draft Standard specifications to demonstrate unforeseen behavior when subjected to large-scale use in production environments." That doesn't mean that we know, yet, that it's as useful as we'd hoped or would like. For (full) Internet Standard, we need "significant implementation and successful operational experience", "a high degree of technical maturity," and "a generally held belief that the specified protocol or service provides significant benefit to the Internet community." This is the level at which we need to show how useful it is -- that it's actually accomplishing what we'd like it to, and that it's a "significant benefit". DKIM might or might not get to full Internet Standard, but that's not what we're aiming at now. We do want to collect the data Franck is talking about, and we are doing so. And if there's consensus to put that in the charter, I'm happy to do so (so far, only Franck has asked for it). But it's not a prerequisite for moving to Draft Standard. On the other hand, it's entirely possible that moving to Draft Standard is a prerequisite for getting the wide-spread deployment needed to see the real usefulness. Barry _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
