Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

"Murray S. Kucherawy" <> Mon, 11 November 2019 07:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3FB91201DE for <>; Sun, 10 Nov 2019 23:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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] 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 PXe1ykh5Rts8 for <>; Sun, 10 Nov 2019 23:34:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84DB8120154 for <>; Sun, 10 Nov 2019 23:34:51 -0800 (PST)
Received: by with SMTP id a143so8087848vsd.9 for <>; Sun, 10 Nov 2019 23:34:51 -0800 (PST)
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=sh2XMOldISsmZS4KFUSmGx1NQJq63WsFvywILYzo46k=; b=kwKFooy6cPZ6yywr/XOe0ckXwr8l6nNGOyOBWu7pogp3XVGHOMYRtIwI8mvX+GVg5I pbbUTQiHPqeHHeJ5C+y4hDg7LwNO+b4swYaHxCKtHb4Zt7UVjGpwkqLLu358GVTqhdLi o2avlNh1uiUzgrFFGkItiacskgmgHIboXeRbfhjlIzQWUrB0eV9xcusRAoiNWnPO0kL5 pFv1oSxcXftfFvNp56ForfH2YZ9ALAD1gzzhOjt+ujxZcrVb+EIaPjwHAOrpL/lr1jbu +LlAVvJ2qK5gPPY1+M2VE9odNY6AXafhVKKwLm86aKK8jFpTQnCVXNrd59uM+yCrVmXg 2c0Q==
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=sh2XMOldISsmZS4KFUSmGx1NQJq63WsFvywILYzo46k=; b=fPk8hMbgJu3stGrp56A1ndR6caIxUnYrs7fMJfQwnAM5lUHavdjy7tXI6M+87bOHkm J5/411KzYlEdtpZdkL8WXN5ZELAPLO4YveJflQ1LrmjGQ5CJjnt92WDVK8cOccHgLjPm j/kL8+2LTzf5gcuyOQ/YIVzHXHQtHxAUT+f5+GQtzU71/NnmHK8PKT3WCjFsStOo3VfU HzkikJi0vqjOGrmMN5bmjICdyDMruxTQmkuGICGU3tNBzhq7AtVKQwvrTwSNvUC1n9WN YUqeWk1J/NJGfwn3eTUXhK0PMWhrXZfhFOLnlpaHO0jqhhSIY+tZEC87byRU659CEr2B kUjA==
X-Gm-Message-State: APjAAAUI0VSAw5lKr8YPpLsbKBCbI0V1JtVCOBGOJVdKdOgERg11QWgl 5Ob8GaVUlSmfTyVO+xoz0ZZjYO1/jU/x2lbaz50=
X-Google-Smtp-Source: APXvYqx7zkE9BP4TpIE5c4yl+207mqUvcIikx95vg64gq4GQIGf2kcrkU0wFZ1kLk6MspboaqrsklJ7iSRJzErUMzZs=
X-Received: by 2002:a67:d198:: with SMTP id w24mr19103214vsi.13.1573457690422; Sun, 10 Nov 2019 23:34:50 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Sun, 10 Nov 2019 23:34:39 -0800
Message-ID: <>
To: Dave Crocker <>
Content-Type: multipart/alternative; boundary="000000000000b4f16005970d2af2"
Archived-At: <>
Subject: Re: [dmarc-ietf] Comment on 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: Mon, 11 Nov 2019 07:34:54 -0000

On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker <> wrote:

> > 1. The change to DMARC should be limited to permitting the query for the
> > organization domain to be anywhere in the DNS tree, including a TLD.
> > Within DMARC this would not look like 'extra' mechanism.
> >
> > 2. The mechanism that processes that query should be cast strictly as a
> > PSL enhancement, independent of DMARC.
> Trying to refine things further:
>     DMARC does not care about the PSL.
>     What DMARC cares about is the Organizational Domain (OD), as a
> fallback when no DMARC record is found at the desired domain name.
>     That is, PSL is literally outside the scope of DMARC.
>     At the least, therefore, the DMARC specification should define a
> distinct interface to the outside functionality that tells DMARC where
> the OD is, which will return what suffix of the full domain name is the
> OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix
>     The PSL-related side of that interface should be a separate
> specification, so that changes to its behavior -- such as has been
> happening with the introduction of ODs that are TLDs or are otherwise
> 'above' where DMARC has been guessing the OD to be -- are isolated from
>     The current problems are that DMARC has embedded too much detail
> about the PSL world, yet DMARC has no involvement in that world. The
> current proposal embeds assumptions of PSL knowledge further, rather
> than separating PSL knowledge out.

We (the chairs) fully agree with all of this.  What we -- I in particular
-- have been struggling with is to find a path forward so the PSD
experiment can still take place without being blocked by the need to first
go back and overhaul RFC 7489 as you've described here, separating DMARC
and the OD determination.  Because that'll take months.

We are perhaps in the fortuitous position in our charter now that our very
next work item is to take up the task of reopening DMARC itself, and the
separation of function Dave is espousing could be made into a reality
during that work.  Given this, we suggest that the PSD draft be allowed to
proceed as Experimental, but with appropriate preamble text added to its
Introduction explaining the deficiency Dave has identified.  So the order
of operations becomes:

* add text to the PSD draft making it clear that what it's describing is an
experiment whose outcome will be taken only as feedback to the revision of
the standard (i.e., this is not intended to be the final form of anything),
and it is not intended to be deployed outside of the experiment's
* publish the experiment with those cautions and allow the experiment to
* while the experiment is running, spin up the work on two new standards
track documents, in line with our charter:
  a) DMARC, with PSL references replaced by the abstract notion of the OD
that's determined in some non-specific way, as Dave suggests
  b) a PSL document that satisfies the abstract notion of OD in the DMARC
document, also as Dave suggests
* when the experiment completes, either augment (b) if it's still in
development, or publish a revision to it, based on what the experiment has

Can this be made to work?

Honestly, the experiment could start anyway without an RFC published, but a
formal record of the experiment and its caveats doesn't strike me as a
wrong thing to do.