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

Douglas Foster <> Sat, 12 June 2021 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 233F83A1D12 for <>; Sat, 12 Jun 2021 11:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wBC2LGdJnJtu for <>; Sat, 12 Jun 2021 11:48:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 405EB3A1D10 for <>; Sat, 12 Jun 2021 11:48:38 -0700 (PDT)
Received: by with SMTP id t40so9669739oiw.8 for <>; Sat, 12 Jun 2021 11:48:38 -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 :cc; bh=D4s5qnEZexHQe5SY/+8mNPflOlf6GXm3leq+qp3vZiE=; b=VYIn3FospulIgRxbGaIjXP8pMK5xakYHEAf9XaTJWZQaHFXCM6anhaS3sC073T7Ztw /qRiqKZq5p3U+AxPkF7dd/MPi4vtq4WzZ2Q1xJSQa4KzpAonrJ0sJRZaf7IZEGyEgHFB EmKhSbXl+y6SDCNtloIUcVLfTA4DFPhZsSWpf0MMahD4n7BhQmDy+aNDshxrLNBZwGfe OR89uyZG/Yq/51oVCSYpCdgdZrrV81plGtNy9BeF8dkV0LaKwHYH88hghQqq8mpJ5r3t ROWtOk1beSq8WwGZfC2zLyf34gojWxWdQa7gDo0qXtpkafaUwIgxl71YGBiALiXwrWO3 HFgw==
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:cc; bh=D4s5qnEZexHQe5SY/+8mNPflOlf6GXm3leq+qp3vZiE=; b=teMOt7Xy+81IdOBrmHaHccg63/4h5X4PC0rd8BOfqXwm3PV75ayh9DE6qGdl4MP/3k //VgQVdpIkkPMVJNVhapsHo8XHD4E9Oaq1ULN9bo9Tzj1COGgku8IyotIrIIZYxPE7JP DGYez09PDoih7Id/an9J1KtslITmghpxyR6rqyWuqN7LY7F03dbo0aYHhUDOJR5JvUK/ INYH7gL88bbzv+IYsWejsBnD1XPiOW2Dx5R3zkpx6QC7MEqGsUzLowWWp+Phw7waCkx1 7VThFI/mx+tdHLaAX17D+vSvPtiF6+ENPH9npTFG0Njl/Z6HPY7/5V3GzTnYKTXXXgts drkQ==
X-Gm-Message-State: AOAM532wsnNjlHx034gplKgCt19TyEPlU5uJjPdJJIrR5AkCgGxayAEn kpO9ofNXc4sA6/R6VKYKBJcSAW1u4ZBtViTfAUo=
X-Google-Smtp-Source: ABdhPJxHDBtno3vAwqDhkkAL82fVV8/QqBgdM0tPffBeM3krFFIWmyFD+IcPJX1TbH2QOMKfUYlggJcYLl4ieR37JC4=
X-Received: by 2002:aca:bd42:: with SMTP id n63mr17143289oif.73.1623523715567; Sat, 12 Jun 2021 11:48:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Sat, 12 Jun 2021 14:48:25 -0400
Message-ID: <>
To: Dotzero <>
Content-Type: multipart/alternative; boundary="00000000000059d47905c4961235"
Archived-At: <>
Subject: Re: [dmarc-ietf] Ticket #111 (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: Sat, 12 Jun 2021 18:48:40 -0000

(Subject ticket number corrected.)

Michael, I am surprised and disappointed by the severity of your critique.

NP Policy
The NP policy is upon us.   PSD for DMARC demonstrated the need.    The
problem is that their definition of NP, which the current DMARCbis draft
inherits, is a pre-SPF test for an invalid SMTP MailFrom address.   It is a
bizarre stretch to apply that test to the RFC5322.From address.    The
current test is insufficiently defined, undefended, and indefensible.  It
must be fixed.   The focus of this draft is a proposed fix, because there
have been no other fixes offered.

The key insight behind the NP policy idea is that some domain abuse can be
detected and rejected without depending on the attributes which create the
mailing list problem.  The best boundary for the NP policy is between those
names that are used as FROM address and those that are not.   Domain owners
currently lack sufficient mechanism to signal that condition correctly.

I evaluated options based on NXDOMAIN, but rejected them.  Even when done
perfectly, NXDOMAIN excludes a smaller set of unauthorized names than this
approach, and seems more difficult to implement.  NXDOMAIN has some nuances
which I found problematic.  This proposal introduces relatively low
compliance measures for those domain owners that wish to implement NP.

The Introduction
As to the introduction, I think the relationship between SP=NONE and the
mailing list problem has been well elucidated.    Nor do I think that an
introductory sentence needs to enumerate all possible reasons for SP=NONE.
 But if you prefer to simply say "some domain owners have difficulty moving
beyond SP=NONE,", without any additional comment, I can accept a change
along those lines.   Getting the correct definition of NP is my priority,
not the opening sentence.

Validate vs Reject
Sender authentication involves two partially independent goals:  proving
that a message is definitely authorized, and proving that a message is
definitely not authenticated.   Proving authorization is only relevant for
names that are used as email addresses.   Proving non-authorization has a
much larger scope, because it involves all possible names, not merely
in-use names.

RFC 7489 attempted to prove non-authentication based on domains achieving
SP=REJECT and messages being delivered without in-transit loss of
credentials.   This has not worked out well in practice.   NP defines
non-authentication based on attributes which are not dependent on transit,
and therefore it is a very powerful idea.

Level of Detail
I could be convinced to move some of this content into a Best Practices
document.,   But my target audience is not limited to the big organizations
that can build custom code and spend a large amount of money on
consultants.   I am equally concerned about the smaller players who are
dependent on off-the-shelf products available from vendors, and the
developers witin those vendors who often implement to the specification
rather than to the security problem.   So yes, I favor laying things out
clearly, rather than assuming that sophisticated people will be able to
read between the lines.

If you have a different definition of NP, let's hear the proposal and its

Doug Foster