ietf
[Top] [All Lists]

Re: DMARC-4-ML: Can the IETF call a demonstration?

2014-05-14 12:37:02


--On Wednesday, May 14, 2014 19:20 +0200 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:

John,

On Wed 14/May/2014 14:39:40 +0200 John C Klensin wrote:
--On Wednesday, May 14, 2014 13:52 +0200 Alessandro Vesely
wrote:

Will the admins go marching in?

At the risk of repeating myself...

(1) I think it is a bad idea for the IETF to be formally
spending effort to work around damage caused by a non-IETF
protocol.   I note that, if this were a protocol that was
specified in the IETF and over which the IETF had change
control, we would be trying to fix the protocol itself or
would withdraw or depreciate it because of the damage caused.

That sounds like yet another instance of the not-invented-here
syndrome.  FWIW, much the same solutions were put forward for
ADSP. IETF or non-IETF, the difference seems to be that DMARC
currently has more traction and deployment than ADSP ever had.

No, it is not NIH.  It is that the IETF has no change control
over DMARC and hence does not have the option of controlling the
damage by withdrawing or adjusting the protocol itself.  There
is no plausible reason why the IETF should be forced into the
role of policeperson for protocols developed elsewhere or,
worse, in aiding those who created a protocol elsewhere in their
(I hope accidental) efforts to inflict pain and costs on others
in the community in order to make their systems work better.

(2) I believe it is unacceptable for a new protocol or
capability to impose costs on operators of other systems in
the absence of clear and broad consensus about why the
changes are needed and appropriate. That consensus may well
exist for DMARC and its policy statements among the
contributors/ supporters of dmarc.org, but it is fairly clear
to me that it does not exist in the IETF.   Contrast that
with, e.g., privacy issues about which there have been
consensus statements in the IETF, perhaps even statements
strong enough to justify some additional costs.

Getting a rough gauge of consensus is exactly the reason why I
wrote.  I'm less confident than you on the opinion of DMARC
people, since a change in DMARC is implied.  I noted some
inclination toward reasonable changes from a few ML admins on
this list, though.

Let me make explicit it is not consensus on DMARC we're
talking about.  It is consensus on the workaround and the
demonstration.

And I am suggesting that, if you want to initiate a proposal for
work on damage control wrt DMARC, nothing prevents you from
proposing that as a work item for some existing WG or a new WG.
I have no opinion about the "opinion of DMARC people" re a
change in DMARC.  IETF does not have change control, so the
question of their opinion is irrelevant.  If IETF did have
change control, their opinions would be part of the general
community consensus... or not.
 
(3) Since I mentioned privacy, I should note that developing,
keeping, and maintaining the database you mention could have
significantly more privacy risks than simple recording of
envelope information in server logs.  If IETF is now committed
to privacy as a significant goal, that question needs careful
evaluation.

That's why the DB has to be build by hand.  Although I doubt
it is realistic for users to hide out from their mailbox
providers, I agree special care is needed.  For those who
trust their mailbox provider, it is convenient to have it
control their subscriptions.  A possible method to automate
that task was called water-tight-opt-in[1].

As you suggest, building by hand only changes the "who do you
trust and about what" equation.  If someone felt forced to
switch email providers because they trusted their provider to
handle mail but not to keep databases of lists subscribed to,
that would be another instance of the design of DMARC and those
specifying restrictive rules imposing costs, perhaps significant
ones, on others.

...
The combined effect seems to weaken both DMARC and mailing
lists.

So?  Perhaps we should be focusing more on strategies that
weaken DMARC to the degree necessary or appropriate without
weakening mailing lists or imposing added costs on those who
operate or subscribe to them.  

I'm not sure it would be good to go for a head-on collision,
even if we were granted getting out safe.  For another inexact
analogy, we let SPF die down that way.  Had we agreed on a
viable compromise, perhaps we would have enjoyed less spam,
who knows?  Now DMARC comes harder. The question is when the
next will come, and whether it will be so better as to be
worth the while.

Again, from my perspective, the question is whether the IETF
actually has responsibility for protocols for which there has
been no effort to obtain IETF consensus and over which the IETF
does not change control.  Until and unless some process decides
that the IETF is in charge of the Internet and allocates
Protocol Police to enforce IETF policies over things it didn't
create, I think the answer to that question has got to be "no".

best,
   john