Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Scott Kitterman <> Thu, 05 September 2019 21:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06B16120130 for <>; Thu, 5 Sep 2019 14:49:46 -0700 (PDT)
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=8Kn4Vb2M; dkim=pass (2048-bit key) header.b=BSaZ2/6r
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O9QFwtC1N5ai for <>; Thu, 5 Sep 2019 14:49:44 -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 1ECC21200D5 for <>; Thu, 5 Sep 2019 14:49:44 -0700 (PDT)
Received: from ( [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by (Postfix) with ESMTPS id 01E58F8066A; Thu, 5 Sep 2019 17:49:13 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201903e; t=1567720152; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=WaEL4LtJAojj884v8mOTpqjsjWrWekrDxSb2HcFou7k=; b=8Kn4Vb2McvCDSyD1u7hybSfSDYq3BD8SibczsoewtXClZ8gZs7oqxNZv oIpNWVZ2I3z3JXH3oC3Mv9qbU1S5Bw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201903r; t=1567720152; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=WaEL4LtJAojj884v8mOTpqjsjWrWekrDxSb2HcFou7k=; b=BSaZ2/6rw6bSf06nD3wN8L6DNNAkC5Vp+CksmcKRnghANjU9YDoGXq77 4TfjD7MIQ6MBi6sWkiUWKcy2wFnc8eqhjAmdXIAFCFaKNCnOyqd9Zo46r5 gB5SGZ4pPrMJo6d5eUCEOKhPn8Ru0OY3z56oNuAlys1XOxzKLs+a3r3GTY DlYvRYJ1PWRvLnJkXXxV0dYjsrtpOSPJ7GUj0oNM/JlBncjIxAxBSeMKZW p3zfoAe9xO79FZfsHYGw+BUf6QR5Fvq4SdV5odyKKPG3N1eSkGLHpVNeVB IMxf2C78VRyXaqvLOrY0SWOQeN2NPXH3Z5SulU+hXf8b2MmMdodD8w==
Received: from [] ( []) by (Postfix) with ESMTPSA id 683CCF80284; Thu, 5 Sep 2019 17:49:12 -0400 (EDT)
Date: Thu, 05 Sep 2019 21:49:09 +0000
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Scott Kitterman <>
Message-ID: <>
Archived-At: <>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
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: Thu, 05 Sep 2019 21:49:46 -0000

On September 5, 2019 8:22:27 PM UTC, Dave Crocker <> wrote:
>On 9/4/2019 6:28 AM, Dave Crocker wrote:
>> ence my current view that:
>> 1. The change to DMARC should be limited to permitting the query for
>> organization domain to be anywhere in the DNS tree, including a TLD. 
>> Within DMARC this would not look like 'extra' mechanism.
>> 2. The mechanism that processes that query should be cast strictly as
>> PSL enhancement, independent of DMARC.
>Trying to refine things further:
>    DMARC does not care about the PSL.
>    What DMARC cares about is the Organizational Domain (OD), as a 
>fallback when no DMARC record is found at the desired domain name.
>    That is, PSL is literally outside the scope of DMARC.
>    At the least, therefore, the DMARC specification should define a 
>distinct interface to the outside functionality that tells DMARC where 
>the OD is, which will return what suffix of the full domain name is the
>OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix
>    The PSL-related side of that interface should be a separate 
>specification, so that changes to its behavior -- such as has been 
>happening with the introduction of ODs that are TLDs or are otherwise 
>'above' where DMARC has been guessing the OD to be -- are isolated from
>    The current problems are that DMARC has embedded too much detail 
>about the PSL world, yet DMARC has no involvement in that world. The 
>current proposal embeds assumptions of PSL knowledge further, rather 
>than separating PSL knowledge out.

I don't think so.  The draft defines PSD as org - 1.  However you figure out org (currently PSL, but whatever).  If there's some place in the draft that doesn't say that, it's a mistake to fix.

I'm currently writing on my phone, so draft review isn't easy.  I'll look at it again later today and report back on details.  If you have specific suggestions on making this clearer, please let me know.

Scott K