Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

Scott Kitterman <sklist@kitterman.com> Fri, 28 April 2023 02:53 UTC

Return-Path: <sklist@kitterman.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 EC1C4C151535 for <dmarc@ietfa.amsl.com>; Thu, 27 Apr 2023 19:53:02 -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, 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=kitterman.com header.b="bIhyIr3F"; dkim=pass (2048-bit key) header.d=kitterman.com header.b="jHOB9AjO"
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 oWS2VYYdzeML for <dmarc@ietfa.amsl.com>; Thu, 27 Apr 2023 19:52:58 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (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 C147DC151707 for <dmarc@ietf.org>; Thu, 27 Apr 2023 19:52:58 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id EA51AF80295; Thu, 27 Apr 2023 22:52:45 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1682650350; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=452shvEc+2nbo5WR0f7Ev6KBsbjMGhrQ6CN/m7l5NeE=; b=bIhyIr3F2igR7b2zZZW6VezY4iyxAg+jPGX5KGgcYHmhHtzomJNwmftULpu/hNz3M/UNo Vvfr/qrL1eGzwE8DA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1682650350; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=452shvEc+2nbo5WR0f7Ev6KBsbjMGhrQ6CN/m7l5NeE=; b=jHOB9AjOxNaxEKLJoW7apIrJIwaWZ+ByB91WXszwxaC8y5m+dGjQvAE14XczcxximO5Om 3wDgTXqW3PJmYRm1NMq2R17WwXt/NiczWdZhrp8PgpyEJ/CLPibZzdp7F4JzzQ8j/tDJifU W5VHvgZmEToPuwpwnBJRaMDPj6lBV0Q9qF7nlAYInCstsEN7VI1YdqOC0xM6FYWfNpRNMEV MiuXrxBBDt7LbEpwmIeELi9bfGndhlkGeI1uBg4bvOUEAMSTLKI0fRwn2FaTpaB3IMNXR7f NJSKiZNf3B4FhY7wZdhRwRxssLiMvcMeRQpGszVYtINNMPFBfESfJeflp21A==
Received: from [127.0.0.1] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 7D79CF8014A; Thu, 27 Apr 2023 22:52:30 -0400 (EDT)
Date: Fri, 28 Apr 2023 02:52:24 +0000
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
In-Reply-To: <8fdcf7ce-f154-4a2a-80b8-12a6e53f4aa7@app.fastmail.com>
References: <20230426160609.8532BC586620@ary.qy> <B08C7AD1-B14B-43FC-BE85-DFBD5282A8DB@bluepopcorn.net> <BF125E76-EAEF-468B-93F2-3318736F932F@kitterman.com> <MN2PR11MB43511D3478D3682AABD35969F76A9@MN2PR11MB4351.namprd11.prod.outlook.com> <8fdcf7ce-f154-4a2a-80b8-12a6e53f4aa7@app.fastmail.com>
Message-ID: <31A475FB-09B8-4F49-9F16-990B434B9BFB@kitterman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/kFf9fzEweZ-O9MV3f58SSAcTd5I>
Subject: Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows
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: Fri, 28 Apr 2023 02:53:03 -0000


On April 28, 2023 2:25:57 AM UTC, Jesse Thompson <zjt@fastmail.com> wrote:
>On Thu, Apr 27, 2023, at 9:30 AM, Brotman, Alex wrote:
>> Attempt to make it a tad more concise (I think), altering some of the language:
>> 
>> ---------------------
>> There can be inherent damage to the ability to use certain SMTP-based systems in conjunction with a policy of quarantine or reject.  These could include, though are not limited to, mailing lists, forwarding services, and other types of indirect mail flows.  Especially in situations where the sending domain is SPF-only, or the intermediary is known to alter messages.  If the users of the domain may utilize these types of systems, the domain administrator MUST NOT deploy a policy of quarantine or reject without serious considerations to the impact to interoperability.  These considerations will be informed by careful analysis of DMARC aggregate reports prior to deploying such a policy.  Some third-party systems may be willing to create a workaround for these situations, though it cannot be guaranteed.  Domain owners MAY choose to create a sub-domain (listmail.example.org) or cousin domain (listmail-example.org) which uses a different policy for users wishing to utilize those services.
>> ---------------------
>
>I like this, and it gives room for best common practices to evolve that don't necessarily conflict.
>
>s/
>    Especially in situations where the sending domain is SPF-only, or the intermediary is known to alter messages.  If the users of the domain may utilize these types of systems, the domain administrator MUST NOT deploy
>/
>    For situations where the sending domain is not DKIM signing all of its traffic in an aligned fashion or there is legitimate use of an intermediary known to alter messages, the domain administrator MUST NOT deploy
>/x

I think most of this would be good in a non-normative appendix.  For my immediate purpose, I'm imagining that in addition to the [adjective] domain, there would need to be an amplification of [adjective] that would explain exactly what we mean by [adjective] and what actions a domain owner might take in order to be [not adjective].

I don't think it's formally part of the protocol, but it's quite important.

Scott K