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> Sun, 18 December 2016 19:04 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 9D354129675 for <ietf@ietfa.amsl.com>; Sun, 18 Dec 2016 11:04:12 -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 sSTNrDnzj6Za for <ietf@ietfa.amsl.com>; Sun, 18 Dec 2016 11:04:11 -0800 (PST)
Received: from bsa2.jck.com (bsa2.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 E94F7129673 for <ietf@ietf.org>; Sun, 18 Dec 2016 11:04:10 -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 1cIgkh-000Abu-KE; Sun, 18 Dec 2016 14:04:07 -0500
Date: Sun, 18 Dec 2016 14:04:01 -0500
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, Theodore Ts'o <tytso@mit.edu>
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: <CE27ED58B7A503683C57E125@PSB>
In-Reply-To: <384e8fd1-76cf-e886-d992-ef70cd4f1462@dcrocker.net>
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> <20161218041544.jitn4ts5nxz2dpzy@thunk.org> <384e8fd1-76cf-e886-d992-ef70cd4f1462@dcrocker.net>
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/TpHRKBeMYcP28xCRGdhcN3BtTDQ>
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 19:04:12 -0000
--On Sunday, December 18, 2016 09:05 -0800 Dave Crocker <dhc@dcrocker.net> wrote: >... >> 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. > > The world of consumer-oriented email deals with scale that > makes the 'developer' market segment almost unmeasurably > small. It is unlikely any consumer service is going to want, > or be able, to make adjustment for the developer segment. Dave, While I agree with your analysis, let me suggest a slightly different formulation (and note this is straying away from the question, which I understood to be about IETF mailing lists and DMARC workarounds. In the fourth quadrant of a conceptual matrix, there are people whose use of, and dependency on, email are mission-critical or personally critical and whose daily email volume is very high. In the diagonally-opposite first quadrant are those who may find email very useful but not actually critical to their lives or work and whose volume is relatively low. For simplicity, I'll leave the other two quadrants as an exercise. One important thing about that matrix is that the number of people in the first quadrant is hugely larger than the number of people in the fourth, to the point that almost any argument based on number of users, eyeballs, etc., can justify ignoring the fourth quadrant (and maybe the other two). In particular, small inconveniences, or even larger ones for a small fraction of the already-small number of messages received, are likely to be accepted in return for a convenient and free email service. The people in that quadrant typically don't need sophisticated mail management facilities (except maybe for personal archival purposes) -- they just don't get enough mail and/or it isn't important enough. It might be an exaggeration, but arguments that everyone should just use Webmail or even proprietary systems interconnected by gateways that more or less work, are not far away (such systems can, among other things, easily develop really effective anti-spam systems if the proprietors actually find that to be in their business interests. The number of Ted's developers or subscribers to IETF lists in the first quadrant is insignificant, not only because there are some of them in the other quadrants but because there just aren't very many of them relative to the total population of that quadrant. Now, the questions become one of who is in the fourth quadrant, how large that quadrant's population is, what features they need, and how should they get them. Part of the answer to the latter is that, while "free" is nice, many of us would happily pay for better mail management capability and other features (see recent discussions about IMAP capabilities and alternatives). Simply because of mail volume and management issues, we are probably much more sensitive to standards conformance, predictability of header field content, etc. We might also be less tolerant of systems that simply lose messages that they consider suspicious than the folks in the first quadrant (at least if it isn't from someone's easily-whitelisted grandmother). If nothing else, a small inconvenience multiplied by 500 or 1000 or more legitimate messages a day isn't a small inconvenience any more. Many of us do pay by insisting in controlling/ running our own mail servers at effective costs (including the marginal cost of Internet connections that allow servers) of hundreds of dollars a month. As a percentage, I'd guess that the concentration of developers and active IETF participants in that fourth quadrant is non-trivial. So... do we need different sets of standards (or even best practices) for the first quadrant and the fourth? Are we willing to leave the practices of the suppliers for the first quadrant users to whatever those large providers decide to do, such that community consensus-based standards may not even be relevant? If we are not willing, do we actually have a choice... several of the comments in recent days suggests that the situation is just our new reality and we need to adjust to it. My suggestion is that, if we really cannot affect the behavior of the service providers for the first quadrant, we should concentrate our efforts on the fourth, making sure that, if email use and dependency rises in the general population, we have appropriate working systems and that, in determining IETF procedures, we should be paying a lot more attention to the fourth quadrant rather than concentrating on the needs and preferences of the users in the first quadrant, no matter how many of them there are. I would feel somewhat differently about this if I thought IETF decisions would have a significant design or decision-making impact on those large-scale first quadrant providers, but the evidence, reinforced by the DMARC experience, is that they are more likely to make decisions that work well for them and their systems, users, and business models and then leave us to compensate for any damage as best we can. Maybe, but just maybe, we should be thinking more about encapsulating messages for those cases, as some of us thought would be the MIME remedy for mail passed through gateways with significant potential for information loss. best, john
- 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