Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk

Alessandro Vesely <vesely@tana.it> Tue, 28 June 2022 16:33 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 A22A1C14F733 for <dmarc@ietfa.amsl.com>; Tue, 28 Jun 2022 09:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.002
X-Spam-Level:
X-Spam-Status: No, score=-4.002 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=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=tana.it header.b=0jpGTs6R; dkim=pass (1152-bit key) header.d=tana.it header.b=C1SMLWc/
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 Ee_uy_1wS7rO for <dmarc@ietfa.amsl.com>; Tue, 28 Jun 2022 09:33:25 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A4EC14CF1B for <dmarc@ietf.org>; Tue, 28 Jun 2022 09:33:21 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1656433995; bh=DcEMUrwttaavr9pnNeAkxQn4wzZBR+ePHP9rbZfiHQg=; h=Date:Subject:To:References:From:In-Reply-To; b=0jpGTs6R4k/+4Fa2gsvicK1tU94JT64ogXcbEGo6sGAOiIphtHfN5PshLJs6Dqvm1 6/5+zYAOqQoFuQEr4GFDw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1656433995; bh=DcEMUrwttaavr9pnNeAkxQn4wzZBR+ePHP9rbZfiHQg=; h=Date:To:References:From:In-Reply-To; b=C1SMLWc/bl68mKbFZyCPziykPKdb8RhZA4EavTtq1Evgm3aXySQ6uHUoHMgSIT9F+ 5tw3E/4gpKifNPTqyMdAOSHuAltf6fkwGUlyU4qn7wQT4vpUKgwvjvW8neda2jI9OX ZCW4RJK1gyOXLT/mrjLvnQUx11E8HTQdqLB99vODhAo7DwRUuT/6yFO6RtceU
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 00000000005DC0E3.0000000062BB2D4B.00007CC4; Tue, 28 Jun 2022 18:33:15 +0200
Message-ID: <be56e041-d588-c8e7-bd37-bf2858773b75@tana.it>
Date: Tue, 28 Jun 2022 18:33:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
Content-Language: en-US
To: John R Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20220626154211.6893F4452D0F@ary.qy> <2bc4e123-8711-7538-599e-727d8ea9caff@tana.it> <bedf51e9-6fe6-d52b-1083-bac67d8906ea@taugh.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <bedf51e9-6fe6-d52b-1083-bac67d8906ea@taugh.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/WkWpgK26UNF3HtTtXz2ZIYqOx78>
Subject: Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk
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: Tue, 28 Jun 2022 16:33:31 -0000

On Mon 27/Jun/2022 15:54:51 +0200 John R Levine wrote:
>> Please recall what you said in April:
>>
>>    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.
>>     https://mailarchive.ietf.org/arch/msg/dmarc/UEwREV5oDD0BoyNpaUB9GN6ixtI
> 
> I thought about it some more and changed my mind.  That occasionally happens.


Right, but how about discussing the merit of it?

What can one find continuing the walk after psd=y?

For example, let's consider an imaginary bank, com.bank, say.  They use that 
domain as corporate domain, and have a DMARC record.  They also delegate zones 
to local subsidiaries.  One of them, uk.com.bank in turn delegates to other 
banks in the UK and sends mail like uk.com.  So you may end up having a DMARC 
record at each level:

bank -> psd=y,
com.bank -> psd=n or psd=u (for private use),
uk.com.bank -> psd=y.

Does our model support that?  How else should they set their records up?


Best
Ale
--