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