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

Rich Kulawiec <rsk@gsp.org> Sun, 18 December 2016 14:04 UTC

Return-Path: <rsk@gsp.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 C54011294BA for <ietf@ietfa.amsl.com>; Sun, 18 Dec 2016 06:04:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 O_7vHJtTebKy for <ietf@ietfa.amsl.com>; Sun, 18 Dec 2016 06:04:24 -0800 (PST)
Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7714E1294B8 for <ietf@ietf.org>; Sun, 18 Dec 2016 06:04:24 -0800 (PST)
Received: from gsp.org (localhost [127.0.0.1]) by taos.firemountain.net (8.15.1/8.14.9) with SMTP id uBIE4MVn016268 for <ietf@ietf.org>; Sun, 18 Dec 2016 09:04:23 -0500 (EST)
Date: Sun, 18 Dec 2016 09:04:22 -0500
From: Rich Kulawiec <rsk@gsp.org>
To: ietf@ietf.org
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: <20161218140422.GA19580@gsp.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: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/v1RK8uI-iitAR5tGq7V5WPx_EkI>
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 14:04:26 -0000

On Sat, Dec 17, 2016 at 06:38:07PM -0800, Dave Crocker wrote:
> there is a broad-based belief in that community that aggressive
> requirements for author authentication will alleviate many abuse problems.

There was a roughly equivalent belief that requirements for
domain authentication would do the same thing:

	"Spam as a technical problem is solved by SPF."

That belief was wrong.  So is this one.  Even if DMARC (and ARC,
and whatever else comes along) work perfectly, without all the
myriad problems we're currently discussing, the impact on abuse will
be negligible.  For example, since we're talking about Yahoo and its
latest massive security breach: I get spam -- all day, every day --
in my spamtraps from Yahoo, and yes it really is from them.   It flows
nonstop, as it has for many years, because they simply don't care to
make it stop.  So it doesn't matter if it's authenticated as really from
them, and further authenticated as really from a particular user account:
this is accurate but useless information because they won't do anything
with it.

Dealing with abuse doesn't require any of these technologies.  It requires
organizational committment to running a well-staffed, well-qualified
abuse desk that responds to EVERY abuse report promptly, efficiently,
and accurately, and which is empowered to take the actions necessary to
make the abuse stop.  Yahoo is miserably bad at this, and they're not
the only one.

So let's not kid ourselves that these operations are sincerely trying
to do something meaningful about abuse.  They're not.  They've told us
by their actions, for well over a decade, that they simply don't care
about the abuse they emit/support/facilitate.

---rsk