Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 17 June 2021 07:57 UTC

Return-Path: <superuser@gmail.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 C09373A11D6 for <dmarc@ietfa.amsl.com>; Thu, 17 Jun 2021 00:57:04 -0700 (PDT)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cY9Yrkx54qgc for <dmarc@ietfa.amsl.com>; Thu, 17 Jun 2021 00:57:03 -0700 (PDT)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 37D363A11D5 for <dmarc@ietf.org>; Thu, 17 Jun 2021 00:57:03 -0700 (PDT)
Received: by mail-vs1-xe36.google.com with SMTP id x8so2510440vso.5 for <dmarc@ietf.org>; Thu, 17 Jun 2021 00:57:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hNMTATexqciUGoDrdpp9cjA+OXqs1zeBd8tbCaRWeMY=; b=LkDP7qtKdTj1nvUC3Oe0oyL6Rt6u0KZ3ABy6LQfSvj71NlJeWI5IbKUxMwMi/KTeAb OTXdiymiXGzn24dwsLNsUrWp5ehUqVp88Ki9dFpXh/9jvub/vJKuv11bcAxVXSF5qCvH YuuJZygJSJIPHEqGQztmqu1f7SyT3aQjb5Vd5AniFYDTrvIzCUsEFbk0AE2NicnzC8yX S3oy+ENh+V3+x0WlFeHdlYVveHZiIhUl7ZU/R7A+wtof6dDOjj3GTz6MqWMHOMBnwUcb 7qM9bjVpGgQzshNvAZdmENMX5tDAWIzD7NaoJeHLYivaGD/K2NJXtYEYpF3HeQjKC3/s mB3Q==
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:cc; bh=hNMTATexqciUGoDrdpp9cjA+OXqs1zeBd8tbCaRWeMY=; b=OGoaCbHL69PkAih5v8Ae99HLSGCMusXoDKa+13ttVjzkpt4Zbk88ol4PPtKANdjIsU Z0fjMwOZ7/OjlJ0fHb9bFzGxIoIgjijS6E3cVvWCZ3u2PZnTHOSjbR+WoKi360hThZuw 2bztCtXGh10EsHodYfaxQA/wqn1S8bILeCYHdp/tpbklotsjNBk091YbvZNF54uUjAIe ayCL2zQ76kFRp4fWjb1BsdpR3u7Juw05MuIqr8TK9msA9LZgcOQozJwC8zLnrXFoUM8k MEptbyefuUaFcJtZslFJsMIuyjAvavVHci6NxyX2KBZ7hClw0Ev2rcJLxZCHLJYkfVeD woig==
X-Gm-Message-State: AOAM5320/vMqvgRyJO/TIt7nKhibv3NELGwPgFMwDV8PjvJrTttSL7v6 Puddmsg+7ZiPVkRNf8IImThO65+WN8yjqKQKjTA=
X-Google-Smtp-Source: ABdhPJzfj4adii76BoXh/s1Fpd/xvLccsgMKKpIPtd3QPjQzDfVjad4tzINKIMirNjVrUaXSWyHyjeak6gaA6bQYKgM=
X-Received: by 2002:a67:1a45:: with SMTP id a66mr3093916vsa.15.1623916621359; Thu, 17 Jun 2021 00:57:01 -0700 (PDT)
MIME-Version: 1.0
References: <20210616160110.09D6011E70FD@ary.qy> <71e61630-0bc8-c9f1-6e7c-5267889c15af@tana.it> <CAH48ZfyYSW5003cxgP0r_skzSdfNvV9FL=sY_32PwQ1dWXxFCg@mail.gmail.com>
In-Reply-To: <CAH48ZfyYSW5003cxgP0r_skzSdfNvV9FL=sY_32PwQ1dWXxFCg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 17 Jun 2021 00:56:50 -0700
Message-ID: <CAL0qLwYsTgRJ8PnjG7nAdTJJ54ww2HWtvOGp2EeMqNStjD6X8A@mail.gmail.com>
To: Douglas Foster <dougfoster.emailstandards@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005c6d4305c4f18d16"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Vnc_HPXIxKF7w1Zq8TiYEtiQrxs>
Subject: Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
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, 17 Jun 2021 07:57:05 -0000

I continue to not understand the defect you're highlighting here.

I think you've expressed yourself primarily in the abstract.  Could you
craft a sample message, sample envelope, and sample DNS context that
highlights the problem you're talking about?  Maybe then it'll snap into
focus.

On Wed, Jun 16, 2021 at 2:43 PM Douglas Foster <
dougfoster.emailstandards@gmail.com> wrote:

> NXDomain on RFC5322.From is a completely different issue.    It means that
> the name is only used for service provider messaging, and is therefore not
> linked to any IP address or other physical infrastructure.  It affects the
> ability to define a meaningful NP test.   The issue becomes irrelevant to
> DMARC if and only if we drop the NP policy idea completely.
>
> The proposed MX/A/AAAA/SPF test has two significant problems:
> - It incorrectly classifies some names as NP because they do not need
> MX/A/AAAA/SPF records because they are not tied to an IP address, and we
> have provided a very poor mechanism for a domain owner to come into
> compliance.
>

There's a workaround here: If I want to use a name that is not represented
in the DNS according to that test, all I need to do is DKIM sign with my
parent domain.  That makes "p" apply because now you have an aligned
"pass", which presumably trumps any "np" that's set.

If you aren't signing with DKIM in that scenario, and you obviously can't
pass SPF either, then you can't possibly hope to pass DMARC irrespective of
any test being done on the name's validity.

- It incorrectly classifies some names that are not used for email as not
> NP, simply because they have an A/AAAA record.   It provides no method for
> the domain owner to signal that the name is not used for email and
> therefore should be treated as NP.
>

If they're not used for email, then they're not in DMARC's problem space.

At any rate, since PSD has been approved, I'm hoping the experiment is
underway, or will be soon, and then we might have some actual data about
the severity of this defect and thus also possibly some hints about ways it
can be mitigated.

-MSK