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
John C Klensin <john-ietf@jck.com> Sat, 17 December 2016 19:55 UTC
Return-Path: <john-ietf@jck.com>
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 166731296EC for <ietf@ietfa.amsl.com>; Sat, 17 Dec 2016 11:55:21 -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, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
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 S4jmpuuN0K4a for <ietf@ietfa.amsl.com>; Sat, 17 Dec 2016 11:55:19 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC7C129449 for <ietf@ietf.org>; Sat, 17 Dec 2016 11:55:19 -0800 (PST)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1cIL4d-0007cD-CE; Sat, 17 Dec 2016 14:55:15 -0500
Date: Sat, 17 Dec 2016 14:55:09 -0500
From: John C Klensin <john-ietf@jck.com>
To: Theodore Ts'o <tytso@mit.edu>, 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: <9AD6AAD6812D3B9F8379226B@PSB>
In-Reply-To: <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> <20161217151451.hx5co6mjqmi2jakg@thunk.org>
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.70
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/WJe7E1bIs1ePcA2sJQSm_sk1KL0>
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 19:55:21 -0000
+1. FWIW, I have to agree with Ted here. When a large mail provider knowingly and unrepentantly does something that violates well-established and well-defined standards and fouls up mailing lists for others, especially when that provider also, within their business model, pushes a "forum" service that is an alternative to those mailing lists, and then effectively says "everyone else needs to adapt to what we are doing", we should not be rushing to make the Internet worse by adapting to those moves. If that large provider joins with other large providers to either develop the technique or push it on others, that is known in some countries as a conspiracy in restraint of trade, and, again, not something about which we should be participating or abetting. If the net effect is that users of that provider's systems have to find another mechanism to participate in IETF work, that is the fault of the provider, not the IETF. And, as Randy indirectly mentioned, if that provider has repeatedly been the victim of attacks that compromise user information at very large scale, we may sympathize with them as victims (even through failure to notify the people whose information was compromised for months should reduce the sympathy level somewhat) but, if any action by us is called for, it is reviewing our security standards and recommendations to see if more or different measures should be explicitly recommended as best practices. If the best practices are already clear and that provider is not following them, it is Not Our Problem except insofar as some of us, in other capacities, might suggest either that their users move sensitive information elsewhere or support non-technical mechanisms for getting the provider's attention. Just my opinion, of course, but the fact that a provider has a zillion users doesn't mean that a "running code" doctrine mean that we need to change standards or internal IETF practices to conform to what they decided to do any more than the observation that they have allowed personal data for many of those users to be compromised makes that ok. best, john --On Saturday, December 17, 2016 10:14 -0500 Theodore Ts'o <tytso@mit.edu> wrote: > 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. >
- DMARC methods in mailman --- [LEDE-DEV] DMARC rel… Michael Richardson
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Yoav Nir
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Paul Wouters
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Dave Crocker
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Michael Richardson
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Michael Richardson
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Paul Wouters
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Theodore Ts'o
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Viktor Dukhovni
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… ned+ietf
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Randy Bush
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… S Moonesamy
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Rich Kulawiec
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Yoav Nir
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Randy Bush
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Theodore Ts'o
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Ted Lemon
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Ted Lemon
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… S Moonesamy
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… John C Klensin
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Michael Richardson
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… John C Klensin
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Brian E Carpenter
- Re: Realistic responses to DMARC John C Klensin
- Re: Realistic responses to DMARC John Levine
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… John Levine
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Dave Crocker
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Theodore Ts'o
- Re: Realistic responses to DMARC Theodore Ts'o
- Re: Realistic responses to DMARC John R Levine
- Re: Realistic responses to DMARC Theodore Ts'o
- Re: Realistic responses to DMARC John R Levine
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… S Moonesamy
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Rich Kulawiec
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Viktor Dukhovni
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Dave Crocker
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… John C Klensin
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Brian E Carpenter
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… John C Klensin
- Re: Realistic responses to DMARC Andrew G. Malis
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… John Levine
- Re: Realistic responses to DMARC Theodore Ts'o
- Re: Realistic responses to DMARC Dave Crocker
- Re: Realistic responses to DMARC John R Levine
- Re: Realistic responses to DMARC Theodore Ts'o
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Brian E Carpenter
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… John R Levine
- Re: Realistic responses to DMARC Michael Richardson
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Michael Richardson
- Re: Realistic responses to DMARC Michael Richardson
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Michael Richardson
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Brian E Carpenter
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Viktor Dukhovni
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Harald Alvestrand
- Re: Realistic responses to DMARC Yoav Nir
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Michael Richardson
- Re: DMARC methods in mailman --- [LEDE-DEV] DMARC… Viktor Dukhovni
- Re: DMARC methods in mailman Hector Santos
- Re: Realistic responses to DMARC Alexey Melnikov
- Re: Realistic responses to DMARC Dave Cridland
- Re: Realistic responses to DMARC Ted Lemon