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

Scott Kitterman <sklist@kitterman.com> Wed, 26 April 2023 03:46 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 A3B02C151985 for <dmarc@ietfa.amsl.com>; Tue, 25 Apr 2023 20:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 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_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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="Mnvmr318"; dkim=pass (2048-bit key) header.d=kitterman.com header.b="jbqlBXWY"
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 vGRXF1oEUQek for <dmarc@ietfa.amsl.com>; Tue, 25 Apr 2023 20:46:15 -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 D7379C1516F2 for <dmarc@ietf.org>; Tue, 25 Apr 2023 20:46:15 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id B93E6F80239; Tue, 25 Apr 2023 23:46:03 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1682480749; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=psJvxBJubbO9t2PHXBDF5JFDYZ6ELykDeCzVIITJZN8=; b=Mnvmr318MqkVTa+xMkd7ZBgdAHMu9G8L31r7HnTgV4xbHETRlH8ewszOuB76vPVBvY4FC 9hP1V3lt/AHxN1oAQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1682480749; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=psJvxBJubbO9t2PHXBDF5JFDYZ6ELykDeCzVIITJZN8=; b=jbqlBXWY6wHilonp8K72DIg08mWYDw6a2ASxTKntCqj2xS+ctTJdYnvfCiqPYq6YPQVKj kvOQI/+00lfPzdcSMadzgYGyF1TgonM/QY5urIadPs3VCgVu6/YOgPB8qdqb2+WTfYKW1t2 FSu/wHVq/5szttODD4WIyVLD3gfuX63SiT/YzTytjEcUDrF/ETqW4HvcPYMGpi4yB5XBie/ /wHUR+M59HH74tN8N4/KjxESWitx/PRWpjHJUy1uOppn5eMI9haS+lb0/k04CbXLg4NNyLD CAJHzZU9EcwPH9xtlHoL53vYLRUTD3Pjk9/v/r4kwHSjbVHAu3MksHqNeWwA==
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 E2321F801A4; Tue, 25 Apr 2023 23:45:48 -0400 (EDT)
Date: Wed, 26 Apr 2023 03:45:44 +0000
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
In-Reply-To: <a0b5e634-529f-4b6e-8737-661e9fedba4b@app.fastmail.com>
References: <20230426010600.BDEC4C4E1FC2@ary.qy> <a0b5e634-529f-4b6e-8737-661e9fedba4b@app.fastmail.com>
Message-ID: <709F2F72-9D99-4A42-8C0E-4EBF2631D89E@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/hvoEbgXtXgHqgnpPAftUThDmwt8>
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: Wed, 26 Apr 2023 03:46:20 -0000


On April 26, 2023 2:23:52 AM UTC, Jesse Thompson <zjt@fastmail.com> wrote:
>On Tue, Apr 25, 2023, at 8:06 PM, John Levine wrote:
>> It appears that Scott Kitterman  <sklist@kitterman.com> said:
>> >My recollection is that a general formulation that I proposed had at least 
>> >some traction out of both groups:
>> >
>> >> [some appropriate description] domains MUST NOT publish restrictive DMARC
>> >> policies due to interoperability issues
>> 
>> This seems like a reasonable approach. As a purely practical point, I
>> cannot imagine this document getting through the IESG without some
>> clear guidance about DMARC's interop issues.
>> 
>> R's,
>> John
>> 
>> PS: If anyone was going to suggest we just tell people how to change
>> their mailing lists to work around DMARC, don't go there.
>
>How about:
>
>Domains owners who have users who individually request 3rd parties to emit mail as an address within the domain MUST NOT publish a restrictive DMARC policy if they wish to support their users' usage of any potential 3rd party. Examples of 3rd parties include mailing lists and email service providers. These 3rd parties are not always aware of, or willing to work around, DMARC. Domain owners implementing DMARC as a means for governance by restricting the unauthorized usage of the domain MUST be aware that not all of the 3rd parties will make changes to work around DMARC, resulting in interoperability issues for their users' usage of the 3rd parties. Domain owners SHOULD provide an alternative address for these users within a cousin domain or subdomain that is not directly associated with the organization's brand-associated domain that is used for marketing and transactional email that needs the security benefits of DMARC. These users MUST use an address within a domain that does not have a restrictive DMARC policy.
>
>(Not a troll. Not directly aware of humming (sorry, it's on my bucket list). Hopefully, didn't touch the 3rd rail. Honestly, in good faith, representing the perspective of an extremely large domain owner, users within said policy-restricted domain, and as a 3rd party commonly used by these, and similar, users.)
>

I never really got humming either (I mean I understand the theory and that it works, but that doesn't make it not weird in my book).

I can see what you're attempting here and I see the logic.  I think the normative part would need to be about 90% shorter.

I think it misses the impact on innocent bystanders.  When you send mail from a domain with a restrictive policy and indirect recipients reject that mail, the intermediary gets the bounce and things like involuntary unsubscriptions from mailing lists result.  It's not just about the impact on the relevant domain.  It's also about third party impacts.

Thanks,

Scott K