Murray S. Kucherawy wrote:
-----Original Message-----
I can break it down by month if anyone's interested in trend
data, but the numbers are so small in the first place that I
doubt it'd be very interesting.
So we can't tell how widely ADSP has been deployed because we
don't check in the positive case, but we can see how it looks
in the negative case: It's successfully "protecting" 0.13% of
the domains out there.
Which is still higher than how SPF started out, yet, SPF took off due
to its high promotion. Since there is no promotion of ADSP, watered
down, and it was made harder to deal with 3rd party scenarios, with
the refusal to make the necessary corrections, IMV, the exploration
has becomes questionable and limited. We have to promote it if we
want to properly measure its adoption.
Data collection is always useful, but it generally doesn't tell the
real story across the board because everyone's personal/business
community network are different. You have to show a statistic analysis
because the majority non usage reasons are untold and does not
necessarily takes away the benefits and the well established proof of
concept and realistic payoff possible. It is very well proven to be
useful for those who have these stronger signature needs.
Interestingly, what would be an adoption percentage before it is taken
serious?
Adoption is really three parts:
1 [X] Verifier ADSP Implementation Readiness
2 [_] Verifier ADSP Deployment (checking) Readiness
3 [_] Domain ADSP declarations
Looking at just current APIs, it is 100% adoption. The current APIs
readiness is due to when policy was still a strong focus starting with
SSP and they were updated to support ADSP. The harm of removing
policy semantics in RFC4871bis is that we will begin to lose this
implementation readiness. Not having any ADID Policy Identity
Assessor insights dangers future implementations from having this
readiness.
Deployment Readiness is whether the operators have ADSP checking
enabled. Because of the short term DNS low efficacy factors, it is a
high consideration to have it disabled by default. That could change
as Domain ADSP declarations increased. But we don't know how
different implementators have made it available. Of course, this will
be an non-issue when implementators stop coding for it or never code
for it and don't offer it at all - the danger of removing the
semantics in RFC4871.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html