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

Scott Kitterman <> Tue, 05 February 2019 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0522130EF1 for <>; Tue, 5 Feb 2019 12:18:41 -0800 (PST)
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=b0ryou6Q; dkim=pass (2048-bit key) header.b=d10snEWY
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AiAMpaZuAsQU for <>; Tue, 5 Feb 2019 12:18:39 -0800 (PST)
Received: from ( [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84503130EED for <>; Tue, 5 Feb 2019 12:18:39 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201812e; t=1549397915; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ejU/IbxveFih2NI868AB/XSdpyE+nk44B/Wldeg+O5M=; b=b0ryou6Q7BIluid+hYtT/E+wezdltNM5EWxrov1wx2yGHLEWUdcU78Vu GsYrURKKYwOYGVcS2RlSx8oEdeCIBw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201812r; t=1549397915; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ejU/IbxveFih2NI868AB/XSdpyE+nk44B/Wldeg+O5M=; b=d10snEWYhRv77HT8Uep721GiLr8sQxr0HhW6lTVOL69sZWRcyAOxGj69 5QOydrZ3hnQSRL7WgqhjnFJpwy18KCgd1NSGQhQv7hAXXxMCbtZjmyPnSe V/oY7hPaUjarzf+hFkX7q5w9LtNDIWx51sx9iCHetstImTYEwxCBm/ubAh 2MQePFfQ3TJF2cRK0E5w22OpuOeTC5U2FgtS8VUxYGrm71BDV4nc6pFJt9 JKSkReD1fOI+Sg/pGR1vE1+1yi2c93DNuSNxMYvcQVUYJcTRHm9KzAGW7p I5S/ICDzeOl7BCYkXfj0a8puu3wYSZIwmo2gb85tA/fnRiMn5yJFYA==
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 AC4312D40033 for <>; Tue, 5 Feb 2019 14:18:35 -0600 (CST)
From: Scott Kitterman <>
Date: Tue, 05 Feb 2019 15:18:35 -0500
Message-ID: <6596039.Rh8MxG5e5K@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <11058591.22vd1BysGP@kitterma-e6430>
References: <20190117185019.16153200CDA113@ary.qy> <11058591.22vd1BysGP@kitterma-e6430>
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: Tue, 05 Feb 2019 20:18:42 -0000

On Friday, January 18, 2019 04:14:42 AM Scott Kitterman wrote:
> On Thursday, January 17, 2019 01:50:18 PM John Levine wrote:
> > In article <3104294.rU99Ex2XNH@kitterma-e6430> you write:
> > >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
> > >receivers.
> > >
> > >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.
> > 
> > That all seems reasonable but it still feels like a lot of mechanism for
> > marginial benefit, particularly since we have no clue who's going to run
> > it
> > if we can't foist it off on Mozilla.
> > 
> > I wonder if there's any way to get the PSL to tag vanity TLDs.
> There are two parts to the PSL; a section called "ICANN DOMAINS" and another
> called "PRIVATE DOMAINS".  All the TLDs (single user or not) are in the
> ICANN DOMAINS section.
> I don't know if it would be enough to have them also listed in PRIVATE
> DOMAINS.  I don't expect they would want to remove them from ICANN DOMAINS,
> since that's not wrong, it just doesn't fit out use case.
> It would require some adjustments to the current DMARC algorithm for
> organizational domain identification.
> The current process is to take the 2822.From domain and (assuming there is
> no DMARC record for that domain) look-up in the PSL and reduce the
> 2822.From domain to the PSL ICANN DOMAIN + one level.  If that level has no
> DMARC record, then the domain does not participate in DMARC.
> If Mozilla would add these single user TLDs to the PRIVATE DOMAINS section
> also, we could adjust this slightly and for this use case (which is only one
> of three in the draft) it would work:
> After checking PSL ICANN DOMAIN + one level, if there is no DMARC record,
> then check the PSL PRIVATE DOMAIN list and if the domain is listed there,
> check for a DMARC record.
> I don't know that this would violate the sematics of the PSL and they are,
> in fact, both ICANN domains and private.  Based on the description at
> it seems like it might be accepted.
> Regardless of exactly how we do this for PSD DMARC, it is probably work
> documenting that for DMARC (the regular kind), only the ICANN domain section
> of the PSL is used.
> Does anyone know someone at Mozilla to ask?
> For the other, non-single user domains, maybe the best we can do is an
> appendix that describes the characteristics of PSDs for which PSD DMARC
> checks are suitable and lists our three from the initial registry as
> examples. Otherwise, I think we need a new list somewhere because those
> (like .bank) are clearly not private.  If IANA is not the right place to
> host a list, does anyone have any other suggestions for the ones that won't
> work on the PSL?

After some off-list discussion with someone who knew someone who knew about 
PSL, it seems PSL probably isn't the right choice for this (meh).

The current PSL is over 12K lines long.  What we're talking about here is 
probably .1% to 1% that size.  Leaving aside for a moment the mechanism, would 
people review the latest draft and see if they think the privacy issues are 
adequately described and if they require some kind of mitigation?

Scott K