Re: [dmarc-ietf] PSD simplification

Dave Crocker <> Wed, 12 December 2018 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DAA7130E4F for <>; Wed, 12 Dec 2018 09:38:20 -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 snmiK1N65LzD for <>; Wed, 12 Dec 2018 09:38:18 -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 B59D912DDA3 for <>; Wed, 12 Dec 2018 09:38:17 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id wBCHd9Gu008440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Dec 2018 09:39:10 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1544636350; bh=6fxFLtdGaPPyq6MGHQrgvjlT8jrEax/SaSKvxVGSe1g=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From; b=lRcKQTAKqzlDz/i3O8BFk8RG7XUmjeoUlPAYkqjUsvZLXEmSbf5rHYnHFXe4ddrCv hUfjMckN2EYDnMzrcujyav/VpDRRQgudfWSSku7bUY4rH9PGjdw075zqDhW4TAwnTe kHePHZZUYZm++QpjH18FrTs9Wm711wLN1mgdd12Q=
To: John Levine <>,
References: <20181212165914.36A76200B6363D@ary.qy>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Wed, 12 Dec 2018 09:38:10 -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: <20181212165914.36A76200B6363D@ary.qy>
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 17:38:20 -0000

On 12/12/2018 8:59 AM, John Levine wrote:
> In article <> you write:
>> 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.
> Given that anything we do to handle public suffix defaults will need
> some code changes, this seems about the simplest change that would do
> the trick.
> I am aware of two security or privacy issues that might come up.  If
> we used a DNS scheme like my DBOUND one, whoever runs the DNS policy
> server can see all the queries and will have some idea of the mail
> traffic from various names.  This approach doesn't have that problem.

1. Doesn't the query to the registry suffer the same risk?

2. I'm not sure what a "DNS policy server" is.  I'm guessing it's meant 
as a DNS server that contains the dbound-ish records?

3. Given queries for MX record, don't we already have massive exposure 
of this privacy-related info in DNS activity?  How would this be so much 
more (and/or worse)?

 > The DNS operator can tell that someone is asking about a subdomain,
 > but not which subdomain.

Sorry but I don't understand this.  A bout of densitude has enveloped 
me.  Please explain, pedantically.

> The other is that the DMARC record might have rua= and ruf= and get
> detailed reports about subdomains.  This is not an unreasonable concern --
> I am the legacy registrar for various <geographic> domains and
> my DMARC reports tell me a lot about one of my registrants who sends
> a lot of mail.  (Real mail, they're the county govermnent.)  This is
> easily addressed by clients ignoring the report advice in the OD
> parent record.

What does it mean for a /client/ to ignore the advice in the OD parent 
record?  I thought that record was for servers.

I'm now guessing that your note is primarily (or completely) about the 
basic, potential dangers of having a default DMARC record in a public 
registry, rather than being about the refinements to the PSD spec I've 

> One issue that is not our problem but might be Scott's is that in
> ICANN contracted TLDs, they're not allowed to publish TXT records at
> _dmarc.BANK or _dmarc.INSURANCE unless they apply to get special
> permission to do so.  I happen to know the people who evaluate the
> applications (as do many other people here) and I'm sure they would
> say yes for those two TLDs, but it would involve some time and money.
> This might actually be a feature, since a similar appplication for
> _dmarc.XYZ or _dmarc.SUCKS would be treated with a lot more
> scepticism.

This invites an exercise at writing a policy directive to characterize 
the types of TLDs that are good candidates for saying yes and those that 
are good candidates for saying no.  The most useful part of such a 
document would be charactizing 'types' of registries...

Dave Crocker
Brandenburg InternetWorking