Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt

Alessandro Vesely <> Sat, 20 March 2021 11:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8AF63A2080 for <>; Sat, 20 Mar 2021 04:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Status: No, score=-2.12 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1152-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iYo7sduoniuo for <>; Sat, 20 Mar 2021 04:41:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D47133A207F for <>; Sat, 20 Mar 2021 04:41:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1616240482; bh=8QaoTC/qkTz3UOXU0SG1jfaQ+5Np+Np19vGWxwMM3nc=; l=1557; h=To:References:From:Date:In-Reply-To; b=Br1IQA/CvgXfF9erPP5M4bQLJXCYn1rfN4CZHjOxP3XuG4MIhgUnGl2bhz/mj9+8r sTImZj5zF4y1DSzFN1QuD7nkx+bmCZyChsauiRZ9gQki+CnNdAfVkUhh+TE6jsYoND PJFfIXuflo1RRRfYtlGpjSnTFk45KDJI8w4N31lr6tp1HFtFFN2Rtl4+RCt8c
Authentication-Results:; auth=pass (details omitted)
Original-From: Alessandro Vesely <>
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by with ESMTPSA id 00000000005DC0CB.000000006055DF62.00007A45; Sat, 20 Mar 2021 12:41:22 +0100
To: Tim Wicinski <>, IETF DMARC WG <>
References: <> <> <>
From: Alessandro Vesely <>
Message-ID: <>
Date: Sat, 20 Mar 2021 12:41:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Mar 2021 11:41:31 -0000

On Sat 20/Mar/2021 01:38:40 +0100 Tim Wicinski wrote:
>> NEW
>>      o  Branded PSDs (e.g., ".google"): These domains are effectively
>>         Organizational Domains as discussed in [RFC7489].  They control
>>         all subdomains.  These are effectively private
>>         domains, but listed in the Public Suffix List.  They are treated
>>         as Public for DMARC purposes.  They require the same protections
>>         as DMARC Organizational Domains, but are currently unable to
>>         benefit from DMARC.
> Hmm, "Public Suffix List" is in this paragraph.  Needs rethinking.

Oops, I missed a couple of those "Public Suffix List" entries.  That term was 
where the conundrum stemmed from, possibly because we're unsure how much we 
want to bind DMARC to the only PSL implementation we know.  That's why we want 
to avoid that term.

OTOH, the term "Public Suffix Domain" (PSD), seems to be sound.  It is often 
defined as "a domain under which multiple parties that are unaffiliated with 
the owner of the public suffix domain may register subdomains."  We can say 
that a domain "formally is a PSD" rather than it "is listed in the PSL".  The 
faint semantic difference between the two phrases is the source of the conundrum.

Being a PSD refers to a kind of contract.  ICANN mentions the above definition 
in a Policy Update issue[*], referring it to an expired IETF draft.  Should our 
I-D include such a definition?


ICANN Policy Update | Volume 15, Issue 5 | Pre-ICANN53, June 2015