Re: DMARC methods in mailman --- [LEDE-DEV] DMARC related mass bounces / disabled subscriptions (fwd) Jo-Philipp Wich: [LEDE-DEV] DMARC related mass bounces / disabled subscriptions

Theodore Ts'o <tytso@mit.edu> Sun, 18 December 2016 04:15 UTC

Return-Path: <tytso@thunk.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FE8129451 for <ietf@ietfa.amsl.com>; Sat, 17 Dec 2016 20:15:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thunk.org
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 r1UjXzNPupD4 for <ietf@ietfa.amsl.com>; Sat, 17 Dec 2016 20:15:48 -0800 (PST)
Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764521293DC for <ietf@ietf.org>; Sat, 17 Dec 2016 20:15:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=jbhO2MW8TStU1aw/+DM+FGaHsLGbVhOLH/FRGzpBnN0=; b=Aje8hSYxSrWVl73RdgcAoCYXPCmAuGwr0lO8+sq6/Gv67/vcQ36SKzeewRqyT0l6ckcVGIoNYsNrHFgMiQ8WiyT3xVCG9DEQst9rJ4YsdTfAcNUHYyYC1xDLxXeiqtJSzFVwX786M1qHW1VnZ65tMXm8G3ZS7RcfvRtmDMJJOhE=;
Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.84_2) (envelope-from <tytso@thunk.org>) id 1cISt0-00028c-5u; Sun, 18 Dec 2016 04:15:46 +0000
Received: by callcc.thunk.org (Postfix, from userid 15806) id E5E21C0068C; Sat, 17 Dec 2016 23:15:44 -0500 (EST)
Date: Sat, 17 Dec 2016 23:15:44 -0500
From: Theodore Ts'o <tytso@mit.edu>
To: dcrocker@bbiw.net
Subject: Re: DMARC methods in mailman --- [LEDE-DEV] DMARC related mass bounces / disabled subscriptions (fwd) Jo-Philipp Wich: [LEDE-DEV] DMARC related mass bounces / disabled subscriptions
Message-ID: <20161218041544.jitn4ts5nxz2dpzy@thunk.org>
References: <alpine.LRH.2.20.1612151513060.15183@bofh.nohats.ca> <20161216202704.glz5vgu773gqqgvm@thunk.org> <20161216203905.GD13486@mournblade.imrryr.org> <01Q8KHVOKE2C011H9Q@mauve.mrochek.com> <m21sx6u8sb.wl-randy@psg.com> <6D2E8F8E-1B02-46EA-B202-D23E5385CFF5@gmail.com> <20161217151451.hx5co6mjqmi2jakg@thunk.org> <13749.1482005985@dooku.sandelman.ca> <fe75a2a0-6127-d29a-8259-a82ddbbc966f@gmail.com> <77efae9d-a550-af05-4194-809887f5cc9d@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <77efae9d-a550-af05-4194-809887f5cc9d@dcrocker.net>
User-Agent: NeoMutt/20161126 (1.7.1)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/UdB6-fPp_UNhFW2Y-9zfegGyuzg>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 18 Dec 2016 04:15:49 -0000

On Sat, Dec 17, 2016 at 06:38:07PM -0800, Dave Crocker wrote:
>    4. The folk using DMARC for c2c are not seeing a significant problem from
> that use and they do report significant benefit.  Sitting here in the IETF,
> we might not like their assessment, but it's their business, not yours or
> mine.

Right, the problem is not with c2c, where the affected mail might be
0.5%.  But for d2d (developers to developers), it's much more serious.

>    5. The IETF has no meaningful leverage over those service providers.  Any
> thoughts about what to do should keep that in mind.

That's been clear.  To the extent that though that some service
providers might want to have developers stay on their platform because
they might be powerful influencers, there might be *some* influence,
but it is admittedly very little.

>    7. The providers' affected users have no leverage on their providers.
> None.

Well, it *might* be that Google might not appreciate headlines of the
form, "Linus Torvalds is leaving gmail because Gmail has become
fundamentally incompatible mailing lists", but it is again,
admittedly, very small.

>    8. It is easy to tell those providers' users that they should go to a
> different provider, but take a look around for choices of consumer email
> providers:  there are precious few choices on the Internet today. And for
> the affected consumers, they need a free, well-run provider who operates at
> scale.

So what we might end up with, in the long run, is mailing lists will
only work with developers who switch to mail services such as, for
example, fastmail.fm.  But there might not be mail services for
consumers that are compatible with mailing lists.  That would be sad,
in that it would involve a partial fork of the Internet mail system,
one for Eloi and one for the Morlocks, using Neal Stephenson's analogy
from "In the Beginning Was the Command Line".

But again, as you have said (and I agree) we have no control over the
big mail providers.  The only thing we have control over is any
mailing list servers we might happen to have administrative control
over, and what kind of pain we want to inflict on our particular
developer community (whether it is standards development or open
source development).

>    9. ARC is expected to help this situation, but I suspect it won't be as
> much help as anyone would like.  At the least, it requires adoption by both
> the mailing lists and the receiving MTAs, and that's a lot of adoption to
> require.

I have the same worry that ARC may not do as much to help as has been
hoped.  Certainly not in the short term.  That's because it won't just
be mailing list servers that will need to adopt ARC, but also mail
forwarding services such as those used by alum.mit.edu,
alumni.stanford.edu, linux.com, etc.

Basically, DMARC is a classic tragedy.  It's playing out in a fairly
inevitable fashion, and there's nothing we can do to change the basis
of the tragedy; only how we react to it.

I suspect the best in the DMARC world where ARC turns out not to be
completely successful is a setting where mailing list recipients can
specify whether their mail service honors DMARC requests, and if it
does, *and* if the sender is one that has a DMARC policy, the From
field will have to get mangled, and if that screws up the recipient's
Yahoo or GMail contacts database, it will be up to that mail provider
to decide how to deal with it.

						- Ted