Re: [dmarc-ietf] wiki vs. list?

[Hector Santos <[e-mail]>]

On 10/26/2014 10:10 AM, Murray S. Kucherawy wrote:
> On Fri, Oct 24, 2014 at 2:17 PM, Stephen J. Turnbull <[e-mail]>
> 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