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