On Jul 16, 2014, at 7:49 AM, Scott Kitterman <scott(_at_)kitterman(_dot_)com>
wrote:
On July 16, 2014 12:55:00 AM EDT, Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
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