Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

"Murray S. Kucherawy" <> Fri, 29 January 2021 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3F423A12A0 for <>; Fri, 29 Jan 2021 12:15:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 yu7hKXOZ6oB3 for <>; Fri, 29 Jan 2021 12:15:14 -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 4B0D13A129F for <>; Fri, 29 Jan 2021 12:15:14 -0800 (PST)
Received: by with SMTP id h11so5516218vsa.10 for <>; Fri, 29 Jan 2021 12:15:14 -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=EeThsgWYvE5P8nwuFUBEC/q82iGUrW4r3rbT6+zfDC0=; b=Ig57c/2SxiPbN1ow6JbrLuyHeL8r1NgmddQFKk9cgQNrg9IpLB0tCq65pqgNtzOYGw vlSEvOCM9zQNbQx2V8+k/QStxn/C5zBdbEBIebbfOzg1dcKPdP+6kueROWqszw7jTZEp s361fDUX5Vh9mcd7SdnggM5k5pv2mcXPDqaZEQ+0TrnE3LVQTrZeYFUewjEcMoAbGWhf PfOFTvC+dIIiZ23nolyVKdDB/PWEuUydWp4PrPeQJeKo3AbH5QmCLCS6hHGrgFn6GRBE 2zJ7eipsHvPNVxZRMVHCvz9mUJA0FzR0MinTxI5XtGyG47RnlFDqQ8tXUNKq1W4fZaL5 v+oA==
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=EeThsgWYvE5P8nwuFUBEC/q82iGUrW4r3rbT6+zfDC0=; b=qhfiy1zOQtnwIekuFtXLWJuc5Xv+S+NwT0r4LfY3UrhDM0Lx0WIPseoQNeEdgiGnOC cEgy7udr5kOAHMYLNUyEbhl7muzjGANMVTQ0BM8PuMllF6S4MfhLgDb09utgLb+dwj09 LtP6GPnaQ9BPwAzCuWV5w0l/l/mMaqNSLN3IEGptvS+IpQwiK5pLDNUsZ190hGq2eimG GdFTg1o0/0ZDDzDnea68iVOBKMTsgBOj2ds5dx7PqjoIbWFgwTDDP/Cl29+0Liu0KFEB jPqnp9eXwE+Adahtd3YJCFrqnF6ZlO5w7HPw0qVdhvqn+hOOrAvufdwp5Nxsf2rwR8E9 OuvA==
X-Gm-Message-State: AOAM5311W5yWUqT3Daguy30c1hf7hLO8nCmEFzmjG4Jkr96ETUr81+wy oz6FXF5kHj35qpk8nNdYJ5TH43Enku6XOXuOgBbqRjqqrP4=
X-Google-Smtp-Source: ABdhPJzeZHPeMJfv4rYx3fOWsink/AteEvHlkPSoaA7ddQxdqDz/6ySGzAKrIhcW6luPS9bAnsj7783Wo8eILQv2FaA=
X-Received: by 2002:a67:2bc2:: with SMTP id r185mr4299474vsr.15.1611951313210; Fri, 29 Jan 2021 12:15:13 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Fri, 29 Jan 2021 12:15:02 -0800
Message-ID: <>
To: Dave Crocker <>
Cc: Tim Wicinski <>, IETF DMARC WG <>
Content-Type: multipart/alternative; boundary="0000000000006b51d305ba0fa9a5"
Archived-At: <>
Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
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: Fri, 29 Jan 2021 20:15:16 -0000

On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker <> wrote:

> Abstract
>    DMARC (Domain-based Message Authentication, Reporting, and
>    Conformance) is a scalable mechanism by which a mail-originating
>    organization can express domain-level policies and preferences for
>    message validation, disposition, and reporting, that a mail-receiving
>    organization can use to improve mail handling.  The design of DMARC
>    presumes that domain names represent either nodes in the tree below
>    which registrations occur, or nodes where registrations have
> DMARC does not have 'registrations'.

It's referring to domain name registrations, not DMARC registrations.

Also the occur/occured contrast has no obvious meaning to me.  Really, I
> have no idea what's intended by it.
"take place"?
"are made"?
"are done"?

>    occurred; it does not permit a domain name to have both of these
> "both" of what?  registration?

It's describing properties of nodes in the domain name tree.  DMARC's
current design stipulates that every node is either (a) a node below which
registrations can occur, or (b) a node at which a registration has
occurred.  An example of the former is "org", and an example of the latter
is "" and its entire subtree.

   properties simultaneously.  Since its deployment in 2015, use of
>    DMARC has shown a clear need for the ability to express policy for
>    these domains as well.
> Which domains?

The intent is to augment DMARC's ability to describe the domain name tree
such that a node can be both (a) and (b) at the same time, for the purposes
of policy expression.  So those are the nodes (domains) of interest.

>    Domains at which registrations can occur are referred to as Public
>    Suffix Domains (PSDs).  This document describes an extension to DMARC
>    to enable DMARC functionality for PSDs.
> This is the definition of public suffix provided by the PSL folk:
> "A public suffix is a set of DNS names or wildcards concatenated with
> dots. It represents the part of a domain name which is *not* under the
> control of the individual registrant."

That seems to say the same thing to me, though perhaps more crisply.

>    This document also seeks to address implementations that consider a
>    domain on a public Suffix list to be ineligible for DMARC
>    enforcement.
> seeks?
> [...]

Hmm.  Maybe that sentence can be struck entirely.  Is this a problem with
certain implementations only, or with DMARC as specified in 7489?  If the
latter, I think we can drop this because the main paragraph already says