Re: Realistic responses to DMARC

"John Levine" <johnl@taugh.com> Sun, 18 December 2016 02:28 UTC

Return-Path: <johnl@taugh.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 8DEEF1294B9 for <ietf@ietfa.amsl.com>; Sat, 17 Dec 2016 18:28:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 9gai1ejnP9g9 for <ietf@ietfa.amsl.com>; Sat, 17 Dec 2016 18:28:47 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECB0129454 for <ietf@ietf.org>; Sat, 17 Dec 2016 18:28:46 -0800 (PST)
Received: (qmail 72013 invoked from network); 18 Dec 2016 02:28:51 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 18 Dec 2016 02:28:51 -0000
Date: Sun, 18 Dec 2016 02:28:23 -0000
Message-ID: <20161218022823.8779.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
To: ietf@ietf.org
Subject: Re: Realistic responses to DMARC
In-Reply-To: <9AD6AAD6812D3B9F8379226B@PSB>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/0qpzsX5G4znfSpGQ2ztdVsKgej0>
Cc: john-ietf@jck.com
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 02:28:48 -0000

In article <9AD6AAD6812D3B9F8379226B@PSB> you write:
>+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, ...

While I am no fan of what Yahoo has done, I think we should limit the
conspiracy theorizing.  I have it on excellent authority that the
reason Yahoo turned on DMARC was entirely the user complaints about
spam with forged addresses taken from stolen address books.  It had
nothing to do with Yahoo Groups.

Yahoo management knew this would screw up every mailing list in the
world, and they explicitly didn't care.  I'm reasonably sure that the
people who run Yahoo Mail had different opinions but they didn't get
to make the decision.  While it is true that it would not be hard to
circumvent DMARC, crooks are as lazy as the rest of us and I continue
to be surprised at the amount of phish stopped by DMARC's simplistic
checks.

I hear that the amount of legit mail that DMARC breaks is well under
1% of the total non-spam mail at large providers, and even though they
know it is mail that the recipients are very interested in, it's hard
to make a business case for doing something for that 0.5 % unless they
are very sure it won't let a lot of the phish back in.  That's the
rationale for ARC, which is a complicated crock, but lets the
provlders make a reasoanble guess about what's non-spam from mailing
lists.  (FYI, they also tell me that legit lists leak spam all the
time due to compromised or forged subscriber accounts, so it has to be
more than just whitelisting the lists.)


>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.   ...

I appreciate the theory, but we also need to consider how much blood
loss we are willing to accept to cut off our noses to spite our faces.
It is pretty clear that within the next year Gmail will turn on a
DMARC policy, too, and I expect other large mail providers to turn it
on, too.  

If we tell people, sorry, you can't participate in the IETF using the
giant mail providers you use for everything else, what do you expect
the response to be?  Wow, what a bunch of noble principled idealists,
or wow, I don't have time for this nonsense, maybe I'll go work on
some open source stuff on github instead.  We have enough trouble
recruiting people now without putting more roadblocks in their way.

A few of us have been doing some experiments on DMARC avoidance,
looking to see if there's something we can do that will survive DMARC,
not screw up the mail too badly so it's legible and recipients can
reply reasonably, while uglifying it to remind people whose fault it
is.  Some of the possibilities involve wrapping the real message in an
outer one, some involve changing the From: address to a mutated
version of the sender's address (*not* the list's address.)

Maybe ARC will work well enough that we won't have to do anything, but
I expect ARC will be a half solution at best, since it assumes
recipient MTAs have a rather sophisticated filter system that can
handle all the stuff in the ARC chain of forwarding headers.

R's,
John