Re: [dmarc-ietf] PSD simplification

Scott Kitterman <> Wed, 12 December 2018 05:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B24D21310AB for <>; Tue, 11 Dec 2018 21:02:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=Q8nchoXc; dkim=pass (2048-bit key) header.b=gsuq8uV+
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Szfv8IBu0sxH for <>; Tue, 11 Dec 2018 21:01:58 -0800 (PST)
Received: from ( [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DE5212875B for <>; Tue, 11 Dec 2018 21:01:58 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201812e; t=1544590913; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=koKCqSKWm+CFZUkQhVgjXPJugEMpdbO84GBNhPC2n+o=; b=Q8nchoXcmVGAxqiWm8ZzNoDKpUJYmErxPfqLtNRu7ID78iCrv5Qgl4M+ h/Bdf9UUw6ARYglawec2q1gbD3IVAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201812r; t=1544590913; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=koKCqSKWm+CFZUkQhVgjXPJugEMpdbO84GBNhPC2n+o=; b=gsuq8uV+ftRMGJ4UibFnroLROVYHzIlkivC0HukJzaYyoREK7iQReKoy 9UTZsEGbGQFwjnYwBhR4KOTjr8/WbTrORVrkPvVob/bUP3UCYDBK/WM2vZ WwR2KFt6DN1R+St5pMk42lJaWYkiVcj5hiexQVI0R8ebCMfwVkW0WIme5q VhJtIPpjF+JfQVWN2EEHEuJkjU2aBR9C8cgGLeSHKVKf02ifl1+Eh2uy6F fdZt76//z0h3E73KD/g1AeesDBximTVtkZpJ6YZ7ZO+rghSFpDtd7LyPHy s/IM6QnRjzgudMUAX9UKa1DDATiMbeVOIpfSEVpdO5ZQ+Tn+7KVPcQ==
Received: from kitterma-e6430.localnet ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1C1592D4062B for <>; Tue, 11 Dec 2018 23:01:53 -0600 (CST)
From: Scott Kitterman <>
Date: Wed, 12 Dec 2018 00:01:47 -0500
Message-ID: <8090288.RMFQGzStmc@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-163-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <>
Subject: Re: [dmarc-ietf] PSD simplification
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: Wed, 12 Dec 2018 05:02:01 -0000

On Tuesday, December 11, 2018 08:17:38 PM Dave Crocker wrote:
> Folks,
> Howdy.
> This note is the result of some offline discussions, patiently helping
> me to work through the purpose of the kitterman-dmarc-psd.  After some
> false starts, here's where I landed:
> I believe the registry created by kitterman-dmarc-psd is not needed.
> More generally I believe the proposal spec can be considerably abbreviated.
>      1.  If the registry is to constrain which public suffix operators
> are constrained to assert a default record, then I'll claim that's a
> false sense of security, given the range of unrelated and even more
> serious powers a parent domain can exert over a subordinate one.
>      2.  If it is to avoid wasting a DNS a query to a record that won't
> be there, that's false economy.  Most queries to the registry will fail.
>    And most queries to both the From: domain name and its organizational
> domain already fail. The incremental cost of a wasted query to the
> organizational domain's parent is pretty small.
> And the cost of creating and running a query-able database that is kept
> current is high and error-prone (as the existing PSL demonstrates.)
> So I think that the functional goal of kitterman-dmarc-psd is fully
> satisfied by merely doing a version of the 3A update to DMARC, directing
> the client to query the immediate parent of the organizational domain,
> if the OD has been queried and no DMARC record has been found.
> That is, making DMARC have a 3-level lookup sequence rather than two,
> where the additional one is the same as for the organizational domain,
> except one level higher.
> Thoughts?

I think your analysis is essentially correct, but I think point 1 is 
backwards.  Since (in the current draft), based on the registry entries, the 
third level queries will usually not take place. It's not that the PSOs are 
constrained not to publish records (they aren't), it's that no one will 
(should) query for them based on the third level test if they aren't in the 

This may seem like a small thing, but I believe it makes all the difference.  
You are certainly correct that nothing in an RFC can prevent a PSO from 
publishing such records.  What we can do is give guidance on when not to look 
at them.

I believe avoiding the privacy implications of the related feedback are worth 
the transactional costs of the registry (but then I would, wouldn't I).  I 
don't think a bad situation justifies making it worse.

Scott K