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

Douglas Foster <> Wed, 16 June 2021 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2AB7B3A27CF for <>; Wed, 16 Jun 2021 14:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, 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 AM-xpg7e-UVT for <>; Wed, 16 Jun 2021 14:43:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6A5C3A27AC for <>; Wed, 16 Jun 2021 14:43:20 -0700 (PDT)
Received: by with SMTP id d19so4091571oic.7 for <>; Wed, 16 Jun 2021 14:43:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BF0Ov+kMRb425eTO5JJkTKHmLogyd65SCvbGqjSae6g=; b=eOqpqwkvkhqMrxo06XW6AAW0mpQ6wVJ0w3/a2+pjb4nvHm18HqolD/mu1x25UG55If CTSpHpjcu0sGWKAspSetcpGUM2Qm41PcSA0Lo0THThharHaq07Qvx3uMiZpLgFV5wxVU ctMmD3/VJIPGg1r7QRD1OSX8cMcWqhfXLmXbjsZDTCydfw/y1f6yaYZQ+DkQCE7elgzy L3JPom3yfXL1doa7KDjxt4Umyu8WpUigYAfVkvNCxqB6YBtuz7wTD1MbBHoGFri6KM4J efygd+cBfD0JBFuz/7cktBIvp6Cjk3wyKSGZEWuokD0GFGZfW5zlA3MBV3OeXGVEygI+ ulig==
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=BF0Ov+kMRb425eTO5JJkTKHmLogyd65SCvbGqjSae6g=; b=huJTia/9WPsbqxdRHyKGkIhCcNi1M1JHZn6aV0LF9YnO/v9FF5qtkFQaEQXVmrIKqe t1YbXRsjptcG+cBD4t4lC8HyUIto0LY/s8GcKkaSkx3JQ6G7WsHkyZa/7haV3AGWkCTz wjPNBmFefG7hDuattNXQO3r3tB5mjGhzqUxnRuM8kccFv0vU6AUW1Od/EHCuHiQMaIPM W70VIf3orM941Rpol3Ojph0kk5wHrw7POpPuNnrjJ1lQIJK6qYn/3Ku+2h+h0WFljyeY 4tgr6bskisC8LAjG4+E7wX7/9aDV1laANaBejL2jJ0QcWORcTiCy8tIwPsjtQBA5ozA3 dB8g==
X-Gm-Message-State: AOAM530FG3VUybEU1ToUJ3DQReBsZANVp7+awzpuKFurACXK7IlQcsbP LBklqpfrc9Ho8g8+L/kvZBbluisFS9o/awhSwEdXmRPdi6M=
X-Google-Smtp-Source: ABdhPJzVa+wT8tKajVI8+ZI5kb7/dKbOxtnhtuVJ9U36cOL1iZfIteA67FzR08dIcfqQ6IT/TWosIajLQyjtWivwl6c=
X-Received: by 2002:a05:6808:130d:: with SMTP id y13mr2048047oiv.146.1623879799502; Wed, 16 Jun 2021 14:43:19 -0700 (PDT)
MIME-Version: 1.0
References: <20210616160110.09D6011E70FD@ary.qy> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Wed, 16 Jun 2021 17:43:08 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000009b7cdf05c4e8fa59"
Archived-At: <>
Subject: Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
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: Wed, 16 Jun 2021 21:43:25 -0000

You or the others seem to be confusing NXDOMAIN on RFC5321.MailFrom lookup
with NXDOMAIN on RFC5322.FROM.  The issues are very different.

NXDomain on the MailFrom lookup says neither the SPF policy nor the SMTP
domain exist, and therefore there is no reverse path.   Rejecting such
messages makes a lot of sense and, as has been said, has nothing to do with

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

With the expectation of significant errors in both directions, we do not
have a usable definition of NP.

Doug Foster

On Wed, Jun 16, 2021 at 1:51 PM Alessandro Vesely <> wrote:

> On Wed 16/Jun/2021 18:01:08 +0200 John Levine wrote:
> > It appears that Alessandro Vesely  <> said:
> >>However, to reject based just on NXDOMAIN is too harsh.
> >
> > I dunno, in my experience it's quite common, and if you do, the chances
> of losing a message you care
> > about are negligible.
> It's been customary to reject NXDOMAIN in smtp.mailfrom since when I
> recall it.
>   To reject NXDOMAIN in header.from is (was) an ADSP feature which doesn't
> seem
> to be very widespread.  DMARC dropped it a long time ago.
> > In any event, this has nothing to do with DMARC.  If for some reason you
> want to do a DMARC evaluation
> > of a non-existent domain, you can use the organizational domain or I
> suppose PSD.
> It might make sense to reject that ~30% which doesn't even have an
> organizational domain (dubbed totally astray in my previous post).  But I
> still
> receive From: <> on a mailing list.
> Rejecting that
> risks getting unsubscribed.  Perhaps mailing lists deserve a special
> permission...
> Best
> Ale
> --
> _______________________________________________
> dmarc mailing list