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

John C Klensin <john-ietf@jck.com> Wed, 14 May 2014 12:39 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794F01A0075 for <ietf@ietfa.amsl.com>; Wed, 14 May 2014 05:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level:
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzRvfFVMM_IQ for <ietf@ietfa.amsl.com>; Wed, 14 May 2014 05:39:53 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1171A0068 for <ietf@ietf.org>; Wed, 14 May 2014 05:39:53 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WkYTD-000JXZ-Dw; Wed, 14 May 2014 08:39:39 -0400
Date: Wed, 14 May 2014 08:39:40 -0400
From: John C Klensin <john-ietf@jck.com>
To: Alessandro Vesely <vesely@tana.it>, ietf@ietf.org
Subject: Re: DMARC-4-ML: Can the IETF call a demonstration?
Message-ID: <0168AF240FBAEFE4174A1B21@JcK-HP8200.jck.com>
In-Reply-To: <537358E1.8060101@tana.it>
References: <537358E1.8060101@tana.it>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/N9xkpW7NeoPIoBLx935hv3SJkiw
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 12:39:56 -0000

--On Wednesday, May 14, 2014 13:52 +0200 Alessandro Vesely
<vesely@tana.it> wrote:

> After some discussion on ietf-822, two viable methods were
> identified for DMARC for mailing lists (ML).  Someone cutely
> suggested to do both:
> 
> *Tweak DKIM signatures*
>...
> *Whitelist*
>...
> Both methods require each domain to build a DB of MLs.  That
> can be done by a "manual process" (see picture) for the time
> being.  The process consists of each ML admin extracting a
> per-domain list of subscribers and sending it to the relevant
>...
> Will the admins go marching in?

Ale,

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.  

(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.

(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.

> Doing nothing will result in a mix of three reactions.  1, ML
> admins changing the From: of domains who publish strict DMARC
> policies;  2, some users changing mailbox provider; and 3,
> less domains publishing strict DMARC policies.  

There are two more options you didn't mention: (4) more systems
either not implementing DMARC or ignoring strict policy
specifications, and (5) driving some users and activity away
from the use of mailing lists entirely in favor of using more
"social network" web sites and activities.  I note that some
people believe that DMARC and strict policies are part of a
business model to force that result.  I don't believe that
personally, but the optics are unfortunate.

> 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.  

The analogy is obviously not exact, but, if some external group
came up with a protocol that weakened TCP and undermined all of
our congestion control mechanisms, we might be pointing out the
damage and encouraging people to not use that protocol --
perhaps even figuring out ways to block its use -- but would not
be scurrying to alter TCP to better accommodate the behavior of
that new protocol, especially if the alterations made "normal"
use of TCP less efficient or effective.

   best,
   john