Re: [dmarc-ietf] ARC vs reject

Michael Thomas <mike@mtcc.com> Sun, 06 December 2020 18:47 UTC

Return-Path: <mike@fresheez.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 047D93A09C9 for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 10:47:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.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 3OFNWPqVYcbw for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 10:47:28 -0800 (PST)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80CE3A09C6 for <dmarc@ietf.org>; Sun, 6 Dec 2020 10:47:28 -0800 (PST)
Received: by mail-pl1-x629.google.com with SMTP id 4so5974222plk.5 for <dmarc@ietf.org>; Sun, 06 Dec 2020 10:47:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=tFoPQmL7QlS7GTnTMSK2BeurY0FPMMEPoDdpk9+eqwM=; b=cFaVaFVEKQtnehH5r9QP2H0ZZhDOKVkXxQmYVui5NAIEu2w00W+7YwO7d+D4PNUCIm QR37mB2YB0YsdBWNDze0luj8uNXRl021bhD8Pi6iSqr7YkvM/cqTwPRZuL9pQhGfbk3R M8wjpWPL8c58WYXa9OeVLg9DU6FWtzO0SQi/EFhgQW2J8qyapU3KlErw3o437zD0CMmj XuRHIwYaC67yXaP2VGylwyv5hLtIXhvdclf5RhPH8LriZeSj+ry9EOnXy7+IxvpQVzxZ d6j7Beecdvf2onUKOQsd5etgDwQD6DWwVGDpjvqMz8/o3n7uHHpfqYFg+k4d5EoldV7+ WQ4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=tFoPQmL7QlS7GTnTMSK2BeurY0FPMMEPoDdpk9+eqwM=; b=ikWJgIjtd5lR4LZsIxh0lBDdMlGeM3IqmD7TCUTTP3JavdC4qjNyNqWbmwPeqY1bG3 ShZNWm/L63OHu0DDdEUSH1uGBMWS2jB5WWOJmvGi+J2Gfri9XRGN1k3A6XAr60QOmlh9 vZiFiYf45CMQVqjxfLcdqqKpPFkR4/mt/e4cLpKvqnPiIZCJPAfekrSy3CtloH4soKW0 RPjcco33QkyJjxHmmL8xLSBAIUiasRBRIe68OSq5D4YuAqteTbwE3DD08jLsx8SSg5xc 3tjFPXYJcwqH+i/kwb009sVS605Grz4k74i+iAsGlkZl+2YwUuvrGR7r7/c1GWP8JVi+ vc5Q==
X-Gm-Message-State: AOAM531Cd0xHk14T7Ns7Ys5EB9ulbPalxQK/8GdDXfqZU1andxHBgw7w tnYnXhDwAW1+Eivnu5zbpLHpt4wTXMrcFA==
X-Google-Smtp-Source: ABdhPJya9Nh/UVbMZBLR2aQGV0yqnpFRAIbppQxpWuq3Cdy6SrBNTelwZOuRRgGh7MlHvnxvyqlqkQ==
X-Received: by 2002:a17:90a:c8d:: with SMTP id v13mr13362240pja.75.1607280446464; Sun, 06 Dec 2020 10:47:26 -0800 (PST)
Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id x6sm9501963pfq.57.2020.12.06.10.47.25 for <dmarc@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 10:47:25 -0800 (PST)
To: dmarc@ietf.org
References: <20201205231059.2BA23290EDCD@ary.qy> <b437a23a-7e7e-f70d-04dc-49810d002c43@mtcc.com> <b6950472-599b-d0a7-c0d1-82db099fb99b@gmail.com> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> <cb526017-c198-44f1-7282-986e5a810d6a@gmail.com> <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com> <CAH48ZfwHKoVZn9RdhBh-xU=he8=smB59R5EF1TYJ_0upEDHn2A@mail.gmail.com> <72d32b62-64fb-937a-dac5-6f4c5816f523@mtcc.com> <cc5cd21c-ae32-512c-e988-55dfabd39e38@tana.it> <d96eb6cc-0412-0215-5ce2-28dbcfc13a8f@mtcc.com> <80558d32-2498-f9b3-313f-2211c1731e73@tana.it>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <e65276e9-0f39-f494-c547-eb67022e0b58@mtcc.com>
Date: Sun, 06 Dec 2020 10:47:24 -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: <80558d32-2498-f9b3-313f-2211c1731e73@tana.it>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/PpcFL5HEhG0Voe1_F1IXRcrni0k>
Subject: Re: [dmarc-ietf] ARC vs reject
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: Sun, 06 Dec 2020 18:47:30 -0000

On 12/6/20 10:31 AM, Alessandro Vesely wrote:
> On Sun 06/Dec/2020 18:01:04 +0100 Michael Thomas wrote:
>>
>> This actually highlights why my observation is correct. If the 
>> intermediary showed how to reverse their changes perfectly to be able 
>> to validate the original signature, it says nothing about whether 
>> those changes to be delivered to the recipient are acceptable to the 
>> originating domain. for the case of a bank sending me sensitive mail, 
>> the answer is that it is never ok. for somebody working on internet 
>> standards working on ietf lists, the answer is that it is fine. hence 
>> trying to get two states of the one "reject" is insufficient.
>
>
> For MLM transformations, this choice can be done by tuning DKIM 
> signatures.  A bank can choose to sign Sender: field (or lack 
> thereof), or any other fields that a MLM has to change, and possibly 
> use simple canonicalization.  In that conditions, transformation 
> reversion won't work.  It isn't a distinct DMARC state, formally.  
> Yet, tuning DKIM signatures allows to harden or weaken the given DMARC 
> state.
>
It seems a lot simpler for the originating domain to just be explicit 
about how they feel about transformations by intermediaries. It's not 
like another short ascii string is going to break the bank.

Mike