Re: [dmarc-ietf] ARC vs reject

Michael Thomas <> Sat, 05 December 2020 21:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50E263A0D69 for <>; Sat, 5 Dec 2020 13:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7yirQKSYl37l for <>; Sat, 5 Dec 2020 13:13:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12D5E3A0D68 for <>; Sat, 5 Dec 2020 13:13:05 -0800 (PST)
Received: by with SMTP id t18so5063482plo.0 for <>; Sat, 05 Dec 2020 13:13:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=JT3yijrIWhDVy9iB7q4NcvnKsUnKIY3rzlMckCyrSpQ=; b=OEzys/04vQpxGKzyY54RmECkroIA8xWlj5+zBGkdn75SEHKJRmWJSNeoiU1iDOTPpF ocPDAILAw8yGv8tl0cUrRhj8Fe6is96EuXeTkZQun6RR9g/WHmM6V1QxaYD2P7Lk4/mE AtJNEjPCjCzGXj4PCYwTG2TUFzgF28QJSuLGPc43RDEG+ZD56ARm/5i5ASA8zdLkmnUS Zb9PrdGLmR8WW82W0uh7WYiuHhpEJ1OwsPbKydtpzWO80B3VY4KcPNtZ/Mg2FKw+fqdk rXuPUFiO+lgwr6H2/W3aPfa8SCesdhUemFqhArZNIz5qHJO1Q4W2qxV6C1REL6CdS1BR 4WoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=JT3yijrIWhDVy9iB7q4NcvnKsUnKIY3rzlMckCyrSpQ=; b=BcqBbwoK7aXZJwCQV+A63fm/kauj+8LKrl71b0QwkK2SdjTqEjb5VeTurMQR60N0UR yMCcHrJHB8EYpY0eAy35yS5BuaFcDLGgpX/xEpOcdAjd+/OurtuKwq8/6Nit2f+G1WxY pA6m6VNqJe/MgLTd7OsoJrayhp1KJ+yEOu6Sb2DtvoxsjgisDTJQtZ3DcS/avWc54fX9 inGG9YLwwvGRItIAdIh14nhOhOsf6B2YRKq67AP38h5Z6B71wa1tQxQseTKpQko4zMpB 9jNideDmEi5ejqh/eda6e92UNFokf5+ccq2cYk6CEgqRD2H8kNdI0JDmrYvZXk9etc+g MD2g==
X-Gm-Message-State: AOAM532KvWjBU020Uk8GQ4qmhmic7QasoGcfi3UxMhPJdDJVy88N1TVA oULIKBh6ZPpQVNFCBiK/93GKGnFi4RBtfCiT
X-Google-Smtp-Source: ABdhPJw1q12fqpjjhAkO73pN3CxKZL5bIKMDjltGllN+mQzXIxWq0sy0TlCze4gE0F9xMn44LXkvDQ==
X-Received: by 2002:a17:902:8b8c:b029:d8:de6f:ed35 with SMTP id ay12-20020a1709028b8cb02900d8de6fed35mr9545150plb.36.1607202784135; Sat, 05 Dec 2020 13:13:04 -0800 (PST)
Received: from mike-mac.lan ( []) by with ESMTPSA id c193sm9159466pfb.78.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 13:13:03 -0800 (PST)
To: John Levine <>,
References: <20201205210351.DB78E2904420@ary.qy>
From: Michael Thomas <>
Message-ID: <>
Date: Sat, 5 Dec 2020 13:13:02 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <20201205210351.DB78E2904420@ary.qy>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [dmarc-ietf] ARC vs reject
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 05 Dec 2020 21:13:06 -0000

On 12/5/20 1:03 PM, John Levine wrote:
> There are, however, use
>> cases where that is exactly wrong and in no case does the originating
>> domain want such an override to happen. Consider my bank sending me
>> transactional email. If somehow somebody managed to get that mail
>> through a mailing list and arc-resigned it, my bank does *not* want that
>> mail to be delivered regardless of the reputation of the mailing list
>> because something weird and wrong is happening on its face.
> If you get a message from a bank via a trustworthy mailing list with a
> valid ARC chain that starts with a DMARC pass, that means someone at
> the bank really did send the message to the list. I don't think it's
> our job to try to guess whether the bank's users are following some
> internal policy we can't see.

There is no guarantee of that. If my bank says reject that mail, I want 
my provider to reject that mail, period. No amount of ARC shenanigans 
should change that policy.

> In practice, I can tell you that many organizations publish p=reject
> because it is "more secure" and have no clue about mailing lists, so
> it's a feature that ARC lets their users participate in mailing lists
> without totally ignoring their DMARC policy.

I'm not talking about misconfigured mail systems. I'm talking about a 
policy state that is not in the current set of p values.