Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-07.txt

Todd Herr <todd.herr@valimail.com> Fri, 22 April 2022 14:57 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 8A00F3A16ED for <dmarc@ietfa.amsl.com>; Fri, 22 Apr 2022 07:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 1Brz_ilSvAWY for <dmarc@ietfa.amsl.com>; Fri, 22 Apr 2022 07:57:38 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 A53053A16F3 for <dmarc@ietf.org>; Fri, 22 Apr 2022 07:57:38 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id s4so6006255qkh.0 for <dmarc@ietf.org>; Fri, 22 Apr 2022 07:57:38 -0700 (PDT)
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 :cc; bh=lFeKus2QrPXiCI4GjomtLE9zdXSchsaR/CYNsNGgB6Y=; b=cwkTMtGwelMt54OrNgesX2JM6hFlSn5xvUrwSWAn+FsNyXoHlgicKBJV+1KbL7OKMl 1JO7Y2jr0uKzV4DGTcvIdVRuhD6jgqBZ48crSw8puA1WWOhFxVlCP96OK6Vpi32lJyzl 5B/UUkkPsVo3M+d5guPJC0F45di1uC4GPIf3iKm6Ad09/PY81rAtO1rcB9SGZEfL79FL b5zizTcRL3dznXr9BUC9W4bhsEV9FAiif2XKBcR9AB9Xpcy8wAhco9TzsW2h4L+EC4jr dnPGdj9vngMCbhmQfHOJd+/yfkg75DD1OWqx5+ztQUQSn15rFWxJHse6cLdU8sZd7s8z 3UTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lFeKus2QrPXiCI4GjomtLE9zdXSchsaR/CYNsNGgB6Y=; b=Q/MZX3EayPhwxuFi3R+CM+bQsW5azLo1Nv5CeNInA+6KaYcJZPil9O9UQaimZMIjkq q13aoKziaitjIxHaeq39Xxu/VOygoacDk2C5/AfW003Kw2/zvIpWUmiu45VOpK3XJZY3 VgRXHBOPKaE8ZiZ03DcjBneV6obw4GossaGtANTMY6Y/KQ+VqlIxp8tb9MaT1Mf/E2NJ BNOzEoxb3eHyS0Hqockt4HwelmUEVLHroiV2h47+aDqfG4SOWsIgbYI1L4iOqgst2hgs uOXSdgYOFlMKejGWKtdYvrjj13TFED3aBIGjINcnIf7earzUkuz2eMpQY8XA5HWHXDgi 4GpA==
X-Gm-Message-State: AOAM530a9ozCOBkoUwGp/4lVtbHYckoVNCZLXBAFJ324klQAYmG3LE83 KM1J5c477KaMrzLFORhcMscIQJPblg38xcHDuRof3Dftcd8=
X-Google-Smtp-Source: ABdhPJzMe9QqVsfRv0lxCBOlMPKCaSLcdJtjBoH2TabZ31HRtWO93Q+DoPxPnLpmnh5eXNXPQzMhjNYoJpubwO9Ejfw=
X-Received: by 2002:a05:620a:408d:b0:69f:412:e171 with SMTP id f13-20020a05620a408d00b0069f0412e171mr2934011qko.628.1650639457461; Fri, 22 Apr 2022 07:57:37 -0700 (PDT)
MIME-Version: 1.0
References: <164925666278.4445.13789431014958416691@ietfa.amsl.com> <CAKFywTKC3HUz=G2O+YvnbqZ0sqMM9XfUiw=jZMu1PSVqMtPcTQ@mail.gmail.com> <30789809-B1ED-4757-86CC-0E3C571B1299@kitterman.com>
In-Reply-To: <30789809-B1ED-4757-86CC-0E3C571B1299@kitterman.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Fri, 22 Apr 2022 10:57:21 -0400
Message-ID: <CAHej_8=9JsLyXRTXCdh1h918o8ZUPVEMfZB0W760c51s2SWKSA@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="00000000000083bb2c05dd3f72ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/GXkIz1CkniHJn-Tybxmo89Ud68M>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-07.txt
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: Fri, 22 Apr 2022 14:57:44 -0000

On Fri, Apr 22, 2022 at 9:15 AM Scott Kitterman <sklist@kitterman.com>
wrote:

>
>
> On April 22, 2022 7:35:29 AM UTC, Robert <aradesh@gmail.com> wrote:
> >In section 4.8. Organizational Domain Discovery, we have:
> >
> >   Note: There is no need to perform Tree Walk searches for
> >   Organizational Domains under any of the following conditions:
> >...
> >   *  There is no SPF pass result and no DKIM pass result for the
> >      message.  In this case, there can be no DMARC pass result, and so
> >      the Organizational Domain of any domain is not required to be
> >      discovered.
> >
> >---
> >We would still want to find a record to know who to send failure
> >reports to no? And this would involve some sort of tree walk if the
> >MAIL FROM doesn't have a record. Should it be changed to something it
> >like:
> >
> >   *  There is a DMARC record at the RFC5321.MailFrom domain and there
> >      is no SPF pass result and no DKIM pass result for the
> >      message.  In this case, there can be no DMARC pass result, and so
> >      the Organizational Domain of any domain is not required to be
> >      discovered.
>
> I agree the current text is a problem.
>
> This case is guaranteed not to pass, so you would need to know what policy
> to apply.  There's another item in the note that addresses the portion of
> this case where the 5322.From domain has a DMARC record.  If the 5322.From
> domain doesn't have a DMARC record then we do need to find the org domain
> to determine the policy to apply.  I think this should be deleted, not
> modified.
>
>
I believe when I wrote what's current section 4.8 that I was operating from
the assumption that tree walks would be performed sequentially, not
simultaneously, and in the following order:

   1. DMARC Policy Discovery
   2. Organizational Domain Discovery

Note that the second bullet in this section, which is elided in the thread,
reads:


   - No applicable DMARC policy is discovered for the RFC5322.From domain
   during the *first* tree walk. In this case, the DMARC mechanism does not
   apply to the message in question.

Further, the thinking here was that the Organizational Domain is only
necessary to discover when relaxed alignment must be determined between the
RFC53222.From domain and either the SPF or DKIM domain (or both) don't
match the RFC5322.From domain, and we've already determined that DMARC is
in play because we found the applicable DMARC policy during the first tree
walk.

All that aside, I'll happily update the text for the next rev once there is
text proposed.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.herr@valimail.com
*m:* 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.