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> Sat, 17 December 2016 15: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 AEDA312947D for <ietf@ietfa.amsl.com>; Sat, 17 Dec 2016 07:15:01 -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 A671z6N02AvD for <ietf@ietfa.amsl.com>; Sat, 17 Dec 2016 07:15:00 -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 61C1B1293DB for <ietf@ietf.org>; Sat, 17 Dec 2016 07:15:00 -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-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=i8j8kRIONjGQkAQUthFV7gsuHbW48JX+Nx5WEqYFrWs=; b=mi++/P3lHEYIiX+I2mC7cHMpXoNec/hJzWnvGNlNX2OPW4DZHMdkzLWMfO+M3DiAaNtfPy8VF5hCSZguR0QcrB0rXQ81a//CGyBEtc86fPlIWMHUja1AKL7C3xgFUDrlUgPSQmqYjfnFLaEdBO+WLolUSNahH7CQW5VeCtzRlYA=;
Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.84_2) (envelope-from <tytso@thunk.org>) id 1cIGhN-0005TO-Vu; Sat, 17 Dec 2016 15:14:58 +0000
Received: by callcc.thunk.org (Postfix, from userid 15806) id 5E289C00665; Sat, 17 Dec 2016 10:14:51 -0500 (EST)
Date: Sat, 17 Dec 2016 10:14:51 -0500
From: Theodore Ts'o <tytso@mit.edu>
To: Yoav Nir <ynir.ietf@gmail.com>
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: <20161217151451.hx5co6mjqmi2jakg@thunk.org>
References: <25431.1481725548@obiwan.sandelman.ca> <5EF6F271-1CF7-4981-8E83-C7A7B49DB8F2@gmail.com> <CDE8A76C-ECD7-4370-9823-3C78144A8850@nohats.ca> <24005.1481827604@obiwan.sandelman.ca> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6D2E8F8E-1B02-46EA-B202-D23E5385CFF5@gmail.com>
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/-HxpRjpk0IN3mrptJJi2kRqmYdU>
Cc: ned+ietf@mauve.mrochek.com, IETF Disgust 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: Sat, 17 Dec 2016 15:15:02 -0000

On Sat, Dec 17, 2016 at 03:20:17PM +0200, Yoav Nir wrote:
> 
> It’s hard to move the pain in a predictable way. If I send you an
> email message and it’s not delivered or gets mangled or goes in your
> spam folder, who feels the pain? That depends on which of us needs
> the email more.

The primary problem is that DMARC is fundamentally flawed, and was not
enacted using a standards process that respected all of the
stakeholders.  As a result, it fundamentally becomes a matter of power
politics.

If there are a bunch of people who need to participate in a particular
mailing list --- say, IETF mailing list or the Linux Kernel
development lists --- more than they need to stick with a particular
mail provider, it becomes possible to say to them, "you want to
participate in our community"?  Change mail providers.

In the cases where a mailing list community badly needs the Yahoo
users, Yahoo can dictate to the mailing list --- change your mailing
list software and inflict pain all off your mailing list users, or you
don't get access to our e-mail user community.

> The group you want to feel the pain are the administrators who add
> DMARC records, but other than spamming them with error reports,
> there’s not much we can do. I don’t think the administrators at
> Yahoo care too much whether their users are able to use IETF mailing
> lists or not.
> 
> As a proxy we can “punish" those senders who have a DMARC record for their domain. 
> 
> If we do nothing, their messages sometimes get lost. They have real
> problems participating effectively in the IETF unless they switch to
> using gmail or hotmail accounts like many of us have already
> done. But that gives us pain as well because we’re missing messages
> as long as they keep using their own accounts.

Yeah, it's the "sometimes mail gets lost" problem which is the main
issue.  So it might actually be better to have the mailing list
software refuse to accept a mailing list posting from a domain with a
DMARC record, and it can be bounced back to the sender immediately
with a "sorry, try again using some e-mail address that does not have
DMARC support".

But again, doing this fundamentally is a game of power politics ---
just as DMARC being inflicted on the entire e-mail ecosystem was a
matter of power politics.

Cheers,

					- Ted

> If we apply the mitigations only to such accounts, we solve the
> bounce issue, but then depending on the solutions we poison some of
> the other participants’ email addresses, or we make the UI show
> weird unhelpful things. Seems like everybody else gets the pain.