Re: [dmarc-ietf] Reversing modifications from mailing lists

Wei Chuang <weihaw@google.com> Tue, 30 November 2021 17:26 UTC

Return-Path: <weihaw@google.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 C07B83A142D for <dmarc@ietfa.amsl.com>; Tue, 30 Nov 2021 09:26:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 LceRv8arkh5g for <dmarc@ietfa.amsl.com>; Tue, 30 Nov 2021 09:26:22 -0800 (PST)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 31FEF3A1428 for <dmarc@ietf.org>; Tue, 30 Nov 2021 09:26:22 -0800 (PST)
Received: by mail-il1-x12c.google.com with SMTP id i9so22119239ilu.1 for <dmarc@ietf.org>; Tue, 30 Nov 2021 09:26:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IQaf2Yj2AIN/v+4AL5q5pSgQBOiuKFfFvPBUYneOD4A=; b=hg5ezTU06pfYQWtc7J/CRAhJ5TziZAf8wvi+xx/OFGGYH7aQEdnzIgccpcDAIJyDyr b4uQ79O1gHRz+JObN2RlozW9sCrvu2uXvslNLfiHuERYMHeozBxcrsJkjAFFb6+DLugZ BsYZbLvDkweeOpnvF59lNbuZZTx1D6QEIQDmcJAWJphsiW4WeFwGhkdnqT9IWQrsAMBJ Kb0tOIN68HRuvrrgYlVhMJz7CSIthqNWQxz/He4dn5fvlheJFl/P8TK4D21v0lbkhrST Uh4++YPXlNWxsDPXTghFdRIy0bQGy1cDQ1K6S/37on0zTL4pokEW3NSmq0sFb7d1eV2r FbIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IQaf2Yj2AIN/v+4AL5q5pSgQBOiuKFfFvPBUYneOD4A=; b=dhfqwdh7Nr8ZOYhZdwyx9qfI5DYgCK/xvI9B3D1hnuqomOaZ8nzaJ9RZ2BKgIHdRq/ 0Jh3p784vd75SJIIwLKrxtW6Cj6msA0ByGh+ijNjGJpyicAwm0v4XcMOzNm3hyLlJIj7 3BP5iCIAt7i5FT8FW1hZwVz3JyczPNXKWGtM9wd6cTUdnjZsqqdJfyr5QxSypJO5tbFj z04irxwoQQCmIL+Uow6JZMdUAjUriaFPOjLI0qXgS1Wf8igVvg1cno/+jhYDigAZGH61 aU2d9TJWBnv8g2hE/SlZdKknqAwlWg9cfrSGhVfAjRKSPJeDLENtfuJEMfANr/Zrp03l wsAw==
X-Gm-Message-State: AOAM530/EnDF27OqFi1xAI0k6B4x8tsVA8Ex1XEOeXIRYZj6nXbwuWQG nmCF0JEsr2U6WL7oNauqZblik4RfjhzEwIcx31DnXrNOTpk=
X-Google-Smtp-Source: ABdhPJwkkhoQMYDBOzTlXUil1VcgaAXQgEINIC4KvJU1Q4hJnvfRVZEiHL1UKt+ZW9HPaYxssYtaav4unWAOYWOIcXQ=
X-Received: by 2002:a05:6e02:1485:: with SMTP id n5mr388152ilk.77.1638293180511; Tue, 30 Nov 2021 09:26:20 -0800 (PST)
MIME-Version: 1.0
References: <20211129030358.BC1EA30B80A5@ary.qy> <0e941529-1c93-b84d-ae7f-01c505a52c60@tana.it> <d6116d53-b415-f4d1-67e6-3a765f83754d@taugh.com> <4eb213fc-c269-3d62-36dd-50fd39efb368@tana.it>
In-Reply-To: <4eb213fc-c269-3d62-36dd-50fd39efb368@tana.it>
From: Wei Chuang <weihaw@google.com>
Date: Tue, 30 Nov 2021 09:26:08 -0800
Message-ID: <CAAFsWK2BLP8+GOVzdDtn_PsyAGaKwt0Y3F_hQWkdTHdC6RhD=A@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: John R Levine <johnl@taugh.com>, dmarc@ietf.org
Content-Type: multipart/alternative; boundary="00000000000010582b05d204dbf0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/bwPwN--_XETOkmifPEglCqsk7ls>
Subject: Re: [dmarc-ietf] Reversing modifications from mailing lists
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: Tue, 30 Nov 2021 17:26:25 -0000

On Tue, Nov 30, 2021 at 2:40 AM Alessandro Vesely <vesely@tana.it> wrote:

> On Mon 29/Nov/2021 15:17:45 +0100 John R Levine wrote:
> >> On Mon 29/Nov/2021 04:03:57 +0100 John Levine wrote:
> >>> This was part of the discussion about what sort of body modifications
> to
> >>> allow. We ended up with optionally ignoring white space changes, and
> l= to
> >>> ignore added text. My impression is that neither is useful. Very few
> >>> messages pass with relaxed canonicalization that don't also pass
> strict.
> >>
> >> Using relaxed rather than strict is quite different between header and
> body.
> >> It is fairly frequent to find reflowed headers, especially with MLM
> handling,
> >> while bodies remain mostly untouched, except for CR additions and
> removals.
> >>
> >> Of course, X-MIME-Autoconverted rewrite bodies beyond strict/ relaxed
> range.
> >> (That's the original mistake.)
> >
> > Well yeah, welcome to mail UNCOL land.
>
>
> Those conversions used to afflict direct mail flows as well.
>
>
> >> It'd be enough to add the subject tag on new messages to address the
> other
> >> changes.  Using l= works well with a wide range of mailing lists.
> However,
> >> it only works with plain text.
> >
> > I suppose if by wide range you mean lists that do not add subject tags
> and do
> > not handle html or multipart bodies.  That may be common among nerd
> lists but
> > take a look beyond mailman and I don't think it is.
>
>
> OTOH, it'd feel cringing to discuss the standardization of solutions to
> deal
> with indirect mail flows using a mailing list where neither of those
> solutions
> apply.
>
>
What about adding a footer to some html mime part is poorly handled when
using "l="?  Multipart bodies could be handled by other techniques.
-Wei