Re: [dmarc-ietf] PSD simplification

Scott Kitterman <> Thu, 13 December 2018 01:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19722129BBF for <>; Wed, 12 Dec 2018 17:27:14 -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=CmYUmpjs; dkim=pass (2048-bit key) header.b=yn7B9JG+
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OImprTzK9C7l for <>; Wed, 12 Dec 2018 17:27:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD5F9128B14 for <>; Wed, 12 Dec 2018 17:27:11 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201812e; t=1544664429; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=Ad81SD0Vvwv6EbglQBn4evn8ZY11/aCqVY1+irfGhmo=; b=CmYUmpjso0Ca0mDdgwSYrj5q9WR0uRIGjdGwGEEiHYbDwYeHAIUKHvDi Erbd+CBX+KfPj+CGJTEy1viN6zuhCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201812r; t=1544664429; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=Ad81SD0Vvwv6EbglQBn4evn8ZY11/aCqVY1+irfGhmo=; b=yn7B9JG+Yzn+RezOD4C+LX9Lq5mcu5ZqxJ0RC3iWSNf5cFfeMSqfGeDI iuvqeDo6Muho5qlfYJeuClvPBBQs3ity/2QwnEXhQ1K+8BCKXUNwZ8MMZ2 HfRYFJRfrEngSzr5xOFCKR2CpT4t97JQL4lWfy7UzU1SfEZGhAn7FD6bfx yjfegEi+eg9eYP/MHRn+uisjXcBJ36xCnK6mvRwKmpSHldUrEjebvw980k KiowJEsoY9STg5thXexKSnymKUoECHlRm+s5GrWUkH7WVoJo7IrVnTiUnR phFKVr6CiSlddCFHal2FztbheIqHZCYMM5rTvoTrdzm6z7g1lRQkrA==
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id EE1992D4062B; Wed, 12 Dec 2018 19:27:08 -0600 (CST)
Date: Thu, 13 Dec 2018 01:27:03 +0000
In-Reply-To: <>
References: <> <> <> <8090288.RMFQGzStmc@kitterma-e6430> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Scott Kitterman <>
Message-ID: <>
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: Thu, 13 Dec 2018 01:27:14 -0000

On December 12, 2018 3:30:20 PM UTC, Dave Crocker <> wrote:
>On 12/11/2018 9:01 PM, Scott Kitterman wrote:
>> On Tuesday, December 11, 2018 08:17:38 PM Dave Crocker wrote:
>>> 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.)
>> 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 registry.
>> This may seem like a small thing, but I believe it makes all the
>> You are certainly correct that nothing in an RFC can prevent a PSO
>> publishing such records.  What we can do is give guidance on when not
>to look 
>> at them.
>That's a cost-saving line of concern.  My point is that the existing
>mechanism already has quite a bit operational inefficiency from queries
>that fail, so that adding one more is a minor issue, especially as
>against the considerable administrative and operational cost of
>and running a registry.
>> 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.
>Sorry but I don't know what privacy implications you are referring to.
>I don't even have a guess.
>And the draft makes no reference to privacy issues.  Or rather, the 
>Privacy Considerations section says the draft doesn't introduce any.

As written, it doesn't.  If you change it the way you propose, it will.

Scott K