> On Dec 4, 2007, at 3:45 PM, Arvel Hathcock wrote: > > SSP offers itself as a means to detect unauthorized domain use. > > That is sufficient incentive for adoption by receivers. > > It doesn't provide a reliable means to detect unauthorized domain > use. That alone is sufficient reason for receivers (and many > senders) > to be skeptical about deployment. Myself and many others believe it offers a means to detect unauthorized domain use that justifies its use. I believe it is reliable "enough" but of course it's not 100% reliable.
We disagree on this point but this isn't a problem at all as we can both have our way with SSP: - I encourage and support skeptics like yourself to avoid use of strict/deny policies and to disregard the use of strict/deny policies. - I encourage those agreeing with Arvel, myself and many others to use strict/deny policies as appropriate as a means to detect unauthorized domain use. Everyone can make their own decision about the applicability and utility of this technique and vote with their SSP policies. Take strict/deny policies away from your mail stream but please don't take strict/deny away from proponents' mail stream because you don't think it's reliable enough. > How unreliable it is we don't know yet, but until we have more > operation experience with DKIM it's reasonable to assume the worst. * see comment below > If it starts being deployed and we discover that the SSP false- > positive rate is too high we'll lose a huge amount of time rolling > back deployment of SSPv1 and working on a more realistic SSPv2. No. If someone chooses a strict/deny policy and it has a high false-positive rate receivers can simply ignore it as you are planning to do. If someone deploys strict/deny and finds it has a high false-positive rate they can change to unknown/process. A change in SSP policy is all that's necessary, not a new SSPv2. > The SSP false-positive rate will be driven primarily by the DKIM > false-negative rate. As that's a critical piece of data needed to > complete the SSP design to a level of quality suitable for > widespread > deployment the wisest course of action would seem to be to > wait until > we have wider DKIM deployment and more DKIM operational experience, > and then to gather that data. * taken together with unreliable comment above... Yahoo and PayPal have done the largest scale implementation of a back-channel strict/deny for DK. PayPal spoke at MAAWG on their success and said he had business benefit. The false positives would be much lower with DKIM than with DK. Other banks have deployed DKIM and found the FP rate to be acceptable to them based on their criteria. I believe the DKIM interoperability summit is the largest test of this kind and results were encouraging. There was no official pronouncement or false positive measurement but I believe the results didn't leave anyone to believe driving the FP rate to an acceptable level was not possible in the near future. Here's the closest thing I found to a DKIM reliability pronouncement: http://dkim.org/news/DKIM%20Interop%20Event%20PR%2011_06_07.htm "We have demonstrated that DKIM is easy to add to an email service and that its use of cryptographic technology provides a strong basis for knowing received email really is associated with the organization that claims to have sent it." - Dave Crocker (quote excerpt) "We learned a lot by participating; not the least of which is that DKIM just works," said Arvel Hathcock, Founder and CEO of Alt-N Technologies, and host of the event. "The testing performed by all participants revealed no significant barriers to adoption or use." http://altnblogs.com/arvel/ Finally, I was struck by just how well this DKIM stuff actually does work. It really does deliver as advertised and we found no significant technological problems which would hinder adoption or deployment. If you have better data on DKIM reliability please share. Of course if you think it's unreliable then publish unknown/process for mail you send and ignore SSP for mail you receive. pat _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html