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

Douglas Foster <> Thu, 17 June 2021 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBC973A25A3 for <>; Thu, 17 Jun 2021 09:18:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 kJ-DNi1UDOy3 for <>; Thu, 17 Jun 2021 09:18:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4DC03A25A6 for <>; Thu, 17 Jun 2021 09:18:00 -0700 (PDT)
Received: by with SMTP id o5-20020a4a2c050000b0290245d6c7b555so1701111ooo.11 for <>; Thu, 17 Jun 2021 09:18:00 -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=9oWlyDRDcqWcqLrO/leOAvqg6IpMBjFlaPB0nptWj7w=; b=Xd+BC/OnZe+DGrMb4lKa1BfkNdiCh2Olcs0w/YYJl+bFNm4lOX1/v7TXyH+JsDy3nG HRfcl1iksCD9liGelsDsXy1ooCjK68FaTOxD5sYTUTLBy6IWxPhK2HzoxvEE2zNf0Wq9 cifVd3I4eRuMvfsNgdL/AXFNsNPRw6QV4Pl7lzUCz6SBZRs848a0Pl3mzv5v4S21/ZXL 913lVn2tb3aN41mW5A2ooaBqYVaQPmcAbmgqulIzKd3xzp3SfjQQUh3HpXVZuql9zv+z s0NYeB248dRlUZc88guBlOy05vTHt2QVBgujr0g7UV1SRePKNs8fcTsD1GdUqlCmTZRs y+xQ==
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=9oWlyDRDcqWcqLrO/leOAvqg6IpMBjFlaPB0nptWj7w=; b=VWV2Mof5jU/TtfvBP63X5Wxv9t7068/Cx5yZjWly9FynMrlftR/QV0lFaIJIbgn6L2 0Erzis3ODmn4iE3ZfW4kD3UYvCe/Cqy7ZG7ek6J7zrIV+o17MA+BzxxtpI5ydZBwBtdc QOIKrHsMVneJRzagA93/xq5WrLPzB+EWLOk1mpYtzhS6w3NxoytO0ttgkdTLqxCC2wNh T0usgQO8RKuWHPCSKI8e8sU1cFEx2N177pYIorPhQ7HuRkwkFahwIjy6wqGnmTYh3BQk BrgNtnZwF0Kwk/LuRF+LtSx+WwHaA92KMdynNIyCGkYQB2xWQ9qmInLMLy2EYeMTEqoN YaPw==
X-Gm-Message-State: AOAM532Ws2mB7Xb3quUfiPi5+X8R/aXB+T8v8ofcZcO2fvhOeoEl9lXx 6Q5mKcTLiyvjLLkr9n7Ag2C9K7W04PJSzZMBwVKxLCS8CGU=
X-Google-Smtp-Source: ABdhPJzhIrzG3FW1HYjdYE1/4MsmSYydpsiRfb2v8bduuzyLR/nmeUDD/e1uKCnc3A4iH+Rjli+dJL9y0qJLik3n2sY=
X-Received: by 2002:a4a:d456:: with SMTP id p22mr1710543oos.13.1623946679036; Thu, 17 Jun 2021 09:17:59 -0700 (PDT)
MIME-Version: 1.0
References: <20210616160110.09D6011E70FD@ary.qy> <> <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Thu, 17 Jun 2021 12:17:48 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000f02d1c05c4f88c56"
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: Thu, 17 Jun 2021 16:18:05 -0000

This is frustrating.   NP is a new design and the design issues should
have been discussed before we got to this point.   I don't know why so many
people are eager to not define the new technology.

There seems to be an unwillingness to acknowledge the current state of the
email ecosystem.  There seems to be a mythology that any email suffix used
with a mailing service must also exist elsewhere in the ecosystem as an
SMTP sender and receiver.   The MX/A/AAAA/.SPF seems to be based on this
myth.  There is no such necessity in the real world.

For a legitimate message, where a mailing service uses its own identity for
MailFrom and the client's identity for the From, the From address has very
few constraints:
- IETF format rules
- DMARC policy if present
- Mailing service business practices

On mailing service business practices:
I find that the major mailing services can be trusted to correctly present
the client organization.  But that does not include a requirement that the
email suffix has a separate identity as an SMTP sender and receiver.   My
data indicates that they will be happy to let @Example.Com send a message

On DMARC policy
NP is only relevant if:
- The message does not authenticate.  DMARC PASS continues to be a final
- A domain P policy does not apply.   P policies override SP and NP
- The SP policy is NONE and the NP policy is QUARANTINE or REJECT.   (If
the NP policy is the same as the SP policy, the result will be equivalent
to RFC7489 SP without NP.  If the NP policy is weaker than the SP policy,
the configuration is simply stupid.)

NP is an effort to partition the RFC 7489 SP=NONE result set, so that a
subset of all SP results can be blocked on some additional criteria.
This additional criterion could be based on non-existent as indicated by
NXDOMAIN, or it could be based on "not used for email" based on a criterion
to be defined.   Either approach needs to have a mechanism for
non-compliant names to be made compliant.   I believe that this should
involve a DNS entry, but the compliance measure should be specific to the
NP test.   Requiring that every FROM address be linked to an IP address
does not meet that requirement.

Doug Foster

Doug Foster

On Thu, Jun 17, 2021 at 3:57 AM Murray S. Kucherawy <>

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