***
cutting all text from about 30 messages on the subject
***
I'm on a plane now from Asia, finally catching up on the mailing list.
After reading the postings, I've never been more concerned about the
future of DKIM. Here's why:
The list is quiet for weeks and then a storm of emails on the charter
language. Are we really 30X more interested in charter language than in
the technology? I think so!
Disclaimer: my bias is toward moving DKIM forward on a reasonable,
expedient path. But I'm smart enough to know that while my analysis may
show a lack of critical flaws in the current specs, there may be some
hiding somewhere. But after reading the last 30 email messages, I can't
discrern any meaningful flaws that can be used to improve the technical
specifications. So, I have to agree with Dave's oft-asked question:
"what changes should be made to the technical specifications?" Right now
I can't figure this out. Perhaps they are critical, maybe not. But right
now I feel there is a tremendous amount of "concerns" and "don't do it
*this* way" and a lack of "section X states blah. this is bad because of
XYZ. change it to improved blah." this is the type of discussion I feel
would benefit us tremendously, even if it leads to upsetting the apple
cart. while i don't personally see the needs for radical changes to
current DKIM specs, i'm open to them if someone can present clear data
and recommended changes. if DNS is the wrong place for DKIM records or
if Doug's weekly-proposed recognition scheme is the second coming of the
IETF deity himself, great. somebody just present some hard issues and
solutions!
Let's hammer out the technical specifications, make them the best they
can be and get this thing to market. Let's not discuss whether the
charter should allow divergence from DNS, let's discuss the best
solution and if DNS can be proven the wrong way to go, I'll gladly argue
for this change. Let's be technologists, not philosophers.
Two other comments:
1. In talking to a few hundred Japanese and Chinese IT folks last week,
I tried to explain the promise and (many) limitations of DKIM and SIDF.
Internet users are counting on us to add authentication of some type to
SMTP. I would never support a fundamentally flawed or unworkable
technology, but I fear that if DKIM standardization does not move
forward with some positive actions in the next few months with tangible
results in the next year, the technology deployers may lose interest and
our wonderful specification may go unadopted, solving no problem. (I
*do* support imperfect technologies all the time. I consider DKIM
imperfect but not flawed or unworkable. But I look forward to specific
examples of this together with solid solutions ready for inclusion in
the specification.)
2. On adoption: I'm happy to hear of Arvel's success in propagating
DKIM. Even the longest journey begins with a first step. I wish I could
say the same for our customers. Unfortunately they are very actively
deploying DK technology. They aren't interested in signing with DKIM if
few are validating DKIM and they perceive too much in limbo concerning
DKIM. They are looking forward to the consensus that gives them
confidence in DKIM to switch from DK. Until then, they will stay with
the legacy de facto standard. Brilliant or stupid, this is the market
speaking, if I could get them to all do my bidding, I'd be a very rich
man. :)
pat
_______________________________________________
ietf-dkim mailing list
http://dkim.org