Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd

"Murray S. Kucherawy" <> Wed, 26 June 2019 20:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BB5A1203A6 for <>; Wed, 26 Jun 2019 13:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZK4KfJbxdZmY for <>; Wed, 26 Jun 2019 13:49:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAB3612018B for <>; Wed, 26 Jun 2019 13:49:26 -0700 (PDT)
Received: by with SMTP id h10so32149ljg.0 for <>; Wed, 26 Jun 2019 13:49:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qnZDWcAPza+u2ebZRv7b+atRWOEfQ4P3Loei7XCWJls=; b=f3UbqdO6V3qDqsW9YDqeOoHKLegQeh1waNKrEn/6H1WRAWXHuE+soe1HRX9s9tnJ+7 cKm8dngoOdhL3knLgVkZRxSMM8nQNBoMDhDYSXsNTWB5z02oroi7OGGnNd2PY8CFdFXZ eWnbAbxsRfkuGD0cgAL6TOntssSE5RTbHp5Ocw2N6tBWBGhufy9Fl5M3bKdhMHeL4R63 oUokZZYrgGrVroehe2mm/50Ul7FUUecmB4NAM+6ajLrf4juNwDZ92hSEdM9Ty7/hQN6p 47ZPue8n7NjtkNiBLPwfM2zi6DEmhreWhVQyK6Wfjyq0QLKmsaXD+zyQosITykXkXnzq 1IvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qnZDWcAPza+u2ebZRv7b+atRWOEfQ4P3Loei7XCWJls=; b=laLcF+AlFr27sb95C01DBDX4PPYNRpDC+aUETYLnPx0BB8IWIBqfVIftpnfsgvT5Dp thtegI7xlbvkDzptw1rXGpJFDJoH43RanVDoRBBQ8AkkK8VBo350PRDv0tm0To1MPdJb 3YR5D9wbXePxmWm0oA4hIXEmqBQ1uCdNqhx1rGelwLvBVEruj91sScmbcOVo/7r0oMgt lzHhwgUOOfSmXlwqInEL/0MsswPU4iRhRcDpxE5giPqmlQC30bG//Vh39cBL6gxoKcsn 3k5IPF3/eI/vHs4m7NSX1pKsdv1ohgRRiK+6cwft6TIqaf6jawmih1ieCa2uZymXkp5o Zv8g==
X-Gm-Message-State: APjAAAVwP0KVh51EgSLwC1Nwxbx4k8sgm2MCafwwmAgGhvGOQoLzU60A OeCzgfpWCVW5H1FBw2cRU51pZNb69OaKkP5fxjiMC/c4
X-Google-Smtp-Source: APXvYqwL9p+zoVuaAI0VsWNL7KDJLz10choNArrH+uoh706gvXWqrfaIQXTEkX78bIM+097KJpnsNJc3sdYJdIDvfPk=
X-Received: by 2002:a2e:7c14:: with SMTP id x20mr179750ljc.56.1561582164726; Wed, 26 Jun 2019 13:49:24 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <2221039.c73XDibtHi@l5580>
In-Reply-To: <2221039.c73XDibtHi@l5580>
From: "Murray S. Kucherawy" <>
Date: Wed, 26 Jun 2019 13:49:13 -0700
Message-ID: <>
To: Scott Kitterman <>
Content-Type: multipart/alternative; boundary="000000000000375843058c402e12"
Archived-At: <>
Subject: Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd
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, 26 Jun 2019 20:49:30 -0000

On Mon, Jun 10, 2019 at 3:31 PM Scott Kitterman <>;

> > >On Thursday, June 6, 2019 at 1:12 PM EDT Scott Hollenbeck wrote:
> > >I recently had a chance to read through draft-ietf-dmarc-psd. If I
> > >understand it correctly (and I'm not sure that I do), the document
> > >suggests that it's possible for a TLD like ".com" >to be a PSD and a TXT
> > >record like "<>" can be published in the com
> > >zone. I found this part of the draft confusing because it's not possible
> > >to add TXT records like that >to the com zone. It might help to
> explicitly
> > >note somewhere (perhaps in Section 2.2) that there may be policy
> > >restrictions in place that disallow the publication of DMARC policy
> > >>records in some DNS zones, including some top-level domain zones.

As I understand it, we're in an interesting position here: ".com" can't
have a TXT record in that zone due to ICANN policy, and this ICANN policy
won't change without a (published or imminent) RFC that suggests allowing
such records would be of benefit to the community.  So the publication of
this even at experimental might obviate the need for such text in the

Given your concern, I think we're talking about adding text that says
"There may be operational constraints that prevent any given operator's
participation in this experiment."  But isn't that an implicit caveat of
all experiments?

On the other hand, perhaps the largest benefit would be from the restricted
TLD operators if they were allowed to do so.

> Right now, PSD DMARC cannot be deployed
> > ubiquitously. That reality should not be overlooked.

This part I agree with; by pointing out that this cannot be widely deployed
right away, we are highlighting that the results of the experiment could be
understated due to the restrictions Scott H. has identified.

I see your point, but I think it's probably out of scope.  This is an IETF
> document and such restrictions are outside the IETF's control.  Also, keep
> in
> mind that once an RFC is published, it is immutable.  If that guidance
> changes, then there would be no way to correct the document without
> spinning
> up a whole new RFC process.

I think it might be beneficial to point out somewhere in the document that
today's operational reality prevents this experiment from being deployed
globally.  However, if the experiment shows that PSD solves a real problem
at a large scale, it would be fodder for appropriate policy changes outside
of the IETF that would permit its ubiquitous deployment.

> Is there a public, stable reference that describes the restrictions?  If
> so,
> it might make sense to reference it.  If we can, I think that would be
> much
> better than 'hard coding' the current external policy in an RFC.

I concur.  Does anyone know of such a policy statement from ICANN?  I don't
recall it being present in, say, any of the DNS RFCs, but there are so many
of those now...