IETF Logo Mail Archive

Re: [dmarc-ietf] ARC vs reject

Alessandro Vesely <vesely@tana.it> Mon, 07 December 2020 10:44 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 BD51C3A0BBE for <dmarc@ietfa.amsl.com>; Mon, 7 Dec 2020 02:44:23 -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 LcJlZeOuaU3G for <dmarc@ietfa.amsl.com>; Mon, 7 Dec 2020 02:44:21 -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 9CF773A12EA for <dmarc@ietf.org>; Mon, 7 Dec 2020 02:44:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607337850; bh=X2FozRElWmf2q7VpgbZaDHTxOMT3KrXGdJw2UsX7A5w=; l=648; h=To:Cc:References:From:Date:In-Reply-To; b=BHtMXH0pRdgI825b83zXaMGvdZMLKEJNC5nwxY6idq40OhVLlZQAQqp+sEjRtcA9y c70wHktgO2t3g4Wvz1lpRTI0WjF8akgd2AvMTtApGB9aLvVx01N9fUy8T5NaVZuAoa NFzqWqw//Nf4joztW+gt1SJbhZvmfYH6+QIkyIbzy+8SFH6jN7+mXzJeqS9CT
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Original-Cc: IETF DMARC WG <dmarc@ietf.org>
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 00000000005DC053.000000005FCE077A.000042AE; Mon, 07 Dec 2020 11:44:10 +0100
To: "Murray S. Kucherawy" <superuser@gmail.com>, Michael Thomas <mike@mtcc.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> <A7E1018B-F6B1-46F3-8FEF-69FDC744DA4A@bluepopcorn.net> <d8dc2644-cbcf-d3a1-c5fb-46fdf5bec819@taugh.com> <CAH48ZfxWWxSh3j3YnA4eD4Y5Ep4GfVDr22WX1MCM4-tcVK0UpQ@mail.gmail.com> <b5774a04-fbee-8d23-d760-0380d58a9fb7@mtcc.com> <CAL0qLwZ+KFrPzScr6c-tMOd2nCV=v1Mf71h0fWBUV9_ZZ-k6Cw@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <b069e7c1-51a8-4550-76a9-c7e78f04c780@tana.it>
Date: Mon, 07 Dec 2020 11:44:10 +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: <CAL0qLwZ+KFrPzScr6c-tMOd2nCV=v1Mf71h0fWBUV9_ZZ-k6Cw@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/-KVTK9tMIi6nCZ4fFj7Cj4ffYjY>
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: Mon, 07 Dec 2020 10:44:24 -0000

On Mon 07/Dec/2020 06:05:29 +0100 Murray S. Kucherawy wrote:
> 
> A counter-argument I've heard often to the idea of reversible transformations 
> is that it can become a spam vector, no different than the argument against 
> "l=".


    Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the
    fact that footers are written in plain text removes the main security
    objection about footer additions.  Namely, footers cannot completely
    replace the original content in the end recipient's eyes by
    exploiting lax HTML parsing in the MUA.

https://tools.ietf.org/html/draft-vesely-dmarc-mlm-transform-00#section-6


Best
Ale
--

v2.23.0 | Report a Bug | By Email