Interesting thoughts...comments inline.
Tim Draegen wrote:
Dave Crocker wrote:
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.
I'm not sure if my feedback warrants a "new issue", as Dave Crocker
brings up my main concerns. Maybe my comments can be added to Dave's
existing issue. Feedback is below -- but first I need to clarify where
I'm coming from.
My understanding of how SSP is to be used is rooted in two distinct
areas - 1. building high-volume email servers, and 2. building a
reputation service. Some factoids:
- My largest customers will not deploy DKIM verification if it
requires making a DNS query (or two) for every single non-signed
email that they receive. Even if it makes no real-world difference,
some people just won't do it.
I don't understand this. Many people routinely do reverse DNS lookups
on the IP address from which messages are received, SPF checks (which
can be several lookups), and so forth. Why the sensitivity to
additional, potentially well-cached lookups?
- DKIM only makes a difference to me if a successful verification
occurs. Everything else is essentially noise. Even with a good
verification in place, I need other information to determine whether
or not the verified identity is a friend or foe. That other info
is appropriately out of scope for DKIM & SSP.
- I do not need SSP to arrive at a 'good verification' conclusion.
Since all I care about it a 'good' result, SSP doesn't add enough
value to warrant the MUST language that currently exists wrt
verifiers querying for policy.
There's a lot of question how much "teeth" these requirements on the
verifier have. We used the stronger wording to encourage "compliant"
implementations to do SSP, because a lot of the reason for publishing
SSP goes away if it is going to be ignored. But I expect that it will
be up to the individual customer's choice, just as it's possible to turn
certain classes of checks on and off in SpamAssassin.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html