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

Scott Kitterman <sklist@kitterman.com> Tue, 05 April 2022 22:58 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 DED323A1534 for <dmarc@ietfa.amsl.com>; Tue, 5 Apr 2022 15:58:32 -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=SeYtL4qY; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Tz4mYzMF
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 qK62eNpQFgP0 for <dmarc@ietfa.amsl.com>; Tue, 5 Apr 2022 15:58:28 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103363A14EC for <dmarc@ietf.org>; Tue, 5 Apr 2022 15:58:23 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 0C2CFF80260 for <dmarc@ietf.org>; Tue, 5 Apr 2022 18:58:23 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1649199502; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=8LEK3d7kIehOGtCoJATh/P86YcDrQIqjnbBzJqkLQTA=; b=SeYtL4qY91BpPpE9cgL9OPCxkRVErzEDp+K5L+TjFHhgXfmQMQ3PDrbHNkt+0mkXtNEEZ im8BRBPyGdwmk7fDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1649199502; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=8LEK3d7kIehOGtCoJATh/P86YcDrQIqjnbBzJqkLQTA=; b=Tz4mYzMFmslm+7mS57NKc8KYqkjY3QXwkUmEumgbrWbIHSQD15tht6BUTTVYCqahkYuaq 6m48JZ0oKdhApIjy6ysQWIbSt+S0ymUgVA+m/302QdSVNVlH+E1cZANhaL5iGFXraemgrg5 edJV8DDbfMUEEAo+XAHWX8/9vY30GdttqcBzi1UsQ/WB3sqcqRUla4W+IpdWVnU0xXoV5TE O+fRyWeMp8sRBt4N/2P6mOkK7qoPb6WbnRPReaHBEazuAHwsVUWOMTUmt6zytxOhDoXOnFz pzpCCp1JegjfnNzSAy3Q7erEc8416iVyJVWpx3eTenG0VTDXSrIX/CnuzabQ==
Received: from zini-1880.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id E2772F8014F for <dmarc@ietf.org>; Tue, 5 Apr 2022 18:58:22 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Tue, 05 Apr 2022 18:58:22 -0400
Message-ID: <21420145.PrrHkNjdJ7@zini-1880>
In-Reply-To: <c99eb896-eef9-1a89-60d6-3f2412b03a9a@tana.it>
References: <20220403024904.479EA3A462E4@ary.qy> <2550778.P67xgtABij@zini-1880> <c99eb896-eef9-1a89-60d6-3f2412b03a9a@tana.it>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/aAhMJ50eO9K6yWdZy2JExGzgte8>
Subject: Re: [dmarc-ietf] 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: Tue, 05 Apr 2022 22:58:33 -0000

On Tuesday, April 5, 2022 4:43:49 AM EDT Alessandro Vesely wrote:
> On Mon 04/Apr/2022 15:29:40 +0200 Scott Kitterman wrote:
> > The diff is relative the last text I posted.
> 
> Section 5 has to stay before Section 4.  It makes no sense to exemplify
> _dmarc.example.com if we haven't yet said that:
> 
>     Domain Owner and PSO DMARC preferences are stored as DNS TXT records
>     in subdomains named "_dmarc".
>                                                    [Current Section 5.1]
> 
> 
> Then, let's make a statement like so:
> 
>     Retrieving the DMARC record of a domain implies the following steps:
> 
>     1.  Prepend the label "_dmarc" to the domain name and issue a DNS Query
> for a TXT record at the resulting domain.  For example, if the domain is
> example.com, query _dmarc.example.com.
> 
>     2.  Collate any string returned, in the order returned.
> 
>     3.  Records that do not start with a "v=" tag that identifies the
>         current version of DMARC are discarded.  If multiple DMARC
>         records are returned, they are all discarded.
> 
> 
> At this point, the algorithm can be expressed in a shorter form like so:
> 
>     1.  Set the current target to the identifier at hand, which is one of
> the domain(s) described above.
> 
>     2.  Retrieve the DMARC record of the current target.
> 
>     3.  If the record exists and contains either psd=y or psd=n, stop.
> 
>     4.  Break the current target name into a set of "n" ordered
>         labels.  Number these labels from right to left; e.g., for
>         "a.mail.example.com", "com" would be label 1, "example" would be
>         label 2, "mail.example.com" would be label 3, and so forth.
> 
>     5.  Count the number of labels in the current target.  Let that number
>         be "x".  If x = 1, stop.  If x < 5, remove the left-most (highest-
>         numbered) label from the subject domain.  If x >= 5, remove the
>         left-most (highest-numbered) labels from the subject domain until
>         4 labels remain.  The resulting DNS domain name is the new target
>         for subsequent lookups.
> 
>     6.  Go to 2.
> 
> 
> Better?

Maybe.  I'd say lets get a draft out that we agree gives the correct result 
before we start re-writing for taste.  I don't think the order matters that 
much.  An RFC is not a single pass compiler.

Scott K