Powers, Jot wrote:
On 3/14/07 8:01 AM, "Michael Thomas" <mike(_at_)mtcc(_dot_)com> scribbled:
Powers, Jot wrote:
On 3/12/07 5:43 AM, "Tony Hansen" <tony(_at_)att(_dot_)com> scribbled:
In other words, would folks prefer to:
A. Expedite publishing the Overview documents, in order to facilitate
development and deployment of the -base specification (with an update
later on for SSP), or
+1
B. Defer the Overview document until the SSP specification is complete.
As the largest phishing target out there, we're interested in having DKIM be
out there as soon as possible, without waiting for SSP, because even "fast"
for the IETF process isn't particularly speedy, whereas spammers and
phishers are.
Not to pick on Jot, but this is very illustrative of why putting
-overview in the path right now may be very counter-productive.
-Base *is* done. Waiting for -overview is *not* required. The
best possible wait time is the zero you can do by reading -base
right now and deploying it.
Don't worry, I can take it. :)
I almost wrote:
C: Wait for nothing.
But I was trying to be a good little list member and only vote on the
options provided.
Just to be clear:
We would DKIM sign now (and did a while ago) if our appliance vendor
supported DKIM, which they plan on doing, once it is a "standard" for some
value of "standard". (They have said summer '07)
Our approach is that we don't care about chicken's or eggs, we just love a
nice chicken omlete. :)
I think this touches on the important question about all of this: what
are we trying to accomplish right now? My feeling is that we want as
quickly as possible to fertilize the fields with as many DKIM signers
as possible. This is a very straightforward proposition and -base
provides the necessary blueprint on how to do that. I really don't
think we need anything more elaborate than that (from an IETF
perspective, that is).
How receivers use the verification results will hopefully become a
lot more apparent once we have a critical mass of people signing, and
this is a *good* thing -- we're creating a tool, not a solution. When
that plays out, I think it would be very useful to document that, and
any SSP related practices into a BCP. That's what I've envisioned
-overview as being a start on: an eventual BCP.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html