Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts
Todd Herr <todd.herr@valimail.com> Thu, 19 November 2020 20:34 UTC
Return-Path: <todd.herr@valimail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3F53A11DB for <dmarc@ietfa.amsl.com>; Thu, 19 Nov 2020 12:34:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smcXVPuLY5f3 for <dmarc@ietfa.amsl.com>; Thu, 19 Nov 2020 12:34:05 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDF13A11D9 for <dmarc@ietf.org>; Thu, 19 Nov 2020 12:34:05 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id z24so3432813qto.3 for <dmarc@ietf.org>; Thu, 19 Nov 2020 12:34:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; 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; d=1e100.net; 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> <2cabc3c3-3f72-f3f8-0909-860112d25141@dcrocker.net> <a166ad22-8229-9662-f480-9953607df88d@taugh.com> <fab8a341-dde0-31b9-c770-3029e76d43fb@tana.it>
In-Reply-To: <fab8a341-dde0-31b9-c770-3029e76d43fb@tana.it>
From: Todd Herr <todd.herr@valimail.com>
Date: Thu, 19 Nov 2020 15:33:48 -0500
Message-ID: <CAHej_8kfimLTf_iJnPTEC-aE9a7-h7M1bY7vPL7u5J=cAeGPqg@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000013315605b47ba6f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/F8cuRsf4_RrHKdZTdmbLelgVXGU>
Subject: Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2020 20:34:07 -0000
On Thu, Nov 19, 2020 at 7:39 AM Alessandro Vesely <vesely@tana.it> 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 - a.b.foo.com - _dmarc.a.b.foo.com non-existent - _dmarc.b.foo.com record exists, p=x, rua=r1 - _dmarc.foo.com 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 a.b.foo.com, and finding none, would then look at the organizational domain, foo.com. This would result in a policy of y being applied to mail from a.b.foo.com, and aggregate reports going to r2. Perhaps the people in charge of DNS and email for a.b.foo.com 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 a.b.foo.com to inherit x for the policy and r1 as the destination for aggregate reports from the b.foo.com record; this would be an error on their part, because DMARC does not currently support discovery of the record at _dmarc.b.foo.com 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 foo.com'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 *e:* todd.herr@valimail.com *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.
- [dmarc-ietf] org domain and dns-perimeter draft Dave Crocker
- Re: [dmarc-ietf] org domain and levine-dbound and… John Levine
- Re: [dmarc-ietf] org domain and levine-dbound and… Dave Crocker
- Re: [dmarc-ietf] org domain and levine-dbound and… John R Levine
- Re: [dmarc-ietf] org domain and levine-dbound and… Alessandro Vesely
- Re: [dmarc-ietf] org domain and levine-dbound and… Todd Herr
- Re: [dmarc-ietf] org domain and levine-dbound and… Alessandro Vesely
- Re: [dmarc-ietf] org domain and dns-perimeter dra… Doug Foster