Murray S. Kucherawy wrote:
We tried policy, and couldn't make it work. It's time to
spend all this energy looking at something else.
Murray, I appreciate your assessment.
The writing was on the wall when you have an opponent of policy become
the author of ADSP, broken by erroneous removing all 3rd party
semantics believe that be enough the separate mail system DKIM
integration - a flaw that drove WG conflicts. There was a conflict of
interest and even then, everyone made suggestions to correct it. But
there was no interest by the editor. No one wishes to say that but
making it work was impossible. A simple change of character would of
made all the difference.
As a vendor who has strategic interest in offering DKIM trust related
eCommerce services and product features for other host to start their
own services, I can accept the design to exclude policy because it
marginalizes a 3rd party trust model. It will lower incentives to buy
into the independent trust assessment service market. I can understand
that, and if that where we want to go, fine. I accept that. No need
to hide the reality.
Bu there are engineering confusion, inconsistencies, marketing and PR
issues.
First, people reading the Deployment Guide document includes ADSP in
its introduction, discussed in 6.1 and has an entire 7.3 section
devoted to it. And when people read the security document, they will
read how policy can help
secure against DKIM threats.
So any good implementator will take all the documents into account.
And yet, the energy continues with DKIM+ADSP feedbacks work and now we
have a DKIM-BASE that intentionally neglects any promotion in any
shape or form concepts and insights regarding policy with existing
Deployment and Security guidelines or any flexibility to explore further.
From the beginning, the single main issue has always been about
controlling unrestricted 3rd party signer. No one disputed the need
for value of trusted 3rd party signers, especially for the trust
business model. The problem is that its viewed as mutually exclusive
from policy, when in fact, the two are necessary co-existing layers.
Policy helps the trust model, and trust helps policy because policy
can not deal with good looking bad guys.
DKIM needs both to be successful. Again, I understand the reasons to
exclude it, and its not about lack of technical merits. I'm proposed
a simple compromise with two words that will not marginalized the
trust market, but help it, help the marketing, help the PR problems.
Also, remember, DKIM has a term tagged to it regarding
"Responsibility" so by keeping ADSP in the Deployment Guide and
Security Documents, there are product liability concerns. While
High-value targets may not add ADSP records themselves, but they might
need to check for it because intentional neglect is a realistic risk.
Having it is not a problem because it also serves as an disclaimer.
History tells us that ignorance is the root of all conflicts. So why
try to ignore and hide it in RFC4871bis?
But if we really think it won't work, then we should at least try to
be consistent and clean up all DKIM related ADSP deployment and
security guidelines - the RFCs need to be updated and it wouldn't make
sense to continue related work with ADSP reporting. Or can be done
right and add a few words regarding its presence.
Microsoft has announced support for ADSP checking. This is an very
significant event. This should not be ignored.
Anyway, sure, a lot of wasted energy is here. But it pretty much based
on your key cogs conviction. If you believe "authorized signer" is an
natural identity for DKIM, then you should propose it and see hows it
goes. Maybe the policy people can come out for wood works.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html