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