Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
In sum, I think the SSP-req doc should say "SSP must be published
by DKIM signers, and the format is <this>".
Disagree, dkim base works now. There will be people that will move very
slowly into implementation and requiring SSP to be implemented at the
same time will slow adoption.
I'm not sure this is accurate. I'm sitting on top of a large
list of customers who want DKIM, and they want it yesterday.
In other words, concern around slow-adoption rates seems a bit
alien to me.
My understanding (trying to stay on topic with SSP-req); again,
I'm just trying to share my perspective for the rest of the WG:
- SSP can be completely dropped, and DKIM will still be worth
something to me. I'm OK with this outcome (if it means no
more time will be spent on SSP).
- If SSP is going to be something other than an ignored add-on,
then SSP-req/DKIM-base needs to have language describing
that, if a signer does not publish an SSP record, the assumed
default will be <whatever>. I did a bad job articulating this
by writing "SSP must be published by DKIM signers".
EG, with a default of "i sign some", the majority of adopters
won't need to do anything (they SHOULD, to make SSP queries
resolve). This also means that a signer understands that one
day they can publish "i sign everything" when/if they ever do.
- From my POV, SSP records can be as simple as
"No-sign/sign-some/sign-all". At this point in time, I see
little if any interest in per-user SSP granularity.
- All the language in SSP-req around how a verifier should
handle mail can be axed. Specifically, the information
advertised by SSP should stop at "I (do/do not/partially)
sign". Adding ".. and therefore you should treat unsigned
email from me as suspicious" might seem useful, but the
unenforcible nature of this only adds confusion.
Hmmm. I suppose the above points describe my SSP requirements.
If the WG deviates from this list, I cannot guarantee overnight
adoption rates. :-P
=- Tim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html