Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

Todd Herr <> Tue, 24 November 2020 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4EA33A0D8C for <>; Tue, 24 Nov 2020 07:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6UNmxzACSmnc for <>; Tue, 24 Nov 2020 07:28:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDC2E3A0D86 for <>; Tue, 24 Nov 2020 07:28:57 -0800 (PST)
Received: by with SMTP id g19so10788619qvy.2 for <>; Tue, 24 Nov 2020 07:28:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0+T03RTK7Ilo2WH0LmrZLfF50dTQ9UtnoawOZkoOW/I=; b=MMJs+k4FN/GiDJZLUip6f0PF7lOKv4iIV+MwrT86NNhYXsAVv59QHIaDw04+t+jgZW mKoXsfzKsUbpPCarzl9pdBFTJeFRTQAfWcyz0LJLSEnoK1J+tYxEavh8dsfeiL2u/fkT cBSp2F3Hoc7GmrX1Kv3da2zmiIB0e+CKpwHmt0rsmaTXSsJEa3W4FDOLf495enUbQjFE sUTxHlzYhpZwJiimbdcmGZSUsKbf0zmf1Q43/88C4uc3cTZaR2B8Wm+SHc155anoaSML mvgZunxpfQ8k5oiVhISeASsdK/9Y0aVt7NFR/wMDBB2KnVCOvLMlIT6zCmISO3CiUZ6i QaaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0+T03RTK7Ilo2WH0LmrZLfF50dTQ9UtnoawOZkoOW/I=; b=hG9/RFJdkJmgZb07SXAz2d++0tN2BgKDc6Go4xCeyh/lImfJXy5wtzavJfxVEXHF+9 d3xaKuZf0Zv3dBTKM/WKvTjdAJNPlyzfTmfnMP/NnlWP9GRdlfIKoCAEo+hLqbDUp4EG wkpVeOYX9VE+HrKot1oxlmmqrTGBGmYOf2WiOODANejTV7xqxGS13uidj/99wYGYn3dc mIetHGgghtPC6cw48oon3+v8rwHlTHkO1W0mgnpsqZkQThDfj/1YjU9Na8FUPEEUTFSh gXRvU/FXVCVmxbp++2L91qaZRGzmfaP1lwMJj+0rbt4Yj0ACKg/nEMPdakGMaDT1ny+o gYkg==
X-Gm-Message-State: AOAM530g3ot0SoZzz7znQPhY6e3OCChdlsXI6W1X6oGf+iD/2nHPoTqe r2sb3y70OjVykJt4SGwUVzr+ENSCymMdahODTs9oqQBxosLGzg==
X-Google-Smtp-Source: ABdhPJwQS90JAmZebvMJLbMBi9EJsFH10R5zbl58r9F0RLfjZHn383mN4FHTqDzwBZDbWHfswf2l/MGqDwSoAHKkKMs=
X-Received: by 2002:a0c:db11:: with SMTP id d17mr5239354qvk.39.1606231736452; Tue, 24 Nov 2020 07:28:56 -0800 (PST)
MIME-Version: 1.0
References: <20201123213846.EB14127C8160@ary.qy> <> <> <>
In-Reply-To: <>
From: Todd Herr <>
Date: Tue, 24 Nov 2020 10:28:40 -0500
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000014268e05b4dbf854"
Archived-At: <>
Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup
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, 24 Nov 2020 15:29:00 -0000

On Tue, Nov 24, 2020 at 10:15 AM Dave Crocker <> wrote:

> On 11/24/2020 7:00 AM, Joseph Brennan wrote:
> > I will ask why the recipient system should look up anything but the
> > dmarc record for the specific domain in the Header From.
> Hmmm.  Unless I've missed it, the DMARC spec does not explain the reason
> for needing the Organizational Domain.
There are two reasons (at least) for needing the Organizational Domain, and
they are discussed in RFC 7489:

   1. DMARC also allows for the explicit or implicit expression of policy
   for sub-domains at the Organizational Domain level. This matters for those
   times when _dmarc.RFC5322.From.domain is non-existent and
   RFC5322.From.domain is a sub-domain of the Organizational Domain.
   2. The default mode for authenticated identifier alignment, relaxed,
   requires only that the Organizational Domains for both identifiers are the
   same, and so the Organizational Domain must be known in order for relaxed
   alignment to be ascertained.

What is perhaps missing from RFC 7489 is the reason that the authors chose
to make these two items part of the specification.


*Todd Herr* | Sr. Technical Program Manager
*p:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.