Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

Steven M Jones <smj@crash.com> Tue, 15 June 2021 02:00 UTC

Return-Path: <smj@crash.com>
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 EF1D03A19C8 for <dmarc@ietfa.amsl.com>; Mon, 14 Jun 2021 19:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com
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 lFomTd9MfkxJ for <dmarc@ietfa.amsl.com>; Mon, 14 Jun 2021 19:00:33 -0700 (PDT)
Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (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 AB6B23A19C7 for <dmarc@ietf.org>; Mon, 14 Jun 2021 19:00:33 -0700 (PDT)
Received: from shiny.crash.com (192-184-141-33.fiber.dynamic.sonic.net [192.184.141.33]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.16) with ESMTPSA id 15F20LT3063225 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Tue, 15 Jun 2021 02:00:30 GMT (envelope-from smj@crash.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 15F20LT3063225
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1623722431; bh=Xu1gn+kMomthUYYjhMGe6hIHH5aKo397uMS1gxHq300=; h=Subject:To:References:From:Date:In-Reply-To; b=VJgkexHCS+9oIjGC0bDLaUHB8QVEUsbvbYSzhFV47m/3aisDCNr3HqaU+ExyJk7b7 ZjjtjDkx2Hd0BKL7SBVjd0pcW4a6zsGIRZxA/hh1w255iS9a4VvatDyFxi2lOt8ZGf BK/XmBR0X0cDGzAjoy6XEuwcQsUpUZAEcuGk5OJ2MHNMDGRphxIRXLTLlEEYqlrcA5 z7EWPGieAv+1PQhUwPit5QSm0AELnMS7PZR+riDjaQC0hPqKlcTsZjAskE17NLVpxS Ks6Lu+05Lei8utGmwnL5arZl71xs/JE01YjA7AQxjN6QCblZu2TMIqP0aQ+WOP5x0K tZVWU6ew/Qseg==
X-Authentication-Warning: segv.crash.com: Host 192-184-141-33.fiber.dynamic.sonic.net [192.184.141.33] claimed to be shiny.crash.com
To: dmarc@ietf.org
References: <MN2PR11MB4351C05DCCFD04F0C7B3F766F7319@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Steven M Jones <smj@crash.com>
Message-ID: <9eec190f-c8a6-273e-f7fe-4a25ee057c55@crash.com>
Date: Mon, 14 Jun 2021 19:00:43 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <MN2PR11MB4351C05DCCFD04F0C7B3F766F7319@MN2PR11MB4351.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Tue, 15 Jun 2021 02:00:30 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/QHveeiqIzK6piaDwFWgo2214X2E>
Subject: Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC
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: Tue, 15 Jun 2021 02:00:36 -0000

On 6/14/21 10:09, Brotman, Alex wrote:
> Does this make everyone cringe, or perhaps worth a larger discussion?


This was considered (repeatedly) during the original DMARC work, and I
believe again while it was being put into RFC7489 form.

It was rejected because it increased the likelihood of broken/invalid
records for the overwhelming majority, while providing complexity that
relatively few senders wanted. And they could usually get what they
wanted by other means.

I would not be in favor of adding more complex policy expressions.

--S.