Re: not really to do with Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)

[Hector Santos <[e-mail]>]

> On Jul 16, 2014, at 7:49 AM, Scott Kitterman <[e-mail]> wrote:
> 
>> On July 16, 2014 12:55:00 AM EDT, Dave Crocker <[e-mail]> wrote:
>>> On 7/15/2014 8:55 PM, Scott Kitterman wrote:
>>> I think, despite all your assertion by distant authorities, it may be
>> that 
>>> something involving U/I requirements (not design, I agree that's out
>> of scope) 
>>> may be part of the least bad solution we have to the problems the WG
>> is going 
>>> to be chartered to solve.
>> 
>> 
>> 1. What sort of 'proximity' do you require, before you can be swayed by
>> authoritative information?
>> 
>> 2. By 'least bad', it appears that you mean it is ok to standardize
>> something that is known not to work, to the extent that the end user is
>> expected to be part of the decision process.s
> DMARC is already fielded and being standardized. Much of the work of this WG is about mitigating the side effects of this. So in this case, least bad solution still wins (which may be write a BCP and declare victory,  I don't know).
> 
> DMARC itself is already known not to work for common standard mail flows.  This is an effort that is devoid of solutions that don't have at least some significant downside. The working group is going to have to figure out which downside hurts the least. 
> 

-1.  The simplest solution has always been the policy lookup with the language to support all the boundary conditions.  This is the most feasible protocol complete solution.  The policy themselves, which must be all honored for this to work, will vary in effectiveness, it's payoff.  The more relaxed, the greater the redundancy and waste you have in the process. The higher the strength, the higher the payoff, including the pains of restricting the resigner who wishes to continue to exist in the blind.  The problem is not in the concept, but that DMARC was never protocol complete. Its reporting offered the "confirmation" for the proof of concept, but it was done on the basis that "no one" will ever enforce this stuff.

The resistance seems to be a learning and "big data" problem among the fewer but larger ESP.  This should be a separate WG or DKIM data work.

This small group already seems to have lost the focus of what the problem always was and the 9 years of vested R&D.   Work thrown out by a very unpopular rough consensus was wrong in their mail operations presumptions.  At the very least, the charter should revisit the threat analysis RFC and the functional requirement RFC to see where it went wrong and corrections are made.  I maintained the 1st vs 3rd party corollary added in rfc5016, section 5.3 item 10, created the genesis of the conflict we have today.  This problem will not go away until we confront this conflict.

--
Hector Santos
http://www.santronics.com