Folks,
I think that Michael has done quite a good job of capturing much of the
detail that has been discussed.
However on reviewing the current draft, I am struck by the absence of
any text that describes the actual purpose of SSP, other than in terms
of essentially reflexive detail.
"The most pressing case seems to be the
bid down attack inherent with almost all systems that allow optional
authentication: how does a receiver know whether or not it should
expect a message to contain authentication information?"
That is, we do not have a general, motivational statement for SSP.
I believe that, in fact, the working group has not settled on clear,
precise benefits goal(s) and that, therefore, it makes it difficult for
the working group to develop consistent technical requirements.
By way of priming the pump here is my own attempt to remedy this:
Potential DKIM signers wish to assist receive-side message
evaluation systems by publishing information about the messages
that they originate and possibly sign. The primary basis for
determining what practices to specify is a strong indication that
receive-side processors have an interest in using the information.
As always, other major factors include potential performance and
reliability impact upon message handlers, and other system
operators.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html