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

Scott Kitterman <> Fri, 18 January 2019 09:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12F6713117E for <>; Fri, 18 Jan 2019 01:14:49 -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=zDL5dnM2; dkim=pass (2048-bit key) header.b=boY3ALSm
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hfLMPQ8bkcoO for <>; Fri, 18 Jan 2019 01:14:46 -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 AEF76131178 for <>; Fri, 18 Jan 2019 01:14:46 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201812e; t=1547802883; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=onxHPlvaxZvG/AaR/UKKw/Owsp51gKNGLEltZ8LkAAQ=; b=zDL5dnM2On5vrHpipCJ53iJEEE4xSHeyFST0BXBnSukVniiuiWwemIjv oQM960kbhGSQla7vqx1Yi7/mhcxGAA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201812r; t=1547802883; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=onxHPlvaxZvG/AaR/UKKw/Owsp51gKNGLEltZ8LkAAQ=; b=boY3ALSmBHId4qDwLGm3AkL+Xnv6iZ8AYHVxasVWI1Q4AbgCiaWHjzyB WgqyLbNoO35jBZkC35TTWG4ZdPB9jAfEVTCLzWp51wZoE2GU4G/DRPwMO7 CRlEDK95JQLu+ROQtIk0+lYNo3WAeGFs1rvAGXfUZvmkKNR7pBiM8TR/8P z/cAPHP6+58sFpsBqW3+uJSk/PlZY1ixHt52WFywXlp5hZZXnfUXmZp4qH 8emVD+zjsAB+ndGEDhW5gD5ejMGB7QZ1aDPsRUhvVyhgORNdjxhwL7sVvW iymsEgvrTVdAeY0jYRdaVfYynoZbemkXnC10midDFvY82n/a59RC8w==
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 421622D4081D for <>; Fri, 18 Jan 2019 03:14:43 -0600 (CST)
From: Scott Kitterman <>
Date: Fri, 18 Jan 2019 04:14:42 -0500
Message-ID: <11058591.22vd1BysGP@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <20190117185019.16153200CDA113@ary.qy>
References: <20190117185019.16153200CDA113@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: Fri, 18 Jan 2019 09:14:49 -0000

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?

Scott K