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.
- 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.
Where I *do* see a use for SSP.. two places:
A. People want to use SSP for local filters policies, regardless of
whether or not DKIM is in the picture (eg, checking for SSP on
every received email).
B. A reputation service wants to keep track of an identity/domain's
SSP for whatever reason (scoring, anti-phishing schemes, blah).
Since "A" is conceivably a sub-set of "B", I'd like to see SSP become
nothing more than a way for domains to publish how they're signing.
=- Tim
----------------------------------------------------------------------
1. Intro
- "In the absence of a valid DKIM signature on behalf of the "From"
address [RFC2822] (Resnick, P., “Internet Message Format,” April
2001.), the verifier of a message MUST determine whether messages
from that sender are expected to be signed, and what signatures are
acceptable."
MUST --> MAY. In reality, my customers won't do this for every
email they receive. They'll want to control this behavior, for
whatever reason.
- "In particular, whether a domain signs all outbound email must be
communicated to the verifier."
This information should be made available to the verifier. Whether
or not the verifier retrieves the info will be optional.
- "Without such a mechanism ... unsigned messages will always need to
be considered to be potentially legitimate."
I believe there is quite a bit of existing technology in place to
determine what is legitimate, regardless of signed status. :->
SSP as-a-way-to determine the validity of unsigned email seems a
bit misguided.
- "Expressions of signing practice which require outside auditing are
out of scope for this specification because they fall under the
purview of reputation and accreditation."
SSP makes no sense to me unless I view it through a 'reputation'
lense. Without going out of scope, I'm hoping SSP describes how
either a DKIM-verifier or a reputation-agent can determine a
domain's signing policy.
-----------------------------------------------------------
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html