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

Alessandro Vesely <> Sat, 10 August 2019 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9C1E120123 for <>; Sat, 10 Aug 2019 03:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 XbEtWi-wBJh5 for <>; Sat, 10 Aug 2019 03:36:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E001E12024F for <>; Sat, 10 Aug 2019 03:36:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1565433404; bh=bGp7zP82o4EpTH11UhNo6v6npQ2DyuQFOcejdE3eIuM=; l=2807; h=To:References:From:Date:In-Reply-To; b=DgZJji4NVn8g1uiD07UrNTQbsrUbgpCBFeToMPGzhSSYMV0UaNkv+Ig0dT/89yTbd GU/5od2CR16OZQN5P/Bcn+kdWIAIzEkVQ3hNdqUueVpB7Xf1RWR7C5AwAemihaCBCy 0hOn4toBRwg3CJ50gBXRyGCPtCrwGTpoJewSOuSj9IUFVtOdCQKHvvnJyFhUz
Authentication-Results:; auth=pass (details omitted)
Received: from [] ([]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by with ESMTPSA id 00000000005DC03D.000000005D4E9E3C.0000677B; Sat, 10 Aug 2019 12:36:44 +0200
References: <> <3966163.57549G4C0j@l5580>
From: Alessandro Vesely <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Sat, 10 Aug 2019 12:36:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <3966163.57549G4C0j@l5580>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-06.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, 10 Aug 2019 10:36:55 -0000

On Sat 10/Aug/2019 08:49:29 +0200 Scott Kitterman wrote:

> Note the updated abstract and please review the changes to the first part of 
> the introduction as I had to write new text there and not just incorporate 
> msk's comments.  This covers all the pending work of which I am aware.

The intro looks smooth.  Perhaps, for maximum clearness, you could add a sentence after the first one of the second paragraph:

   As an example, imagine a country code TLD (ccTLD) which has public
   subdomains for government and commercial use (.gov.example and
   .com.example).  They are both on the public suffix list, although
   gov.example is not really available for public registrations, domains
   under it belong to different branches of the government.  Suppose
   there exists a registered domain "" that is responsible
   for taxation in this imagined country.  [...]

Excuse me, but I hadn't noted the following in Murray's message of Aug 1st:

   Experience with DMARC has shown that some implementations short-
   circuit messages, bypassing DMARC policy application, when the domain
   name extracted by the receiver (from the RFC5322.From) is on the
   public suffix list used by the receiver.  This negates the capability
   being created by this specification.  Therefore, the following
   paragraph is appended to Section 6.6.1 of DMARC [RFC7489]:

   Note that domain names that appear on a public suffix list are not
   exempt from DMARC policy application and reporting.

First, it's not easy to read, as the concept of PSL "used by the receiver", albeit obvious, is new.  The whole idea is better expressed by the last three lines in the abstract.

Second, Section 6.6.1 of RFC 7489 deals with the uniqueness of the From: domain.  The idea of a PSL is brought forward in a subsequent section (policy discovery).  If the note has to go there, I'd rather insert it between the first and the second paragraphs of that section.  The last paragraph there seems to conflict with the second bullet, and adding the note above after it is not going to make things clearer.

The next section has:

   As an example, for a message with the Organizational Domain of
   "", the query for PSD DMARC
   would use "" as the longest PSD
   (Section 2.3).  The receiver would check to see if that PSD is listed
   in the DMARC PSD Registry, and if so, perform the policy lookup at

It is not natural to spot which is the organizational domain, because the names are misleading.  Cloudcompany looks like a name registered under the com.example PSD; how come is the longest PSD?  I'd stick with the gov.example introduced earlier.