Re: [dmarc-ietf] Signaling MLMs

Alessandro Vesely <vesely@tana.it> Sat, 15 April 2023 16:13 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 37DEEC14CE27 for <dmarc@ietfa.amsl.com>; Sat, 15 Apr 2023 09:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b="8OuCKNbZ"; dkim=pass (1152-bit key) header.d=tana.it header.b="CoX5XyFM"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e55HqXV2tVWK for <dmarc@ietfa.amsl.com>; Sat, 15 Apr 2023 09:12:59 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [94.198.96.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECE9C14CEE3 for <dmarc@ietf.org>; Sat, 15 Apr 2023 09:12:56 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1681575175; bh=uRyo8hj5vhQaIr8Q10YIxMIQsglxoFA4fFgT0gmxYgE=; h=Author:Date:Subject:To:References:From:In-Reply-To; b=8OuCKNbZ5yQMzUnrLMabmcwjC25d+OoUbwAF7594r638m9cU549+lFo/le4eJ8y7j zNIQ+bLw4fFX579yvasDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1681575175; bh=uRyo8hj5vhQaIr8Q10YIxMIQsglxoFA4fFgT0gmxYgE=; h=Date:Subject:To:References:From:In-Reply-To; b=CoX5XyFMM22KrM8cDQb0fXsqjefU6ces7a7OSPfl0srNYqVMw/J5f2GgMl3jkbEFb R1usLpjHjDs9tuBJt77eDdPJCucZ8BwdkxOpcc4AQAgaToFPjOERcJAuUYPt+jcmae gtwR7BuoZBWNnORRtkKYP/cvehUG2YGoQb3kAezDOVa3703cfEB/F2AUmxoiF
Original-Subject: Re: [dmarc-ietf] Signaling MLMs
Author: 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 00000000005DC100.00000000643ACD07.00006133; Sat, 15 Apr 2023 18:12:55 +0200
Message-ID: <e96e75ac-8ef2-cd80-1663-24c10caf3028@tana.it>
Date: Sat, 15 Apr 2023 18:12:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0
Content-Language: en-US, it-IT
To: dmarc@ietf.org
References: <CAL0qLwZc2X7tyP+_8vvL3Yb7uJk6td3XGbsXUB68BNUEMhV4yQ@mail.gmail.com> <909C826B-2745-4BE8-AD16-920E6DE86D1C@kitterman.com> <329db752-fdeb-7633-ede1-06e435db1c0e@tana.it> <6600461.14hOuAKI9C@localhost> <CAH48Zfwgyr6EGb1Ty3v7gVzEDbMr5dig_GVz79gwqx4F0zsEZA@mail.gmail.com> <CAL0qLwZToWMh3cO-1zvvMZBFvo2o_PF+aRD58kAEZ0OObOcQNA@mail.gmail.com> <4b5aa1d9-dcb0-4abd-a149-b6bae30349f7@app.fastmail.com> <CAL0qLwaJU66JLE_GbUcyzR75Zbf25_i_c+v57NVKOoYNPp8CNw@mail.gmail.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <CAL0qLwaJU66JLE_GbUcyzR75Zbf25_i_c+v57NVKOoYNPp8CNw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/VGfLIZF5P4i5p7DkjFiLO3pZgEE>
Subject: Re: [dmarc-ietf] Signaling MLMs
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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, 15 Apr 2023 16:13:05 -0000

On Sat 15/Apr/2023 04:57:13 +0200 Murray S. Kucherawy wrote:
> On Fri, Apr 14, 2023 at 7:32 PM Jesse Thompson <zjt@fastmail.com> wrote:
>> On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:
>>
>>> The Sender's users being denied the ability to participate in a list due 
>>> to its policies seems to me like it puts this customer service problem 
>>> where it belongs.
>>
>> Let's say, tomorrow, IETF configures this list to reject Todd's mail (as 
>> well as for every other member with p=reject) and/or disables from 
>> rewriting. Does Todd's domain owner care? No.
>
> This is where it breaks down for me.
>
> What's the calculus here?  The domain owner decides that protecting its 
> name in this one targeted way is so valuable that it's fine with whatever 
> negative impact it has downstream?  And we're supposed to be OK with giving 
> this sort of approach a blanket green light by not declaring such use of 
> DMARC not interoperable?  And we're fine with giving their biz dev, PR, 
> legal, and all the other teams you named a pass on dealing with the 
> aftermath?  Because as I think you can see, those are not the teams in the 
> trenches figuring this out.
>
> Why do you believe that the domain owner and its users shouldn't feel the 
> pain for such a decision?  That its customers go someplace else that does 
> care about these things?  Or that it has to split its mail flows into 
> something general purpose and something transactional in the name of 
> continued interoperability?


MLM damage is evident.  However, our calling transactional the mail flows that 
don't risk indirect delivery is unreal.  Limiting DMARC to transactional mail 
flows is not a step we can rely upon, as receiver-side forwarding does exist.

MLM traffic is 99.9% indirect (≈0.1% for list masters who participate from the 
list domain).  Chances to run into a forwarded address are much lower, but 
absolutely positive.  So, why don't we say that forwarders MUST NOT break DKIM 
signatures?  Some of them do.  Doesn't that disrupt forwarding just like it 
disrupts MLM?

The transactional vs. general purpose dichotomy relegates us to a protocol that 
/sometimes/ works, which I consider utterly improper.


Best
Ale
--