----- Original Message ----- From: "John Levine" <[EMAIL PROTECTED]>
>>- 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
