Re: [dmarc-ietf] PSD simplification

Dave Crocker <> Wed, 12 December 2018 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AB82130934 for <>; Wed, 12 Dec 2018 07:30:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OnYGjgOQK4eU for <>; Wed, 12 Dec 2018 07:30:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E3164130DC9 for <>; Wed, 12 Dec 2018 07:30:27 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id wBCFVKEq031843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Dec 2018 07:31:20 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1544628680; bh=+iQAAxPnBx5HV/ryGEZWGWdiO1LNI1vfZ06wB4Rmu8c=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From; b=PAYzLLQPQwexQaSThFQjBzdfFL0/J8hCDW7JHMkNwAZY8vvPaWX+sKDQUe5cVPZht 2V3BCmOkXPigwbJ0L7FM9QzGWFkCUsArsCKXngJsKghjYqoYbqFGADa+J9oAZtKbid eb8CfvV6lTOJ1CjxLDwAkgjMc5grHJFsKNHcRBrg=
To: Scott Kitterman <>,
References: <> <> <> <8090288.RMFQGzStmc@kitterma-e6430>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Wed, 12 Dec 2018 07:30:20 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <8090288.RMFQGzStmc@kitterma-e6430>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 15:30:32 -0000

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 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.

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 creating
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.


Dave Crocker
Brandenburg InternetWorking