Re: Realistic responses to DMARC
Theodore Ts'o <tytso@mit.edu> Sun, 18 December 2016 22:24 UTC
Return-Path: <tytso@thunk.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 0C56B1296CA for <ietf@ietfa.amsl.com>; Sun, 18 Dec 2016 14:24:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thunk.org
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 O60WvOJ2rJBT for <ietf@ietfa.amsl.com>; Sun, 18 Dec 2016 14:24:31 -0800 (PST)
Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3615E1296BC for <ietf@ietf.org>; Sun, 18 Dec 2016 14:24:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=ZWA4G53rNJFS2Ts9KhFIc58jH5Nbu1jzup7ztbihmiA=; b=G5N0SVKz4OMDsJNSdON7y/pvlFSkpjxKTMHhW1MCEDhzjFhETf73t5eaWpegKwSedCQaax4FO1SLyYH0qnrN0DCYQocwDbpNzuBqTqVGvOSOQFrZOY+4FDxNSzQ6NG9YKndgL6JAW0Ry1bZu5p50z3O4NZpulMfENvl890+eIf0=;
Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.84_2) (envelope-from <tytso@thunk.org>) id 1cIjsb-0007Ap-Ec; Sun, 18 Dec 2016 22:24:29 +0000
Received: by callcc.thunk.org (Postfix, from userid 15806) id 3986FC00788; Sun, 18 Dec 2016 17:24:27 -0500 (EST)
Date: Sun, 18 Dec 2016 17:24:27 -0500
From: Theodore Ts'o <tytso@mit.edu>
To: John R Levine <johnl@taugh.com>
Subject: Re: Realistic responses to DMARC
Message-ID: <20161218222427.7phtcg7mhpypcwnb@thunk.org>
References: <9AD6AAD6812D3B9F8379226B@PSB> <20161218022823.8779.qmail@ary.lan> <20161218055834.he6gkupqp5xqlvml@thunk.org> <alpine.OSX.2.11.1612180101460.14297@ary.qy> <20161218065905.5g66jgkvtckydmry@thunk.org> <alpine.OSX.2.11.1612180215450.14970@ary.qy>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.OSX.2.11.1612180215450.14970@ary.qy>
User-Agent: NeoMutt/20161126 (1.7.1)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/AP4zYCig7BSBkzfrsW_4V-_3Vw8>
Cc: IETF general 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 22:24:33 -0000
On Sun, Dec 18, 2016 at 02:24:03AM -0500, John R Levine wrote: > > Therefore, a developer-friendly mail service MUST NOT have a p=reject > > or p=quarantee DMARC policy, and MUST also ignore DMARC policies on > > the receiving end. Fortunately, these mail services do exist, even if > > they aren't the big, free consumer ones. > > Linux may be enough of a cult that developers will put up with having to use > a mail account different from the one they use for everything else, but as > I've said a couple of times already, I don't think the IETF can stand the > blood loss. It has nothing to do with Linux being a cult. It's a matter of Linux's economic importance. If you look at who actually writes the Linux kernel[1], you'll see the vast majority (over 80%) are doing this work because they are being paid to do it, with over 200 companies contributing work to every Linux kernel release. These are all companies that have products using Linux, and if they want to participate in the development process, then they darn well better figure out a way to deal with the fact that vger.kernel.org is unrepentantly *NOT* DMARC-compliant. [1] https://www.linux.com/publications/linux-kernel-development-how-fast-it-going-who-doing-it-what-they-are-doing-and-who-5 >From looking at the numbers over the past year, the Linux kernel has been increasing the number of developers contributing in each retreat during the entire time that we've been giving the middle finger to DMARC, and it hasn't been a problem. When I used to be attending the face to face IETF meetings ten years ago, at that time my impression was that the IETF was that important and vital as well, and I suspect that if people had been forced to change mail providers because that was the only way they could get work done, and the only way they could ship products, they would do what they would need to do. I can't speak to the power and respect and importance that the IETF commands today, but what's important to remember here is that this is, again, all about power politics. So when David Crocker tells us that the mail providers aren't going to back down, regardless of whether or not it is true, *of course* the the mail providers will try to say that, because they are trying to intimate people into knuckling under and accepting DMARC. Similarly, there is of course a similar game going on with the vger.kernel.org mail administrators basically telling yahoo.com subscribers, "sorry, find another mail provider", in that by not backing down, hopefully that will change the position of the big mail providers. It's all basic power negotiating --- the sort of thing that Trump would understand --- and this is what happens when something like DMARC is promulgated across the e-mail ecosystem without a standards process that respects all stakeholders. The alternative to "rule of law" or "standards" is "rule of the jungle". And so at the end of the day, it's all about what your BATNA (best alternative to a negotiated agreement). If it really is true that the IETF is so lacking in power, and is so enervated, that you are afraid that you will bleed participants if you don't stand firm to DMARC --- then you will have lost already. And if it's true, then maybe the IETF doesn't have the economic power of say, the Linux kernel in today's computer industry. I don't think that's true; I certainly hope that it's not true. But you're probably in a better position to make that judgement than I. Cheers, - Ted
- 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