Re: [dmarc-ietf] PSD vs org, 5.5.4. Publish a DMARC Policy for the Author Domain - dmarcbis-06

Scott Kitterman <sklist@kitterman.com> Wed, 06 April 2022 05:08 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 900DE3A0DE2 for <dmarc@ietfa.amsl.com>; Tue, 5 Apr 2022 22:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 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, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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=gxArBdU3; dkim=pass (2048-bit key) header.d=kitterman.com header.b=gdqFuHMi
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 c8tDr4_mdz50 for <dmarc@ietfa.amsl.com>; Tue, 5 Apr 2022 22:08:00 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06CAF3A0DDD for <dmarc@ietf.org>; Tue, 5 Apr 2022 22:07:36 -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 144BDF80249; Wed, 6 Apr 2022 01:07:33 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1649221652; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=1N2YYwxjHhdTYQKVXFV5+IKD75IocyfnMlQE/NYrE+E=; b=gxArBdU3tBUXagFFHirbCwO42cWbuDCo+PEY1SavO4Wp/n5gotva5VcikMq4GLWf6RIRS tcDsIIojvqsk1LeBQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1649221652; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=1N2YYwxjHhdTYQKVXFV5+IKD75IocyfnMlQE/NYrE+E=; b=gdqFuHMieWZaoylouafgA32SL0CqVszFdoZGy24VaIz3A9nd+geGT65K/RevhP71IXOT/ tqx3tpOZCqTr6PjJlgyViZrZPXxrooyFXs5ZUmcMrzVWWO6H5NNESQH4HfDj43Nrn1u0vSX WMStZ4wT1Kl0keDiAnIGw3M20CswOLhi0stffFoOdj3hzTNMBX+9mjdAdc2PLMZjz9yNfQn 0IBHylO7qPqTJbVjDjIAmoOxyRBS0FtPyxqRNowRltPjdcfpNldVJ09UsHfg/vLxWJtWIfO wQ2RMhCyEXXrvnw5/lg1rppjF1FPSj1LnpV0RF8LbliE6VybMrjNBYxRSpdQ==
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 C032BF8016F; Wed, 6 Apr 2022 01:07:32 -0400 (EDT)
Date: Wed, 06 Apr 2022 05:07:32 +0000
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
In-Reply-To: <9f276019-f7b7-c986-ffcb-912c3c26a48c@taugh.com>
References: <20220403024904.479EA3A462E4@ary.qy> <0c06b5b0-a298-479d-90b5-a17cfaa4e672@taugh.com> <362b2316-53fc-59bc-ba71-d9fe4b184c8a@tana.it> <1782962.OBcs8SkWkA@zini-1880> <9f276019-f7b7-c986-ffcb-912c3c26a48c@taugh.com>
Message-ID: <A2C3A80C-F7F6-4592-862D-C8759A6A4A11@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/crIpdzZ2GVOLY1RukhxxL6Zb-fw>
Subject: Re: [dmarc-ietf] PSD vs org, 5.5.4. Publish a DMARC Policy for the Author Domain - dmarcbis-06
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: Wed, 06 Apr 2022 05:08:06 -0000


On April 6, 2022 2:21:52 AM UTC, John R Levine <johnl@taugh.com> wrote:
>On Tue, 5 Apr 2022, Scott Kitterman wrote:
>>>> _dmarc.ac.me TXT "v=DMARC1; p=quarantine; adkim=r; aspf=r; fo=0; pct=100;
>>>> rua=mailto:dmarc@ac.me" ac.me mail is handled by 10 mail.ac.me.
>>>> ac.me TXT "v=spf1 mx ip4:89.188.43.10 ip6:2a02:4280:0:200:89:188:43:10 -all"
>
>> Generally speaking, I think that a PSD can send mail and it should be covered
>> by DMARC, so I disagree with the idea that a PSD can never also be an Org.
>
>How about if we say that if the initial domain has psd=y, that's the org 
>domain and you don't look anywhere else.  That is easy to explain and I 
>don't think we are likely to find anything that better matches the 
>expectations of people who send mail from PSDs.
>
>There are 44 domains in the "ICANN" part of the PSL that have MX records 
>and at least 400 in the "PRIVATE" part so I think it would be a good idea 
>to have a plan for how DMARC works for them.

Agreed as far as having a plan, but it would have to be more complicated or more restrictive than that, I think.

Let's take the example of:

5322.From: psd.example (which has psd=y)
5321.MailFrom: spf.psd.example
d= domain: dkim.psd.example.

If we just ignore psd=y for an exact match, then the org domain for psd.example is psd.example, spf.psd.example for SPF, and dkim.psd.example for DKIM.  Neither align since neither have the same org domain as the 5322.From.

I see two potential paths out of this:

1.  Slightly expand your proposal to say that if the 5322.From domain has psd=y, then the psd tag is ignored for all org domain determinations for the message.

2.  Just say explicitly, if you are a PSD, you have to make all three the exact domain (effectively like strict alignment only).

The current text says a domain is always its own org domain, so we have (without explaining it anywhere) defined #2 currently.  I think that's good.

PSDs, have already (mostly) told us that the name space below is administratively distinct.  The approach in #1 would give all their customers the ability to spoof them, which is suboptimal.  Additionally it would make the SPF and DKIM org domain determinations dependent on the org domain determination from the 5322.From.  That adds complexity and seems ugly.

A PSD that does control/trust the namespace below it (e.g. .mil) might not even need to bother with psd=y if they aren't worried about their registrants spoofing each other.

My suggestion is that we leave the process as is and add some explanation for PSDs on the implication of being a mail sending PSD that does DMARC.  It should be simple enough.

If the group agrees, I can write something up, but I don't think the next revision needs to wait for it.

Scott K