IETF Logo Mail Archive

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

Dave Crocker <dhc@dcrocker.net> Fri, 31 July 2020 22:41 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972F03A0764 for <dmarc@ietfa.amsl.com>; Fri, 31 Jul 2020 15:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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 bpneFIL2cX9i for <dmarc@ietfa.amsl.com>; Fri, 31 Jul 2020 15:41:50 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 DB7503A0746 for <dmarc@ietf.org>; Fri, 31 Jul 2020 15:41:50 -0700 (PDT)
Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06VMiQWo028117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2020 15:44:27 -0700
Reply-To: dcrocker@bbiw.net
To: Joseph Brennan <brennan@columbia.edu>, IETF DMARC WG <dmarc@ietf.org>
References: <cd9258e6-3917-2380-dd9b-66d74f3a64d3@gmail.com> <20200717210053.674D61D2C431@ary.qy> <CAL0qLwbkhG-qUyGqxaEjcFn2Lb7wPMhcPFEMA8eqptBJpePPxA@mail.gmail.com> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <CAL0qLwbK7GQXkiS+H8GtsvHMzWr4o431Shc7Cc9MhqsTiHfzFw@mail.gmail.com> <bc7ed18c-8f1d-b41b-0a4b-3aa180a63563@gmail.com> <CAL0qLwYgs7py1aTQ87pykNT_0dpnrKz=+1DxMMSQMgbwz4XZDg@mail.gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> <d8bab034-7539-fbb4-faa0-daf6aa51e087@wisc.edu> <CAMSGcLAfhvsJhzB0Ukaer_ZCS276vZ5i=k08KAcWudJ0mLvLEw@mail.gmail.com>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <37ae27f2-449a-feb9-c07b-460a9189bcae@dcrocker.net>
Date: Fri, 31 Jul 2020 15:41:42 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <CAMSGcLAfhvsJhzB0Ukaer_ZCS276vZ5i=k08KAcWudJ0mLvLEw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/QjvbLEVoxgXbqPUY4SZAOQhnDyE>
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2020 22:41:55 -0000

On 7/23/2020 6:07 AM, Joseph Brennan wrote:
> I'd be happier for the proposed standard to say that DMARC policy
> "SHOULD NOT" be compromised by rewriting From lines-- and see how that
> goes over.


Consider coming along, in the middle of a 45-year practice and suddenly 
declaring the an independent entity, with whom you have no business 
relationship and who has been doing legal things for those 45 years, 
should now stop their legal practices because you've decide to impose a 
new policy on them.

Forget technology.  Consider the inter-organization implications here.

MLMs are independent.  They take delivery of a message.  Delivery, not 
simple relaying.  The post a new message.

You've suddenly made their existing practice fail and so, as is common 
and famous for the Internet, they start routing around the breakage 
you've created.

Please explain how this "should not" you want is reasonable.  Then 
please explain how it is likely to be effective.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

v2.23.0 | Report a Bug | By Email