----- Original Message ----- From: "Arvel Hathcock" <[EMAIL PROTECTED]> To: <[email protected]>
> > I'm not convinced there is sufficient installed base that > > should preempt making DKIM work right, the "first time." > > What sort of deployed base would you consider "sufficient"? Speaking for > myself alone I've had many tens of thousands of downloads (and I assume > installs) of my software since DK/DKIM support was added. For me, that's > significant and I'm nothing compared to some of the other vendors interested > in this topic. If that includes automatic installation of DKIM for each customers, then that would be significant for your customer base. But we have over 100,000 customers using WCSMTP and we also added SPF among other things. This does not suggest we have 100,000 customers using SPF. We are not automatically enabling SPF, adding DNS records, and so on for each domain. That is left up to the sysop and it took awhile to convince people to add SPF records. But the industry has lots of packages and just because SendMail and ALTN added DKIM support, does in in way indicate we have a sufficient install base. We have MS EXCHANGE, EXIM and a slew of popular systems to deal with as well. If this is a concern now, then what you are implying we now have a big compatibility problem and I will add to this concern, a major threat vector because if we have to support the early adopters, exploiters will make sure there are using "version 1" and stay away from a more secured system. Thats a given and in my view, it defeats the purpose of this work. Also, if early adopters were adventuous enough to add early support, I am sure they will also be eager to make whatever changes need be to work with the more secured official standard. You might be in a position to have to worry or deal about backward compatibility, but I will venture that most packages will not worry about a vastly un-supported, non-standard, unsecured early rendition. > > So early adopters, who well knew in advance that the value > > of this work had no meaningful value with by-far a > > non-compliant world, was incomplete and/or was plagued > > with serious security issues, and only added this stuff for the > > most part for marketing reasons, > > I'd be careful in making assumptions like that. The last time I checked, > you weren't part of my decision making process (maybe you are for others > here). Speaking for myself, I added DK and DKIM for the same reason I added > SPF et al - because I care about the future of email which is under threat > today (and my customers do too). That's nice Arvel. Too bad you were sensitive to that statement. For whatever reasons you added support, I won't be completely off base marketing and promotion was part of your business strategy, but thats neither here or there. My only point is that if we are concern about backward compatibility now, especially for what? at most two vendors?, then we its all a moot point. Whats the point of a VERSION 2 when exploiters will just need to AVOID it? It is the same problem with have today with SMTP. If we didn't have to deal with SMTP backward compatibility and legacy issues, we wouldn't be here today. By far, DKIM and/or DK deployment is not at the levels of standard SMTP development where such issues is extremely important. But we are not there with DKIM. We need a strong DKIM system out of the gate. Not a weak DKIM system. We already have a weak system and added more ambiguity to it isn't going help weak system get stronger. Please note I don't think you need to change your software other than SSP verification which I think is paramount for DKIM success. That is my main concern with DKIM. Without SSP verification, there is little to no value in signing and/or verify mail with loose interpretations. It is the same idea with 2821.MAIL FROM. The SMTP specs has it written in STONE that Validation of the MAIL FROM is not required, hence the #1 basis for the SMTP spoofing problems and reason we are trying to find something to AUGMENT SMTP to secure the transaction. Finally, I think the WG charter, if its written to protect legacy early adopters, then what it is basically saying that the current specification, as written today, is the current BASE model. So maybe it is just a matter of rewording it to say that the current BASE specification is the current working model and moving away from this model if out of scope. However, if legacy support is not important, then we are open to modify the BASE specification. To suggest, the reason for not changing it because of a perceived installed base, I think create a loophole into the security DKIM is trying to offer. You don't need me to say this. SMTP is all the proof you need to show what unverified information can bring about. It is too late for SMTP. It is not too late for DKIM. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ ietf-dkim mailing list http://dkim.org
