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

Jim Fenton <fenton@bluepopcorn.net> Thu, 03 December 2020 06:03 UTC

Return-Path: <fenton@bluepopcorn.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 4059E3A00C4 for <dmarc@ietfa.amsl.com>; Wed, 2 Dec 2020 22:03:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
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 7VHAbKHi6mgC for <dmarc@ietfa.amsl.com>; Wed, 2 Dec 2020 22:03:25 -0800 (PST)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 AA0753A0062 for <dmarc@ietf.org>; Wed, 2 Dec 2020 22:03:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HHn7IM7L/L0pGGjJbWRpRjG8VaCSeUwSFSMYfHTozlg=; b=U5HWQXv5YptWxfFaU2m9I4TOZS vZHKE33SjPm2yLP5mBsDMxN/boiYY+Yc3sPEBMAL9sm+daKqsHa/VMSaAHFLDJ5Jg8sc+6d/vgyd7 ltSHBtLNcJqyKwk7fix2syPelqejyP3wd15K1MRMxzQkcObSalY1BOL1o1m8FUQF5pRg=;
Received: from [2601:647:4400:1261:814f:cf27:ab65:355] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <fenton@bluepopcorn.net>) id 1kkhi8-0007Av-RX; Wed, 02 Dec 2020 22:03:25 -0800
From: "Jim Fenton" <fenton@bluepopcorn.net>
To: "Laura Atkins" <laura@wordtothewise.com>
Cc: "IETF DMARC WG" <dmarc@ietf.org>
Date: Wed, 02 Dec 2020 22:03:24 -0800
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <B3AD64BB-1636-4632-ABB5-96E675CDC5F1@bluepopcorn.net>
In-Reply-To: <5C559553-3F45-494D-9714-F7BC47BB82FF@wordtothewise.com>
References: <a49a7a79-6c52-ded7-60a3-754cd12fb7c3@taugh.com> <5C559553-3F45-494D-9714-F7BC47BB82FF@wordtothewise.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/3PLyW2EXABXqDUnIVfYdtXupNEA>
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: Thu, 03 Dec 2020 06:03:27 -0000

On 2 Dec 2020, at 1:47, Laura Atkins wrote:

> p=quarantine is quite useful, particularly for those folks who are 
> trying to get to a p=reject state.
>
> In practice, senders who publish p=none don’t find all of the 
> indirect mail flows as some mailing lists do nothing to transform the 
> 5322.from address for a p=none policy. Senders have found that when 
> they switch from p=none to p=quarantine pct=0 they regularly find mail 
> that was not failing for a p=none.

I’m really confused by this. It sounds like the 5322.from address 
rewriting is creating additional errors that didn’t exist beforehand, 
and that’s the opposite of the intended purpose. Isn’t the purpose 
of rewriting the 5322.from address to change the domain to that of the 
mediator, which should redirect reporting to the mediator rather than 
the original sender?

-Jim