Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

Douglas Foster <dougfoster.emailstandards@gmail.com> Sat, 09 October 2021 19:39 UTC

Return-Path: <dougfoster.emailstandards@gmail.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 26EA73A084F for <dmarc@ietfa.amsl.com>; Sat, 9 Oct 2021 12:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9qt2zHNQLYeJ for <dmarc@ietfa.amsl.com>; Sat, 9 Oct 2021 12:39:48 -0700 (PDT)
Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (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 525943A0846 for <dmarc@ietf.org>; Sat, 9 Oct 2021 12:39:48 -0700 (PDT)
Received: by mail-oo1-xc2e.google.com with SMTP id s4-20020a4aad44000000b002b6aa5b6999so2414900oon.2 for <dmarc@ietf.org>; Sat, 09 Oct 2021 12:39:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PsS11SJ81QrxCo3ZPLyYOSIQR7D7Et1R3fQMTjkrhHE=; b=V3B3CpLT0d0A0C7Oqsbv30NIE6QTMDaNX2uzgzbvNQ61gDoGM9ruEfZFM6NbgOnfh/ Cx9ze0CI+UQ0YT+k0ccN6WuF+K4Vfz13lrx8EO7I98nXntUKs6ZJft2EowwUdmKiE5g9 lpjSKGMl5C3YvsrJ40H83guKawsOT4CNUjns9kxl/4Cg2KrC/r4QyYMqIg0D9Wfd+NDx 5sWvCXdsdISVWr0972wWmOrV6118remikCEw8pcj+KN+E7jIdmgFHy/jVIQ/kAZlkNYY G0eCUY9mcGueF/OWfW1Hqv4T6/a3AgxOpbblUXiXU0zeCrpzL5YPnyOjxOC0lotuJT/X IkQQ==
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=PsS11SJ81QrxCo3ZPLyYOSIQR7D7Et1R3fQMTjkrhHE=; b=hQpelMFZZRVFlKvfF/dKQuxc3nQZkne8i/1LlTaPutpy5RiMmPW12exw43NspjKKsr dPgF+vr2uTSs4JxE25BywU5vpQBvgg8pcqQhXDaAbX7PK7KlCJ0P3l6R6of2nzyGD4JQ S/ddZu2FHejeJiCEk7qgnLAjkIvEFvndOjwPsASjEZdJ0cFRyOx8Uh97enW55FOJq0nj +E8yfemDHGK0kDgYuO5C2+Z6L1pA77dBySrs+OuM29kN+cs3mmcwz+GBB0DqQB2VJEPW b4/IbPvFdl5AeLZFvI0VMvk0JtmH25EpQig1TJvJwawh0EhUWTpK7tVHLfWVNSqqp+K1 rAcw==
X-Gm-Message-State: AOAM530qN1XU1B1KBWPWRqouf3DamDR9IpYdc/j+Ki9dVCbm6hAGwrli +4/hgMKbwIqA23RGLyaCmWXEd9k0fQ3xCLbwsxg=
X-Google-Smtp-Source: ABdhPJxfQy/+As6qbGlaG8kkhJu9HBJN+FbYNqo7R04RKbIsAfiVWef/kMWgtTlpmjkYCsLzG3xYhB2wP+Y+Z8FRAn0=
X-Received: by 2002:a4a:c18d:: with SMTP id w13mr13121925oop.15.1633808387317; Sat, 09 Oct 2021 12:39:47 -0700 (PDT)
MIME-Version: 1.0
References: <20211006233727.24C1429DC897@ary.qy> <56B7A1D4-B683-47D3-8871-2A1F283FA464@wordtothewise.com> <c1e199f1-0c91-9c39-1479-e9ba76af493e@tana.it> <2290129.80B3yH0EHm@zini-1880> <CALaySJJ3Neo6hgEJJ80g-H4vFMJ5Y-Fc=to4R8=sa9-3pg3zgg@mail.gmail.com>
In-Reply-To: <CALaySJJ3Neo6hgEJJ80g-H4vFMJ5Y-Fc=to4R8=sa9-3pg3zgg@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Sat, 09 Oct 2021 15:39:36 -0400
Message-ID: <CAH48Zfw81292FOXoSK9xDpG-zo9-r58Dne4Uwy+oi1SFSN_0pA@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: Scott Kitterman <sklist@kitterman.com>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008ea2d205cdf0a882"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/7qZdbMbM1zdexGeZouUHWp_J0e0>
Subject: Re: [dmarc-ietf] DMARC-Compliant 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: Sat, 09 Oct 2021 19:39:53 -0000

I would be pleased to see a document which explains why lists MUST or
SHOULD alter content.    After more than 2 years following this discussion,
no reason for this practice has ever been documented.

Content changes would be easier to justify if subscribers granted
authorization to modify as part of the subscription process.   But there
was not informed consent when I joined this list, so I doubt that informed
consent occurs on other lists either.

What if, after reviewing the SHOULD list, an organization says "That's
interesting but unconvincing.   Please send messages to our domain without
alteration?"   Are lists equipped to give participants what they want, or
not?

Doug

On Thu, Oct 7, 2021 at 9:58 AM Barry Leiba <barryleiba@computer.org> wrote:

> Just on one point, for us to consider:
>
> > Personally, I think mailing lists changing From has horrible UX and I
> don't
> > really think anyone disagrees.  It's only advantages are that it's
> relatively
> > easy to implement in a Mailing List Manager (MLM) and it solves the
> entire
> > DMARC problem for a specific mailing list without needing anyone else to
> change
> > anything.  I understand the appeal.
>
> I think Scott is right that we all agree that rewriting From mitigates
> problems that mailing lists have with DMARC, but at a significant cost
> in usability.
>
> I think it would be bad to publish From-rewriting as a standard.
>
> But here:  I think it is reasonable, perhaps advisable, to
> informationally document From-rewriting as a mechanism that is in use,
> and to include in that documentation a clear exposition of the
> problems that it causes.  Why not get those horrible UX issues down on
> paper so that when someone decides to deploy it they are better
> informed?  Perhaps we can lead people to take steps to reduce the UX
> challenges (for example, rewriting the way the IETF is doing it at
> least addresses the issue of knowing who sent the message, and how to
> reply to the actual sender, as compared to a rewrite directly to the
> mailing list address).
>
> Doesn't that make sense?
>
> Barry
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>