The recent new bombardment of A/R considerations is undermining SSP
efforts. I hope this note serves as food for thought for anyone that is
really focus on a A/R.
I think SSP is not about Reputation and Accreditation (A/R).
But this is not a note on what SSP is but rather how A/R proponents
SHOULD support SSP, not necessarily within its product offerings, but
rather in helping to lowering the adoption barriers and get more people
into the market to use DKIM.
Like many other product vendors here, A/R concepts is already part of
the package. It is just a layer among other things.
We are eager to add DKIM but not without public domain, IETF standard
policy protocol augmenting DKIM to help address the DKIM base protocol
consistency issues which A/R systems does not address and doesn't have too.
It is to benefit of any A/R vendor or would be vendor that has already
has DKIM or is planning to use DKIM, to endorse SSP as a fall back and
default solution to address some really basic DKIM protocol usage
exploits that are completely external to any ideas regarding reputation.
So I am throwing these recommendations from a technical sales standpoint:
1) A/R systems should endorse public domain IETF standards
DKIM/SSP efforts, not hinder it.
2) A/R systems should leverage the benefits of DKIM/SSP, and
even offer an alternative discovery process.
3) A/R systems should come together with some common protocol
to offer a different discovery process for A/R information.
This part is highly critical if DKIM is to become a wide
used general mechanism in the network.
The last thing we want, because we been through this before and do not
want to go this again, is to add DKIM support with a "Batteries
Required" concept which means that we MUST document that DKIM will not
work unless the customer subscribes to a external non-IETF related
protocol A/R service bureau.
DKIM must be able to offer some basic functional benefit and DKIM-BASE
does with 1st party valid signatures.
But DKIM-BASE is highly exploitable without some basic protocol
consistency wrapper that I believe SSP does offers.
That is why I am so confident about it. I truly believe it will help.
But this does not suggest nor eliminate the idea for any additional
white/black "Trust" concept either local or 3rd party.
I just think it would be unfortunate if we lock in DKIM-base with 3rd
party A/R concepts. I think it will be a recipe for low general acceptance.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html