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

Todd Herr <todd.herr@valimail.com> Tue, 24 November 2020 15:52 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 D9A1E3A11D3 for <dmarc@ietfa.amsl.com>; Tue, 24 Nov 2020 07:52:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
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: 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 NZLo8RJ6ReqS for <dmarc@ietfa.amsl.com>; Tue, 24 Nov 2020 07:52:47 -0800 (PST)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 AC9773A11AA for <dmarc@ietf.org>; Tue, 24 Nov 2020 07:52:47 -0800 (PST)
Received: by mail-qv1-xf2f.google.com with SMTP id q7so10784126qvt.12 for <dmarc@ietf.org>; Tue, 24 Nov 2020 07:52:47 -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=+egr6+GzifR3d+2b7EaZwIfmk+omQ/GlZzsaixKHNXk=; b=DtxFVMuY9N5hk2YVY7yWR9HK0/csGcrGol75huqLUxFWTSnQe2x74rzW64b6kk3Fl/ dG2mGbwqzA0zCidMvenBPXl2otiJQpXHhHJwAYto4Q6K49UVPTlccH9BbhSKF1DuwNYH ifFCEdZcrJb9yHShLROBFGoXUa2xzcs/YGe4iCx1lrH5Wg0+taQ/RZtZaiPVl0PB7Pzk MfNKjS0uMe+9xr4nFjAQ+UL5DAE8hnQIK5Q0Bj7liYBJSmBzbDAYMioDqO58uYMeMVmq NL+GEaWXrlOoekbQPm+0ZO9//go+tn9eTVxXzIpZTAmWZ4exISn/nfn/LdKxMbmfZoVP RRww==
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=+egr6+GzifR3d+2b7EaZwIfmk+omQ/GlZzsaixKHNXk=; b=tubNfrTsMMVWR/U52rw7VkcEkT2Bwgb3gg8z9sSp24iRuud+NY9WSTfr0AtbF+v/AW 2JkcThxFdw/D0dKPI19Cj5s6/6UZLPODwwbu6Rn397LRMwiCYlD6Kuc6963sH9t/okqT S/6aOV2JfTYzqDMHSFw36ZNJ+KFraYGNHWO+4cUo1/omQDRF8Sdxu6rTQgzJa6pLZc+C wLJ8SIWmgAVmWxckxXt20cXgIe/+AjOhlRjNTDSq8AdXBUnjSKi4dVfLy/ujgYyf5UGM XR/LQneb4/3VOryF0zGsuTaIPuWx97Ch8s2wSB1YenfJpCY3PnncEZ1XecL4lS3egKap VRog==
X-Gm-Message-State: AOAM53108wKvWUc4RY0I2/+WueRN7q9ZseKAkruTLRVecWP8BmvpQWQo BTs7TM6QEAtWmRwLPGF7Q5YS9y8chZTdGDaupEeuL7cnY6iy5A==
X-Google-Smtp-Source: ABdhPJxZYcCLitO5E9+TRLYbwwoh2UuJU8mTSim+s9NmUiCMnP/MUkl8awjwShyt7+pbXtBJkGg2cw0FwAyNJW5zWX8=
X-Received: by 2002:a0c:f809:: with SMTP id r9mr5571253qvn.17.1606233166437; Tue, 24 Nov 2020 07:52:46 -0800 (PST)
MIME-Version: 1.0
References: <20201123213846.EB14127C8160@ary.qy> <efa0117e-5b17-800d-820d-b5d2413c6075@tana.it> <CAMSGcLBimU5NSBnxDEfSLnBkjhosrxd8_7BaTfA-A5bQyrTe1g@mail.gmail.com> <29d3b145-1652-8b62-5eb2-74993e95eb45@gmail.com> <CAHej_8k_o1yVjOP4wWR1Xz_Tuq-XA0snPAzNQeNPaApbRWy8fw@mail.gmail.com> <be400e78-091c-196c-2d7a-461050e9bab3@gmail.com>
In-Reply-To: <be400e78-091c-196c-2d7a-461050e9bab3@gmail.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Tue, 24 Nov 2020 10:52:30 -0500
Message-ID: <CAHej_8mW3ENNMR7D_Jf6G5uz=EuGc3LCddtmrzVJR-GDq8Q7ow@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004ff1c505b4dc4ddf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/-1yNaOiZDojzijmoGTVswHGyMs0>
Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup
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: Tue, 24 Nov 2020 15:52:55 -0000

On Tue, Nov 24, 2020 at 10:37 AM Dave Crocker <dcrocker@gmail.com> wrote:

> Just to be clear, I'm not challenging the need.  Rather I'm just looking
> for text that explains the need.  And I'm not finding it...
>
> On 11/24/2020 7:28 AM, Todd Herr wrote:
>
> 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.
>
> Except that I do not find either of these points provided in the document.
>
For point 1, this is from Section 6.6.3, Policy Discovery:

   1.  Mail Receivers MUST query the DNS for a DMARC TXT record at the
       DNS domain matching the one found in the RFC5322
<https://tools.ietf.org/html/rfc5322>.From domain in
       the message.  A possibly empty set of records is returned.

   2.  Records that do not start with a "v=" tag that identifies the
       current version of DMARC are discarded.

   3.  If the set is now empty, the Mail Receiver MUST query the DNS for
       a DMARC TXT record at the DNS domain matching the Organizational
       Domain in place of the RFC5322
<https://tools.ietf.org/html/rfc5322>.From domain in the message (if
       different).  This record can contain policy to be asserted for
       subdomains of the Organizational Domain.  A possibly empty set of
       records is returned.



For point 2, this is from Section 3.1.1, DKIM-Authenticated Identifiers:

   In relaxed mode, the Organizational Domains of both the [DKIM
<https://tools.ietf.org/html/rfc7489#ref-DKIM>]-
   authenticated signing domain (taken from the value of the "d=" tag in
   the signature) and that of the RFC5322
<https://tools.ietf.org/html/rfc5322>.From domain must be equal if
   the identifiers are to be considered aligned.  In strict mode, only
   an exact match between both of the Fully Qualified Domain Names
   (FQDNs) is considered to produce Identifier Alignment.




Also for point 2, this is from Section 3.1.2, SPF-Authenticated Identifiers:

   In relaxed mode, the [SPF
<https://tools.ietf.org/html/rfc7489#ref-SPF>]-authenticated domain
and RFC5322 <https://tools.ietf.org/html/rfc5322>.From
   domain must have the same Organizational Domain.  In strict mode,
   only an exact DNS domain match is considered to produce Identifier
   Alignment.




-- 

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