Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

Doug Foster <> Mon, 23 November 2020 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BA423A0C25 for <>; Mon, 23 Nov 2020 10:43:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I1v3JNo10YPp for <>; Mon, 23 Nov 2020 10:43:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 596043A0C23 for <>; Mon, 23 Nov 2020 10:43:11 -0800 (PST)
X-ASG-Debug-ID: 1606156988-11fa313c0139ca0001-K2EkT1
Received: from ( []) by with ESMTP id s7WqzHf21dLH7TB4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 23 Nov 2020 13:43:09 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1025; h=message-id:subject:to:from; bh=jHSmwuCXZnzSS2Zau+tlCdth9XOH5feflRbhyqn+s0g=; b=hDKPGh1cPW1OXIrjpNoTetW1jorr2zFvpFkbv0PsoTYYUUCA+GGSKHzLVx51gMwxz Rjp4wmP6tzi0NG3e2WhZKGopkStjFXMi6CI7JqVhiU2uLVQ1ycQRqxLfJoGYcXkiJ eKHvris1oSfAVJcsS+TJy0hojssSlayO76LE1u7LI=
Received: from MSA189 (UnknownHost []) by with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Mon, 23 Nov 2020 13:43:01 -0500
From: "Doug Foster" <>
To: "'Tim Wicinski'" <>
Cc: "'IETF DMARC WG'" <>
References: <003f01d6bcf0$69055b60$3b101220$> <> <> <> <>
In-Reply-To: <>
Date: Mon, 23 Nov 2020 13:43:02 -0500
X-ASG-Orig-Subj: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
Message-ID: <00d001d6c1c8$79804e00$6c80ea00$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D1_01D6C19E.90AD2C30"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJImLb1cmUMRltHAmghMYnlRx5C7gMRkJ65AaptzrECDxExzgEDiy0OqLPmFyA=
Content-Language: en-us
X-Exim-Id: 00d001d6c1c8$79804e00$6c80ea00$
X-Barracuda-Start-Time: 1606156988
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-BRTS-Status: 1
X-Virus-Scanned: by bsmtpd at
X-Barracuda-Scan-Msg-Size: 41924
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
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: Mon, 23 Nov 2020 18:43:14 -0000

I was misinterpretation the language to require detection whether any host existed in the zone, rather than checking whether there is a host name which matches the domain name.  Thank you to Murray for straightening me out.


That aside, we still have a problem.   The specification is applying SPF-type logic to an address that has no necessary connection to SPF.   A typical advertising message, sent be a third party, will pass SPF using the third-party sender’s domain.    The message From address becomes a label to identify the client organization in some manner, and possibly to identify the identity of the marketing campaign.  The domain name used for that purpose may not exist anywhere else, often does not accept replies, and may not exist as a mail server domain anywhere.    Consequently, these may very well be unregistered domains, but it may be reasonable to insist that domain owners get them registered to avoid false positives from the test.   The least disruptive test will be for NS.   Anything stricter will produce false positives.


The logic that seems to work is:

-          Check SPF and DKIM for domain alignment.   If the DMARC criteria are satisfied by either method, the message domain does not need to exist, because it has been validated.

-          If the message does not pass DMARC alignment, then we need to look for a DMARC policy to see if P/SP/NP applies.  If NP applies, and NS does not exist, the NP policy is applied.


Using the example domain from the document, I am assuming that we are trying to block all three of these non-existent domains:




If the goal is only to block, then the current NP algorithm is slightly less problematic.


Doug Foster



From: Tim Wicinski [] 
Sent: Thursday, November 19, 2020 11:04 PM
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP




In looking for domain presence most folks will look at the domain itself.  There are a few web tools to enumerate

such as 


Some examples


There are unix tools - such as 'dig' - which are also quite useful.


hope this helps




On Thu, Nov 19, 2020 at 10:44 PM Douglas E. Foster <> wrote:

Time to show my ignorance again.


How do I check a domain for presence or absence of A, AAAA, or MX records?

I thought most domains were protected from enumeration, so one had to know a name to find out if it is defined






From: "Douglas E. Foster" <>
Sent: 11/19/20 9:27 PM
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP


Thank you for the pointer Eric.


Can someone explain why the chosen algorithm, which requires testing multiple conditions, is preferable to a single query for a name server record?   Minimizing DNS traffic has been part of our recent discussion, and minimizing software complexity is always a good thing.


Can someone also explain why the DMARC appendix takes such a strong stance against all queries for non-existent domains, regardless of technique?  It seems like the philosophical incompatibilities need to be addressed before both documents advance.


DMARC is specified only as a test for the RFC5322.From domain.   RFC5321.MailFrom domains may also be non-existent.  They will return SPF NONE, but that is an ambiguous result, and SPF has no organization default mechanism.   

*	Is there data to indicate whether evaluators have found that checking the RFC5321.MailFrom for non-existence is useful?   
*	Suppose that the NP policy becomes generalized, and a domain has asserted a "must-exist" DMARC policy.   Should a non-existent subdomain used in the RFC5321.MailFrom address be treated skeptically?

I can imagine a scenario where a spammer uses a bogus subdomain of a legitimate organization, in an attempt to get whitelisted by spam filters which primarily evaluate the RFC5321.MailFrom address.   This attack could be paired with an unrelated and non-DMARC RFC5322.From address which is newly minted or otherwise not generally known to be suspicious,   So my instinct is that some extension of DMARC to the SMTP address will be beneficial.


Doug Foster






From: "Chudow, Eric B CIV NSA DSAW (USA)" <>
Sent: 11/19/20 5:31 PM
To: 'Doug Foster' <>om>, 'IETF DMARC WG' <>
Cc: "''" <>
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP


Section 2.7. defines a non-existent domain as "a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is a broader definition than that in NXDOMAIN [RFC8020]." This should be sufficient for determining that the domain is not intended to be used and therefore could have a more stringent policy applied.


The idea of looking for a "mail-enabled domain" based on if an "MX record exists or SPF policy exists" is interesting. Although there may be domains that send email but not receive email and so may not have an MX record. Also, even if there is no SPF record, the domain may still send email, but then it might be held to a more stringent DMARC policy that would further penalize it for not having an SPF record.


Also, for the revision of the document I like the way that the three parts of the experiment are now laid out more clearly. My only comment is that the title of Appendix A is overly specific to just one of the experiments and so should be broader.




Eric Chudow

DoD Cybersecurity Mitigations


From: Doug Foster <>

Sent: Tuesday, November 17, 2020 9:46 AM



Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP


I did not see a definition of a "non-existent domain" (the np policy).   A definition is needed.


To my thinking, the obvious rule should be to query for a NS record for the domain.  If the record exists, then the domain owner could create a DMARC record for that domain, or could create a default entry for the domain at the organizational level.  If no record exists, it is because the domain owner chose to not create one.


However, the DMARC Bis document conflicts strongly with this.  In section A.4, it suggest several ways to do a test of this type, then repudiates all of them.  NS lookup is not one of the mentioned options.


There is a possible second-level policy test for a "mail-enabled domain".  I would define that test as "MX record exists or SPF policy exists".    That could be an additional option to NP, but should not be a replacement for it.


PSD for DMARC clearly intends for the NP policy to be a general solution to a general problem.    If there are still objections to it becoming a general solution, this should be addressed soon.


Doug Foster



From: dmarc [] On Behalf Of Tim Wicinski

Sent: Friday, November 13, 2020 1:42 PM



Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd





During the IESG reviews of draft-ietf-dmarc-psd, there were several issues raised with some of the document.   Most of them are editorial but the one big item was the description of the Experiment.   The chairs sat down and broke out the experiment section into three separate experiments, and included language on how to capture the data to confirm how the experiment worked. 


It's enough of a change that we wanted to do a second working group last call to make sure the working group agrees with our changes. The diff of the current version with the previous version is here: 




This starts a *one* week second working group last call for  draft-ietf-dmarc-psd

Please review the changes and offer up comments to the working group.


This working group last call 20 November 2020




dmarc mailing list