Re: [dmarc-ietf] ARC vs reject

Alessandro Vesely <vesely@tana.it> Sun, 06 December 2020 13:40 UTC

Return-Path: <vesely@tana.it>
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 C9AF63A0DBA for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 05:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 UzGjyoCZEPdd for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 05:40:49 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 4FE9C3A0DB5 for <dmarc@ietf.org>; Sun, 6 Dec 2020 05:40:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607262046; bh=i3kLiHLHE1zsM7SN6kU+i62KAbs+/co8y9LyEkC49j8=; l=821; h=To:References:From:Date:In-Reply-To; b=BQV1xS+xZSL1Lm0KPZDIHJuWWuzLMYpKq3/M+x2zH31zf4FFoiMtEzTdd0FryWnet JjT12RP1WkhBIyc0Y9w3l3VNpU1y0kbNJB9NtRaQxluFDdtVavq656GFt04HHOvxD5 zrK/kZf6oMGxvDWa5MNswwo1l7W3hslGny7kWgoIGtV/toEFJpL/ucNVdB9tA
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC03D.000000005FCCDF5E.00004826; Sun, 06 Dec 2020 14:40:46 +0100
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>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <cc5cd21c-ae32-512c-e988-55dfabd39e38@tana.it>
Date: Sun, 6 Dec 2020 14:40:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <72d32b62-64fb-937a-dac5-6f4c5816f523@mtcc.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/lzjPj0N0-SMci1Zdq64mdXNaHpg>
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 13:40:51 -0000

On Sun 06/Dec/2020 02:34:45 +0100 Michael Thomas wrote:
>>
>> 5) The work you and Alessandro have done with reverse transformation is more 
>> likely to produce a solution for the mailing lists.   The lists will continue 
>> to do From rewrite, but reverse-transform recipients can validate the true 
>> source of the message and restore the From if desired.
> 
> I'm starting to get a little more serious about my quip that the MLM can insert 
> a sed script in a header to unmangle the message since it knows what transforms 
> it has done, unlike the receiving MTA trying to guess the common transformations.


But then the receiving MTA will have to guess whether the sed script 
considerably alters the intended meaning of the message.  For example, does it 
change a bank account number?


Best
Ale
--