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
over in the "gathering data" thread.
On Wed, Sep 30, 2009 at 2:01 PM, Franck Martin <franck(_at_)genius(_dot_)com>
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 <franck(_at_)genius(_dot_)com>
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