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

Alessandro Vesely <vesely@tana.it> Mon, 04 April 2022 08:19 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 1330C3A1B07 for <dmarc@ietfa.amsl.com>; Mon, 4 Apr 2022 01:19:42 -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=H+sOTAfp; dkim=pass (1152-bit key) header.d=tana.it header.b=CtRFMh2/
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 IakKiJfP0R4s for <dmarc@ietfa.amsl.com>; Mon, 4 Apr 2022 01:19:33 -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 103AE3A1191 for <dmarc@ietf.org>; Mon, 4 Apr 2022 01:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1649060364; bh=WsXWwebvxFqSN9KnM8bV75KfGD3vS9yRxSbfcPmPnP4=; h=Date:Subject:To:References:From:In-Reply-To; b=H+sOTAfpDXMH9T03DCIgtLtTz2yaDwyMx1+dsOshyF0xa0caqm0yIoRMy7d4jz05r lPgrDfK0OdwB32YSkDmAw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1649060364; bh=WsXWwebvxFqSN9KnM8bV75KfGD3vS9yRxSbfcPmPnP4=; h=Date:To:References:From:In-Reply-To; b=CtRFMh2/OB7zwrQ3VYscVYVPOeEiqDRmGSU2IbUji4d1tPQ+nf1xfvcrtaAH0Jkk4 Ii9f/PvGxHvaO6gV6vjGUAClNsukT+GXXXLH+/GKCraumRwKR0jLNLz1MEIe5r63jq HnyaegVxuMx1vf9m8l/1C/0eqcOSsjpVZ88T8+0prpxfu1K29eRgbDjzxnwD7
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 00000000005DC0ED.00000000624AAA0C.000020C5; Mon, 04 Apr 2022 10:19:24 +0200
Message-ID: <f1ae6447-0f91-39e5-fdbe-e6f9edba31c4@tana.it>
Date: Mon, 4 Apr 2022 10:19:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2
Content-Language: en-US
To: John R Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20220403024904.479EA3A462E4@ary.qy> <45a019b3-3f97-6c56-409b-5a3f9f2d06ba@tana.it> <83bed554-8def-0952-28e8-47cf6abe67df@taugh.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <83bed554-8def-0952-28e8-47cf6abe67df@taugh.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/O1DfgIJcGMYmF4rWc2WKqs_yRYE>
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: Mon, 04 Apr 2022 08:19:42 -0000

On Sun 03/Apr/2022 18:07:29 +0200 John R Levine wrote:
> On Sun, 3 Apr 2022, Alessandro Vesely wrote:
> 
>>> (If the one beneath it has no DMARC record, is it still the org domain? I 
>>> think it is.)
>>
>> This seems to be inconsistent with the sentence that follows.  Would the 
>> landscape change if .com suddenly publishes psd=y?
> 
> Currently with the PSL lookup, foo.com is an org domain whether or not it 
> publishes a DMARC record, and mail.foo.com and sales.foo.com are in relaxed 
> alignment.  While I think it would be reasonable to say that an org domain has 
> to publish a DMARC record if it's going to be used for relaxed alignment, that 
> would be a change from the current rule.


The current definition, Section 3.2.7, replicates the original semantic:

3.2.7.  Organizational Domain

    The Organizational Domain is typically a domain that was registered
    with a domain name registrar.  More formally, it is any Public Suffix
    Domain plus one label.  The Organizational Domain for the domain in
    the RFC5322.From domain is determined by applying the algorithm found
    in Section 4.8.

The last sentence is particular in that Section 4.8 aims at determining the 
Organizational Domain for /any/ identifier, not just the From: domain.  We are 
assuming that an org domain can be determined for any domain, always.

At the end of Section 4.8, in order to fulfill that assumption, in the absence 
of DMARC records, "the initial target domain" is promoted to the rank of 
Organizational Domain of itself.  That way, a PSD /is/ an org domain, which 
formally counters the second sentence in 3.2.7.


> Since there is no chance that .com .net .org or other large TLDs will ever 
> publish a PSD record it makes little difference in practice, but if we agree 
> the org domain needs a DMARC record, we should make clear that this is a 
> deliberate change.  It's a good idea since if foo.com has no DMARC record and 
> .com has no PSD record, it won't work as an org domain anyway.


To make the change clearer, I suggest to use different terms to indicate 
"working" org domains and registered domains with no DMARC record.  Perhaps 
using the circumlocution DMARC Organizational Domain could suffice.  However, 
along with the ubiquitous use of other longish terms (such as the above domain 
in the RFC5322.From domain), it makes for a rather wordy spec.  Better names?


Best
Ale
--