Re: [dmarc-ietf] ARC vs reject

Michael Thomas <> Sun, 06 December 2020 21:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E05513A0C00 for <>; Sun, 6 Dec 2020 13:12:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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 zcDFxW9l1lUl for <>; Sun, 6 Dec 2020 13:12:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 817B53A0BFD for <>; Sun, 6 Dec 2020 13:12:32 -0800 (PST)
Received: by with SMTP id e23so7130181pgk.12 for <>; Sun, 06 Dec 2020 13:12:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=eVAu55X88WuLcPouYIeA2z99oHKpntXp6hYI7/ZfcVY=; b=PQq3XiXpgXg7+cbvjl1X2fJeI615a3t25+hCgj3Tt2cmNE+BV+jco2AyLnLEa03cRF FelQxstmJG4M68qvG17857hPy4gLtjL2EC5PjGoRFZqPKP+MAHYHzgp0G6ypU3S2TJoY TxKsmqmxXSAJJfyXGU1VfypWIOsrX6oROhHlE6+c1fkvCq06jWkk2ncUyXKvUvT9buNz kFn8elABzBaHoYcZYyQviZdI8jTZPMbfGIWzQBFWtz2qoLuTQug91Sl2YvNVIaDdwgKI jJpnYbWyCMYIVe40VSJiLHR5wBQev2ECXcYnnZyfY2y8bu4jwQ1qxyROdpkAEqlKC4vW 0zOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=eVAu55X88WuLcPouYIeA2z99oHKpntXp6hYI7/ZfcVY=; b=HsilmPC169Ow6k7MIlRQK5ArCd+QNVH/J2TaKYflJVunSbmEFq0Jzp5gpsy2uqjatW Boj6RRusZ8/EGoVoIsiENaFoZJBqPsLmFQQv3hUhmr8pPHrTYFMczUk3MUdecLBDRge5 4Hqm72koBam3nH3KS4NSeMSt6rit5g5vp/N6/3JkKx7uY6euht80r3IvW/N3E+LHsSMU h4OrDwxYsQACwJsBPHuO3S2G1KPhs3YqOk+5t5XZ4UnxJqBRXBazfWaJ8iLXzANX98o4 vLZD52TLzrVAVZYPqYyJsQtdYpj9C11f6dxdcAreKiuKHm9QU8MJnZhY07aEmxocz/A2 0hAA==
X-Gm-Message-State: AOAM5318TYvcUVTIv2Mvh3CCG/MveW9i7y9LcpcyRhXlNb3cNczzbMrz DLd7BwygV0s2sDrS6HTQ9yPLR5Ekxvv5LA==
X-Google-Smtp-Source: ABdhPJz7KyBlNk5o8VIL2hwh33jT30kpjN36iiG/1XNGsVmnNjWGOo9HXASFRLgzzTjjolSfO8kVuw==
X-Received: by 2002:a17:902:bd8d:b029:da:fcd1:664 with SMTP id q13-20020a170902bd8db02900dafcd10664mr232848pls.30.1607289151407; Sun, 06 Dec 2020 13:12:31 -0800 (PST)
Received: from mike-mac.lan ( []) by with ESMTPSA id x6sm9434863pgr.20.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 13:12:30 -0800 (PST)
To: Jim Fenton <>, John Levine <>
References: <20201205210351.DB78E2904420@ary.qy> <>
From: Michael Thomas <>
Message-ID: <>
Date: Sun, 6 Dec 2020 13:12:29 -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: <>
Content-Type: multipart/alternative; boundary="------------0F4A361C9B62F081A0584245"
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: Sun, 06 Dec 2020 21:12:34 -0000

On 12/5/20 6:04 PM, Jim Fenton wrote:
> I’d like to step back from the specific use case of “a bank”.
> If a domain publishes p=reject, they’re requesting particular handling 
> of a message they originate. ARC modifies that, which is good for 
> mailing lists and similar intermediaries, but depends on a list of 
> trusted intermediaries that is not under the control of the 
> originating domain. That increases the attack surface for DMARC 
> considerably.
> The question I have is: Should DMARC have a policy (or policy 
> modifier) that says, “Do not accept modifications to this message?” In 
> other words, that the originator values the integrity of their 
> messages over deliverability.
I'm in the middle of reading rfc  7960 and lo and behold I found this. 
So I'm not the only one who has thought about this.


To further complicate the usage of mitigations, mitigation may not be
    desired if the email in question is of a certain category of high
    value or high risk (security-related) transactional messages (dealing
    with financial transactions or medical records, for example).  In
    these cases, mitigating the impact of DMARC due to indirect email
    flows may not be desirable (counterproductive or allowing for abuse)"

And the example they use is exactly the example I used.