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

Alessandro Vesely <vesely@tana.it> Wed, 06 April 2022 10:08 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 285CF3A185D for <dmarc@ietfa.amsl.com>; Wed, 6 Apr 2022 03:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=tana.it header.b=27MD8HxP; dkim=pass (1152-bit key) header.d=tana.it header.b=C25V3awI
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 X78-CtOchYzd for <dmarc@ietfa.amsl.com>; Wed, 6 Apr 2022 03:08:26 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE073A1897 for <dmarc@ietf.org>; Wed, 6 Apr 2022 03:08:22 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1649239700; bh=vQBPOtekDycH3KZpTkZc+mO4cJ9h4DIF9TLkDeDnWIo=; h=Date:Subject:To:References:From:In-Reply-To; b=27MD8HxPeG0eL721pmNZV+RGAfv39d13qpAfr8vPGQWPZRrr0jBislHg4H405DNc/ fJtN4JOfESKZYX7+DWTCw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1649239700; bh=vQBPOtekDycH3KZpTkZc+mO4cJ9h4DIF9TLkDeDnWIo=; h=Date:To:References:From:In-Reply-To; b=C25V3awIg60QOt2+SkX0KOikk6Vi1R5VHNztpce4I+zPTstSpOSqFHfL+eof4rKUf 6QF9FNqjWU36KU3CQVCt50y1V//UnC9bmhAe2tzsK+Nvp0mnXd6rsYzIyifK4qgSd9 quoCbmkkz00i6rFoUmZiYulRVaadCAWILGJpHit/2J6/WbYCFIAwsi2VKt+5u
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 00000000005DC033.00000000624D6694.00000965; Wed, 06 Apr 2022 12:08:20 +0200
Message-ID: <7341738e-27a0-17b6-d068-e1ea95dee904@tana.it>
Date: Wed, 6 Apr 2022 12:08:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: dmarc@ietf.org
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> <A2C3A80C-F7F6-4592-862D-C8759A6A4A11@kitterman.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <A2C3A80C-F7F6-4592-862D-C8759A6A4A11@kitterman.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/bHtWJyzURBVR_5FTVN0rmCHkzAw>
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 10:08:33 -0000

On Wed 06/Apr/2022 07:07:32 +0200 Scott Kitterman wrote:
> 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.


They can send mail, but they're different from an org domain in that the latter 
can have aligned subdomains.


>>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.


It is not that we ignore psd=y.  I'd say that in this case psd.example /must be 
treated like/ an org domain —although it isn't— with the restriction that 
alignment must be strict.


> Neither align since neither have the same org domain as the 5322.From.


Correct, for whatever definition of org domain.


> 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.


I agree that #2 is straightforward.  It follows also if we define alignment for 
either identical domains or both admitting identical org domains (as per my 
proposed amendment).


> 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.


+1,  #2 is the way to go.


Best
Ale
--