Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

Steven M Jones <smj@crash.com> Wed, 02 December 2020 09:55 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 DF62B3A1277 for <dmarc@ietfa.amsl.com>; Wed, 2 Dec 2020 01:55:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, 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 2gca9OEizdoB for <dmarc@ietfa.amsl.com>; Wed, 2 Dec 2020 01:55:57 -0800 (PST)
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 86A763A1274 for <dmarc@ietf.org>; Wed, 2 Dec 2020 01:55:57 -0800 (PST)
Received: from [10.10.10.124] (135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 0B29tk0w070503 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Dec 2020 09:55:55 GMT (envelope-from smj@crash.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 0B29tk0w070503
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1606902957; bh=00UXW7sNDflRPSUfpz5A2PaEXAuet3zC95W1d0blLFA=; h=Subject:To:References:From:Date:In-Reply-To; b=mnJnLYclF3o5bcMCVzAXhMa8xozUqXfiXjEpATgGVZZ3gcj+/957En91b37UfUyh0 Aq/ReaPYUKT50JQzBd/0ebt9CjHMlHomz4Bxq9I0tYOdCpVYJe5Lyc8QyGTCRhHhlN I6I9eksNt4p6GDIo1IM15O0FH9j+hNA+qAUIenAYQxq338U8MRfBxVbGnlzWtyCTQS Ni0EdQ9/KRlsA4/kOXRvCqXlRlFt5XduDtdUvCa+Ea9mKeDdPNgwnOY7FvP/QCy0aJ fC+vfJEqORtCjz/prg4UHlTjaxnwENjvzVPHGRs7dCf7ZmjGKPVxiqSkoERdJJiARZ bN40go5QGx3EQ==
X-Authentication-Warning: segv.crash.com: Host 135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94] claimed to be [10.10.10.124]
To: Dave Crocker <dcrocker@gmail.com>, dmarc@ietf.org
References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com>
From: Steven M Jones <smj@crash.com>
Message-ID: <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com>
Date: Wed, 2 Dec 2020 01:55:45 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com>
Content-Type: multipart/alternative; boundary="------------0572F1393EDA5630CA4755B4"
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]); Wed, 02 Dec 2020 09:55:55 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/vx4ChHZZg4JMXw-BQC4sLy_ZGmc>
Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine
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: Wed, 02 Dec 2020 09:55:59 -0000

On 12/1/20 7:41 PM, Dave Crocker wrote:
> On 12/1/2020 7:03 PM, Steven M Jones wrote:
>> Rather that the Domain Owner is *requesting* whatever the Receiver 
>> implements between rejecting the message and putting it in the inbox, 
>> and is willing to apply. 
>
> Yes, but...
>
> The premise that an author domain owner can, in any way, direct the 
> message disposition decisions of a receiving system is simply false. 
> It's false to a level of silliness, if one adequately considers the 
> complete independence of the receiver from the domain owner.

Yes, you are absolutely right. But this is why I wrote "requesting" 
rather than "commanding (with all the guarantees King Canute had when he 
commanded the tide to halt)" -- the latter phrasing is just /slightly/ 
too ponderous even for me... Does "requesting" really imply control over 
the outcome, rather than the expression of a desire?


> I'd frankly recommend changing the labels for these expressions, but 
> expect folk to argue that there is too much installed base and 
> operational history.

Ah, now maybe we're getting somewhere. But if you toss that notion out, 
you have to follow up with an example or two. Which labels, and changing 
them in what way?

--S.