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