Re: [dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-04

Scott Kitterman <> Fri, 26 July 2019 20:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89DA6120071 for <>; Fri, 26 Jul 2019 13:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=PvQ+2q3t; dkim=pass (2048-bit key) header.b=XfgCtsVb
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7zlcE0uPW5wz for <>; Fri, 26 Jul 2019 13:27:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75A18120047 for <>; Fri, 26 Jul 2019 13:27:37 -0700 (PDT)
Received: from ( [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by (Postfix) with ESMTPS id 5B83DF80758 for <>; Fri, 26 Jul 2019 16:27:36 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201903e; t=1564172856; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=5STRWSK1maI/fIBdLmyKEnLHPvL60JVuysly+zx1acM=; b=PvQ+2q3t7C6FCFVmuWOUFpYkoPNTOITVCV0J4D2PkpI6KtwzTrUu/mcm IgjJng9jSzmVPMT0x/TEHyvwWKI4Bw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201903r; t=1564172856; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=5STRWSK1maI/fIBdLmyKEnLHPvL60JVuysly+zx1acM=; b=XfgCtsVbVs1jj5ircyjv8+XHE8Umgs7Aut7ouNMeyGnvk7OayFqcm0Yk RZsFp6Q3MsFKuydIOTcTze18LveA8fRCgZD+DET37HrAi5H+WPE+jACckY 7AZcmGAsIdZcT2HzjukOhXSyKswRoWs5Vp3Txvw0q46YlcNGuGMh5boK0N tiiURG5OeTw2D2xgdjjGY7pKtpPWR151KmtPJygHmE3rjwDrJsvZ6w0yj4 tb0Q8il5ZfU/5uyhIrB+1AmZ5fDJl10g/2yVvLX+NZbg5mYIVoTY+I8Z69 BpzJ9XinqYTyk41n85k8y2g5XbX0hqml32k1XaW6c96wfxhA6MxHCw==
Received: from l5580.localnet ( []) by (Postfix) with ESMTPSA id 29279F80096 for <>; Fri, 26 Jul 2019 16:27:36 -0400 (EDT)
From: Scott Kitterman <>
Date: Fri, 26 Jul 2019 16:27:35 -0400
Message-ID: <2236077.6bFe0TRX2e@l5580>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <>
Subject: Re: [dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-04
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, 26 Jul 2019 20:27:40 -0000

On Friday, July 12, 2019 6:35:31 PM EDT Kurt Andersen (b) wrote:
> Please note that I did not review Tim's comments in detail so some of the
> following points may have been covered by him previously.
> *Page 2 contains the following paragraph:*
>    This memo provides a simple extension to DMARC [RFC7489
> <>] to allow
>    operators of Public Suffix Domains (PSDs) to express policy for
>    groups of subdomains, extends the DMARC [RFC7489
> <>] policy query
>    functionality to detect and process such a policy, describes receiver
>    feedback for such policies, and provides controls to mitigate
>    potential privacy considerations associated with this extension.
> This extension does not really allow PSDs to express policy for
> "groups of subdomains" unless you take the perspective that "all or
> none" are groups. Perhaps altering the language to say " express
> policy that would apply to subdomains..."?

I think the changes I just pushed in response to Tim's comments address this.

> *The very end of section 1 says:*
>    DMARC [RFC7489 <>], by design,
> does not support usage by PSOs.  For PSDs
>    that require use of DMARC [RFC7489
> <>], an extension of DMARC
> reporting
>    and enforcement capability is needed for PSO to effectively manage
>    and monitor implementation of PSD requirements.
> I still fail to see how this proposal is necessary (or, potentially
> even useful) for the PSO to perform enforcement of their policies. I'd
> recommend either deleting the entire paragraph or refocusing the
> second sentence around the brand protective role that this proposal
> brings for abuse of non-existent subdomains below the PSD.

Agreed.  Deleted.

> *Section 2.2* "PSD DMARC includes all public domains..." --> suggest
> "PSD DMARC applies to all public domains..."


> *Section 2.6* "...that a receiver is willing to accept" seems like it
> opens up a wide area if one applies considerations like
> DNSSEC/DANE/MTA-STS/etc. There is a separate conversation on this
> topic so I'll defer to that thread.

This went away due to that discussion.

> *Section 3* should include the new "np" keyword as an update to the DMARC
> spec.

Added based on the no existent domain sub-thread.

> *Section 3.5* This call-out makes it seem like information about
> non-existent domains is not desirable and useful for org-level DMARC.
> Can we modify the language to remove that implication? Perhaps "
> desirable and useful, just as it is for org-level DMARC operators."


> *Section 4* Neglects the privacy implications of broken "receiver is
> willing to accept" conditions that may lead to additional leakage.
> Also in the third bullet point, "it's feedback" should not have an
> apostrophe.

OBE, related text is removed.  Typo got fixed somewhere along the way.


Scott K