On 10/26/2014 10:10 AM, Murray S. Kucherawy wrote:
On Fri, Oct 24, 2014 at 2:17 PM, Stephen J. Turnbull
wrote:
Hector Santos writes:
> POLICY has been reestablished as the DKIM framework long ago.
I have no clue what this sentence means. What is "POLICY"? What is
"the DKIM framework"?
For any definition of "the DKIM framework", the claim is incorrect. DKIM
has never had policy inherent within it since it was published. ADSP and
ATPS are failed experiments to add some.
This is MY VIEW as an external long time participant with early
explorer SPF/DKIM add-on products in our mail system. Nothing
personal nor negative intended, especially towards you, but you are in
fact the "leader" and in charge of this work.
DKIM had its origins from Domainkeys (DKEYS) which had a built-in
POLICY framework Murry. DKIM, when it was first released, also carried
over the built-in policy framework and it public domain APIs with API
functions "hooks" for POLICY logic. DKIM had an expanded set above and
beyond what DKEYS offered. For the most part, the specs and API
reduced the functional logic to:
IF DKIM.VALID and DKIM.SIGNER.DOMAIN != FROM.DOMAIN then
LOOKUP AUTHOR POLICY FOR EXCLUSIVE/RESTRICTIVE OPERATIONS
Thats no claim. Thats a public domain API fact with original API
libraries for DKEYS and DKIM. It is an historical, public domain fact
and there shouldn't any debate about its origins nor how it been
reestablished with your new published draft DMARC work. The concept
of policy is peppered all over the document. There should be no
dispute DMARC is a "DKIM Policy Framework" or "DKIM Policy Protocol"
or "DKIM Policy Specification" or "DKIM Policy Layout" whatever other
terminology we wish to use.
DKIM had two frameworks -- a POLICY and TRUST and there lied the long
time problem and continued conflict when in fact, DMARC itself is
about POLICY and DKIM STD is about TRUST. When Policy was removed
from the DKIM RFC/STD work and replaced with TRUST. Folks were warned
of the mistake to inherently exclude the Author Domain Identity (ADID)
from the assessment algorithm (remember that discussion?) and we are
here today because it was left out, trying to reestablishing it via
DMARC.
Finally, Its easy to dispute ADSP/ATPS as "failed experiments" by the
fact it wasn't giving a chance at all. In other words, the effort
didn't have the proper both project/product development champions and
the fact that DMARC is being adopted and now discussed, proves the
Proof of Concept (Policy in principle) had never gone away and it is
still alive and well. It won't go away either as it should finally
realized by now. Call it any name we want -- it is a DKIM POLICY
framework and we should save time by recognizing this fact and develop
the proper tools to allow the world to adjust to it.
Its unfortunate the DKIM progress for both an integrated TRUST and
POLICY framework has been held back for some time now. Policy was
always the first layer (expectation), TRUST was always the second
layer (valid signature true). But DKIM project leaders pushed for
TRUST only which the POLICY advocated warned that was going to be a
problem in the future -- and it did, hasn't it? But ignoring POLICY,
we weren't ready for it. I should note, that DMARC repeated what
Levine did with ADSP -- ignore all 3rd party control concepts in an
attempt to reduce conflicts with 3rd party resigners. I think it
should be determine asap if 3rd party policy ideas are in fact going
to be developed for DMARC, and by that, I mean, you PUSH IT, You
CHAMPION IT. Otherwise it ain't going anywhere for awhile.
It shouldn't had never been a difficult total TRUST/POLICY integrated
product solution and since the same folks are behind it, well, its
progress seems to be in a status quo direction for its future.
Not a negative towards you, you are doing good work for all the work
you do. But it does seem to be too much and overwhelming. You need
help. No doubt. But thats also a management problem. So, I'll leave it
at that.
I really hope you guys moving with this.
--
HLS
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
