Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)x

John C Klensin <john-ietf@jck.com> Thu, 17 July 2014 18:06 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999BF1A0028 for <ietf@ietfa.amsl.com>; Thu, 17 Jul 2014 11:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 eluO4cIeUJNu for <ietf@ietfa.amsl.com>; Thu, 17 Jul 2014 11:06:35 -0700 (PDT)
Received: from bsa2.jck.com (ns.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 8C1A61A00C5 for <ietf@ietf.org>; Thu, 17 Jul 2014 11:06:34 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1X7q0l-000Jq9-Jo; Thu, 17 Jul 2014 14:02:31 -0400
Date: Thu, 17 Jul 2014 14:06:28 -0400
From: John C Klensin <john-ietf@jck.com>
To: John R Levine <johnl@taugh.com>
Subject: Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)x
Message-ID: <D8ABF2C07C06C553E1DA8341@JcK-HP8200.jck.com>
In-Reply-To: <alpine.BSF.2.11.1407171227550.8184@joyce.lan>
References: <20140717024645.1605.qmail@joyce.lan> <EAC6F6031A4AF95070AF35C5@JcK-HP8200.jck.com> <alpine.BSF.2.11.1407171227550.8184@joyce.lan>
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.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/0Y7Y_dcetiI76sGy0aJ6a823Ms0
Cc: IETF general list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 17 Jul 2014 18:06:42 -0000


--On Thursday, July 17, 2014 12:32 -0400 John R Levine
<johnl@taugh.com> wrote:

>>> It's more popular among large providers than small ones.
>> ...
> 
>> To me, that makes decisions about damage-mitigation work for a
>> non-essential protocol complicated because one way to
>> eliminate the damage is to not support the protocol at all,
>> possibly including stripping its headers whenever they are
>> encountered.
> 
> Having talked at length with people at the large providers
> that use DMARC, I am sure that there is no possibility that it
> will go away and it is likely that more rather than fewer
> providers will start publishing restrictive policies.

I do see a plausible scenario under which it goes away, but that
scenario is not the IETF's problem and I hope it stays not the
IETF's problem.  More to the point, my note did not posit any
change in their behavior.

> They understand that it causes problems, and I believe they
> are open to implementing changes to alleviate those problems.

Let me be clear, since my earlier note obviously either wasn't
or was too detailed.    I believe there are three possible
"fixes" that are under IETF control (what those providers will
or will not do is not, ARAIK, under IETF contorl):

(1) Changes are made to DMARC that reduce the pain level.

(2) Changes are recommended and made by the pain-recipients that
will make things less painful.  

(3) Changes that are made in systems not controlled by the DMARC
sponsors that make the protocol both less effective and less
painful, e.g., by removing DMARC headers in appropriate
circumstances (with "appropriate" to be something the WG
discusses).

I just want to be absolutely sure that the charter doesn't
constrain any of those options and that the WG is on notice that
it will be accountable for, and required to explain, the choices
it makes.  

 best,
     john