Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts

Todd Herr <> Thu, 19 November 2020 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A3F53A11DB for <>; Thu, 19 Nov 2020 12:34:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 smcXVPuLY5f3 for <>; Thu, 19 Nov 2020 12:34:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CDF13A11D9 for <>; Thu, 19 Nov 2020 12:34:05 -0800 (PST)
Received: by with SMTP id z24so3432813qto.3 for <>; Thu, 19 Nov 2020 12:34:05 -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=CsL4vARkeCGjabTlhmCeaNMIsj8UutzIa/PXy0m5VwE=; b=LIHqeP3GzHoVLhwW6tkkIy9oQ7F/VACIEGjryKx7QbO59P86NTwDfS5sTBY+5h6vAU sto/YRiVYPiIAzfBbqzb1RUe/Bo4jirH/EakDzqCHTQDuDSd3pkYZTosHKmrt/zDkSl5 GQ5nZYNB/ghqnQCWu7mYuH9+kY0HnMacaD77AqffbgnBc/RriZebK49huulgaU0NtoPj zRxL8hy2w6yhwmNFR2EDhMs9MgOeZO7xFfbfIaqUwhw4SSL4BTfGOdhCEWr7VmdHFvBd Q7nxuiGUupoUeN8YfQAF2Bngh+iiS9XdpNvp9Dud8H2+iAgvyzOQ0pIGYUODnbwt+WRi Poow==
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=CsL4vARkeCGjabTlhmCeaNMIsj8UutzIa/PXy0m5VwE=; b=eUSinH8qfdCAyijxazceECpF8z5eOfuygslWXKLx5SKnleoATLS3M3SEAPW3a7chC0 eSjChwkVLMj+T6A24BIzKKFzmdRK4oMYRbY3ru7lMJ0eejmLd1WJYRbyC2DJcgNObBmZ 9DMpT3y8YQUFyAhbihfHyG5EUjWdBt/W4cR9/Urc59503nBilnfOyPHSVzpu0o14vVEu gSQ53y6eIlnXbHO/hqTMx3ihNoer0yds/AstHo+uNx7aM0PR+WdPCsL2NuMcxt+t1gNc /TntYAoJkNRtMi0ywUQr4abYqwmiqKhFWc0ehhmWW1ybfD04fLBhULLctS+sVpiwGrP0 jWJQ==
X-Gm-Message-State: AOAM530JbE9RdUFoprTk2wheFHAuhw6T91UdoJmZ2NKhsKIua89H9zO2 DqfSKKJF2cbij6Q8mCAkwCY+qu659eMEStWeRdY45ldIDmk=
X-Google-Smtp-Source: ABdhPJyzKUcA01dx4IHpWsKEvA/rGJPNO1Lb2FNbQfoombOK8qjyHZ1cfCZX7jAGnqSPliRdjUVvU9ImgL/S8PpI7ho=
X-Received: by 2002:a05:622a:14e:: with SMTP id v14mr12025887qtw.298.1605818043799; Thu, 19 Nov 2020 12:34:03 -0800 (PST)
MIME-Version: 1.0
References: <20201118204436.5BE81278D997@ary.qy> <> <> <>
In-Reply-To: <>
From: Todd Herr <>
Date: Thu, 19 Nov 2020 15:33:48 -0500
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000013315605b47ba6f4"
Archived-At: <>
Subject: Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts
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, 19 Nov 2020 20:34:07 -0000

On Thu, Nov 19, 2020 at 7:39 AM Alessandro Vesely <> wrote:

> On 18/11/2020 22:33, John R Levine wrote:
> >> On 11/18/2020 12:44 PM, John Levine wrote:
> >>> so I encourage the group to limit the debate to the existing Org/PSL
> >>> kludge and a tree walk.
> >>
> >> "and a tree walk" is not a minor 'and'.  neither conceptually nor
> >> operationally.  assurances to the contrary notwithstanding.
> >
> > I didn't say they were equivalent.  But I do think they are the only
> options
> > that are likely to get much interest from the WG.
> I don't think tree walk is a viable option, as it distorts semantics.
Forgive me, but I don't know what you mean by the phrase "distorts
semantics"; can you please help me understand?

As for the viability of a tree walk, it is possible in complex environments
to have something resembling the following:

   - RFC5322.From domain - - non-existent
   - record exists, p=x, rua=r1
   - record exists, p=y, rua=r2

(The actual p= and rua= values for these two records are of no consequence;
in this example it is only required that they differ from each other.)

Let's put aside whether or not such a configuration is the ideal way to do
things, because that's outside the scope of the working group; let's
acknowledge that the "Holy Roman Empire" method of management of DNS and
email does exist, and so centralized control of DNS across all
organizations is just not possible.

With the current DMARC specification, the receiver actions for policy
discovery would look first for a policy record at, and finding
none, would then look at the organizational domain, This would
result in a policy of y being applied to mail from, and
aggregate reports going to r2.

Perhaps the people in charge of DNS and email for intended for
this to happen; we can't know their intentions without speaking directly
with them (which obviously doesn't scale) but this is what the
configuration would yield.

On the other hand, one might infer from the DNS records that are published
that their intent was for to inherit x for the policy and r1 as
the destination for aggregate reports from the record; this would
be an error on their part, because DMARC does not currently support
discovery of the record at in this case. However, it's not
hard to see that this might be what they intended, especially if the
published policy here is p=none; they may be in the "audit" phase of their
DMARC rollout for their portion of's namespace, wanting reports
sent to a mailbox under their local control, so that they can effect change
quickly to their mailstreams.

The way I see it, we can choose one of three paths here:

   1. Keep things as they are, where if there is no policy published for
   RFC5322.From, the policy is inherited from the org domain, if a policy is
   published there
   2. Change the spec so that the only policy lookup done is for the
   RFC5322.From domain, and if there's no policy there, then DMARC doesn't
   exist for that domain
   3. Change the spec so that policies published between the RFC5322.From
   domain and the organizational domain can be discovered, in order to support
   the most flexibility across organizations.

Option 2 would cause the most pain for the current install base of domain
owners that publish DMARC policies, because even those who understand DMARC
will have to update DNS for domains below the org domain that are used in
RFC5322.From headers. Meanwhile, options 2 and 3 would both require code
changes for domains that do DMARC validation. The larger point, though, is
that there are plausible scenarios that argue for supporting the ability to
publish policies somewhere in the DNS hierarchy between the RFC5322.From
domain and the organizational domain.


*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.