Re: [dmarc-ietf] Signaling MLMs

Jesse Thompson <zjt@fastmail.com> Sat, 15 April 2023 02:32 UTC

Return-Path: <zjt@fastmail.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 7B9F4C14CE40 for <dmarc@ietfa.amsl.com>; Fri, 14 Apr 2023 19:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=pass (2048-bit key) header.d=fastmail.com header.b="ebnmmQ+j"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="EgVMFsGp"
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 6cymU8waNm9t for <dmarc@ietfa.amsl.com>; Fri, 14 Apr 2023 19:31:57 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A51DC14F6EC for <dmarc@ietf.org>; Fri, 14 Apr 2023 19:31:56 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id DDB8632007CF for <dmarc@ietf.org>; Fri, 14 Apr 2023 22:31:53 -0400 (EDT)
Received: from imap42 ([10.202.2.92]) by compute1.internal (MEProxy); Fri, 14 Apr 2023 22:31:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1681525913; x=1681612313; bh=lf t8Y+IZGsyfef4sBrUEjs4wv1PQDqPRZJb4lfUzUMQ=; b=ebnmmQ+j4zbKfuIvvQ lsO+H7FkIKieUuJPmznlDNItf3qARotvCVf5CvBnonng3ACPATRxnF2m2qZIKqaQ pJCRVaxfNVvc0gac2eJ7h+sbNfE/fWYUBENPFLU4VdYRFZEk/0qUOflKWlSKqJ/p WJYlBYsEeWswciKpv0kTVItbUqRA7+F3JOf3UdfZcwbmFxUIqlQ/x2KyQ8DvSxaZ CT1kxZfATN09rFDgSi/CJ01GxsfsUxzMI8om9hPVQqB0eYHgqya7I65vpLQh5T2I vd7tRlNpmV5uDibh7BETmnEIhXQ5rApjV2sCziP+IVOAV+aY8qkyN3mUBROg+2pz Fd6A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1681525913; x=1681612313; bh=lft8Y+IZGsyfe f4sBrUEjs4wv1PQDqPRZJb4lfUzUMQ=; b=EgVMFsGpsH2hj3xguPd+Dbl4mhWOX OUvqes93Mq2kTfih0tLR7Cnb/HxfBfHZTv4Lb2ZHf9Tx/TobcKS/pZHJTHwXzWVs NzOxKhwUjMhZ09Qp/defBB4jk3zzq8cJkwYxk+dxUSLbktm9ACxE5DBkyzF0I+TL guQfFtIzpDK462GyBgcozRPpWRmy3m7tF4Slj491xQqaYTKobcsUtlJipY4aMQUC p695sAZ/QTJtPFgtubpQF/fwmiDk1xKIl37MzLQGsHBNpuBnh4rxnSQX/2m5B923 36Vew/AE+6pn/M8xb1VSvuXveEzK82LV+PVESvX/nsZcuG7s/JyD+7XTw==
X-ME-Sender: <xms:mQw6ZHt0jS0hp7dY3nRV4ph11IEtP8fTBzHrC98xX5fDza7HsDOULQ> <xme:mQw6ZIc2O88w0ig10nLowEzFIDZx-PDNOkL5yYcn7a4-pPnKPMhpyj0NXGazPDo2A JGfQ782wH2GVlXFW7Y>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeluddgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedflfgvshhsvgcuvfhhohhmphhsohhnfdcuoeiijhhtsehf rghsthhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepuedtveekhfeuheekvdfhhf ffudfhgeelkedutdeuffeiveeiheeuhfefvedvlefgnecuffhomhgrihhnpehsphdrrghm necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepiihjth esfhgrshhtmhgrihhlrdgtohhm
X-ME-Proxy: <xmx:mQw6ZKzZB72CXaBB61fhnz5FHEEmAOBZinN32XUT45LOyyrBv0UWDA> <xmx:mQw6ZGOiW6ErZpWK0WduQs8RDVPO980ivDWksK-BMFYRVNc6jWV26A> <xmx:mQw6ZH_acNEe-v4fOR134xYLuZDf70o_j9K7QyUz7HR1cHUGohyO6g> <xmx:mQw6ZKLTq4E75DzeuvnjIOAsqAr7unqFJPMcNRXeafHuIDqHrMoqbg>
Feedback-ID: i1a614672:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 38ED1BC0078; Fri, 14 Apr 2023 22:31:53 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-334-g8c072af647-fm-20230330.001-g8c072af6
Mime-Version: 1.0
Message-Id: <4b5aa1d9-dcb0-4abd-a149-b6bae30349f7@app.fastmail.com>
In-Reply-To: <CAL0qLwZToWMh3cO-1zvvMZBFvo2o_PF+aRD58kAEZ0OObOcQNA@mail.gmail.com>
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>
Date: Fri, 14 Apr 2023 21:31:33 -0500
From: Jesse Thompson <zjt@fastmail.com>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="f9ed24d2ef7d4eb29bb8846d93fab590"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/EpIJrZbo0TWrRF2t4AEF7s_UgFQ>
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 02:32:02 -0000

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. Todd cares. Todd can't argue with his CISO and IT security team and biz dev team and public relations team and legal team and all of the other forces that caused his domain owner to publish p=reject. But he can argue with IETF for making the decision to make the change, because he feels like the IETF considers him an important stakeholder. 

It's this list's customer service problem, like it or not.

After calling IETF customer service, Todd finds out his options are:
1. Create an email address in a domain that houses members of the general public, instead of one that represents his identity as a member of a company.
2. Don't participate in the list.

But Todd is really important to this list, and doesn't like these options. Surely something can be done for an old friend? John, having been escalated this customer service dilemma seeks DMARCbis for guidance and finds:

...MUST NOT p=reject...  
(Todd's company is pretty clearly stating Todd mustn't be representing his company on any mailing list.) 

...Domain Owner MUST provide a different domain with p=none for mailing list participants. 
(Maybe they do, maybe they don't, but it's worth asking.)

...Mailbox providers MUST NOT reject or quarantine email based solely on a DMARC policy violation.
(John could ask each mailbox provider to create an exception to their DMARC policy enforcement)

and he also finds something like:

...If a mailing list would like to provide the best customer experience for authors within domains that violate the "MUST NOT p=reject" and to deliver the author's mail to mailbox providers violate their "MUST NOT solely enforce", for those authors the mailing list MUST rewrite the From header to use a different domain. This is a new mode of interoperability the mailing list may choose to adhere to.

John now knows what he MUST do to provide the best customer experience given the reality he finds himself in with an important stakeholder. He can choose to ignore that MUST as much as the domain owners and mailbox providers will choose to ignore their MUST NOTs.

I feel like there will be very few mailing lists that will ever stop rewriting (among those who are doing it), especially if DMARC adoption (publishing and enforcement) continues to rise. This is the new way of interoperating, in reality.

Throw them a bone so that they have a MUST to justify the things they had to do to interoperate all this time. It's not as easy for them to justify their reality with only this page <https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail> to lean on.

Jesse