----- Original Message -----
From: "John Levine" <johnl(_at_)iecc(_dot_)com>
- If SSP is going to be something other than an ignored
add-on, then SSP-req/DKIM-base needs to have language
...
No way.
There is enough operational experience with DK that we can
be confident that DKIM will do what we expect it to. SSP,
on the other hand, is purely a paper design with no
operational history at all.
The SendMail DKIM-SMILTER public API has SSP support built-in. Therefore any
implementations out there using this API, it would have direct field
testing and operational history.
What you are wishing to say that you haven't seen (or wouldn't know) anyone
published SSP policies other than the default o=~ (Optional Signature)
Policy. The fact is, every DKIM domain I have tested up to this point has
a SSP policy published. So you are obviously wrong in this respect.
Hnmmmmmmmm, isn't this the same problem with SPF? Everyone (the majority)
publishing a NEUTRAL policy that it made SPF practically useless?
I would rather use direct correlations and real operationl history based on
similar concepts such as SPF, to have enough insight to see history will
repeat itself here with DKIM using neutral policies or NO SSP (therefore
NEUTRAL by default).
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html