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

[John C Klensin <[e-mail]>]

--On Wednesday, May 14, 2014 19:20 +0200 Alessandro Vesely
<[e-mail]> 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