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

Scott Kitterman <> Wed, 16 January 2019 05:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D03131310E2 for <>; Tue, 15 Jan 2019 21:43:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=KRBzCL3g; dkim=pass (2048-bit key) header.b=IZMPLqaR
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4qdqbiRWrVId for <>; Tue, 15 Jan 2019 21:43:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83F951310DB for <>; Tue, 15 Jan 2019 21:43:40 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201812e; t=1547617413; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=fMnraTAS5sRgti3uXBSlxk50xEKxAPlPgRYJx4Jq7GE=; b=KRBzCL3gXpEcC2aooMpE1P8VJrc/adadLjtc2K+626tpX9JSQSfRVSWX ParIVBsy5Yw2RXLX2/Te3wyU166OCg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201812r; t=1547617413; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=fMnraTAS5sRgti3uXBSlxk50xEKxAPlPgRYJx4Jq7GE=; b=IZMPLqaRM4nRE1LBGL5sAQF5epOT8UBsWVr7RiWHrcZggeWLwm/BOTA5 kic7uOONYXBNB7A5ZeUTDRGMVUrObuvusu2CDK/TOEwU4YcjxsE4rUiL8G fTyw/kaHzVnYtyUNDpjNmWB0wmLh4UQb9YcgW2yRyC1jlCns5tEQ8WXRYh xu/XneB+KF+RVANY5/dOWq3PVZ22mXuVAScL9bHvS1H1TqpPG4Uc6RzjJV OTg4Dv4CUXSaCpbBypnCxW4q3a1tEoUpK4Ns//U8J4A7iGeeajPI2M9LzR bibEA67McAtAU5jY1Xq6N5GF4SAVq8o9cPSxbpJ8XrFCQVFTNbgSlg==
Received: from kitterma-e6430.localnet ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 902062D4078E for <>; Tue, 15 Jan 2019 23:43:33 -0600 (CST)
From: Scott Kitterman <>
Date: Wed, 16 Jan 2019 00:43:32 -0500
Message-ID: <3104294.rU99Ex2XNH@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <20190116004918.22F1A200CACCFC@ary.qy>
References: <20190116004918.22F1A200CACCFC@ary.qy>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <>
Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.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: Wed, 16 Jan 2019 05:43:43 -0000

On Tuesday, January 15, 2019 07:49:17 PM John Levine wrote:
> In article <5126347.eOcQ2jtf8Q@kitterma-e6430> you write:
> >This update removes the IANA registry (which is what I think I was supposed
> >to do based on the feedback to date).  I also bulked up the
> >Privacy/Security considerations descriptions since they are no longer
> >mitigated.
> >
> >I'd like feedback on the best path forward.  Essentially this draft
> >replaces the IANA registry with an undefined way to know where PSD DMARC
> >is appropriate.  I think we need something better than that, but I didn't
> >know what.
> The more I look at this, the less I understand what problem it solves.
> If you manage a zone that can publish a PSD policy, you have some kind
> of relationship with the zone members so you should be auditing their
> policies anyway.
> To take a non-random example, I looked at the 2700 names in .BANK.
> There are 122 with no DMARC at all, which PSD might help, but there
> are also 164 with p=none, 29 with p=quarantine, 7 with pct=N where N
> is not 100, 4 with multiple policies, and about 30 where the DMARC
> record is invalid.  Assuming your goal is to get everyone to p=none,
> PSD doesn't impress me as offering significant help.

My understanding is that, since, as you say, PSOs (like .bank) have a pre-
existing relationship with their registrants, they don't need PSD DMARC to 
audit their registrant's policies.  For an entity like that, it offers the 
chance to get feedback on other, presumably non-existent, domains so as to 
better understand abuse patterns within the PSD they manage.  It also gives 
them a mechanism to express a reject policy for those domains, which does not 
currently exist.  This may help improve rejection of cousin domains by 

For single entity PSDs, like for a very large Internet company that is, 
conveniently not named after a large South American rain forest (so they can 
get it registered), it offers other advantages.  In cases like this, the PSD 
operates like an organizational domain except for the fact that in the current 
DMARC instantiation, their record won't work for subdomains.  PSD DMARC would 
enable '.example' to publish a single record for all lower level entries in 
the zone.

Scott K