Subject: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

From: Douglas Foster <[email-masked]>
Date: Wed, 5 May 2021 07:28:12 -0400

The MX/A/AAAA test is an appropriate tool for verifying the probable
existence of a return-path based on the RFC5321.MailFrom address. In the
early days, the requirement to send and receive non-delivery reports meant
that all mail systems had to participate bi-directionally. This is no
longer the case. Non-delivery reports are officially discouraged, and many
messages announce that the return-path is unusable with a NoReply username.
For testing RFC5321.MailFrom, SPF is now a necessary part of the
calculation, so its absence from the proposed test is baffling.
Additionally, use of MX/A/AAAA as a substitute for a missing SPF policy is
now discouraged in some circles.

The A/AAAA portion of the test reflects a necessary transition process to
MX, but that process should be complete for any domain with enough
sophistication to publish DMARC policies. As defined in RFC 5321, the
A/AAAA test does not even require that the A/AAAA record be a domain-level
name. We know that there are many more A/AAAA records than mail systems, so
we can be certain that the test will produce false positives.

Equally important, the RFC5322.From address has no necessary connection to
an actual mail server, since the From address can be used exclusively for
messages sent by an EMail Service Provider (ESP) using the ESP's identity
for the RFC5321.MailFrom? address. Consequently, the relevance of the
MX/A/AAAA test for distinguishing between SP and NP is lacking.

In sum, the test will produce both false positives and false negatives,
making its value doubtful, and it has at best a tenuous connection to the
way that RFC5322.From addresses are actually used.

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 6 May 2021 23:32:21 +0100

On 05/05/2021 12:28, Douglas Foster wrote:
> Non-delivery reports are officially discouraged

RFC 5321 Section 6.2 says the reverse.

-- 
Cheers,
   Jeremy

---

From: Douglas Foster <[email-masked]>
Date: Thu, 6 May 2021 19:19:22 -0400

I was referring to this section of RFC 7208, which I have interpreted as a
replacement for the older language of RFC 5321.
Perhaps I overgeneralized, and it is acceptable/desirable to send NDRs if
the system is confident that the return-path target is not forged.
My perception has been that NDRs are widely ignored even when they are
sent.  Is your experience different?

Doug Foster

2.5 <https://tools.ietf.org/html/rfc7208#section-2.5>.  Location of Checks

   The authorization check SHOULD be performed during the processing of
   the SMTP transaction that receives the mail.  This reduces the
   complexity of determining the correct IP address to use as an input
   to check_host() and allows errors to be returned directly to the
   sending MTA by way of SMTP replies.  Appendix D of [RFC7001]
<https://tools.ietf.org/html/rfc7001#appendix-D> provides
   a more thorough discussion of this topic.

   The authorization check is performed during the SMTP transaction at
   the time of the MAIL command, and uses the MAIL FROM value and the
   client IP address.  Performing the check at later times or with other
   input can cause problems such as the following:

   o  It might be difficult to accurately extract the required
      information from potentially deceptive headers.

   o  Legitimate email might fail the authorization check because the
      sender's policy has since changed.

   Generating non-delivery notifications to forged identities that have
   failed the authorization check often constitutes backscatter, i.e.,
   nuisance rejection notices that are not actionable.  Operators are
   strongly advised to avoid such practices.  Section 2 of [RFC3834]
<https://tools.ietf.org/html/rfc3834#section-2>
   describes backscatter and the problems it causes.

On Thu, May 6, 2021 at 6:32 PM Jeremy Harris <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Douglas Foster <[email-masked]>
Date: Thu, 6 May 2021 20:02:25 -0400

I have begun data collection on the effectiveness of the MX and A tests.
 Wildcard DNS entries increase the frequency of false positives and reduce
the usability of the test.   For example, "msaqq189.ford.com" returns a set
of MX results, but I rather doubt that I made a lucky guess and found a
mail domain that Ford Motor actually uses.

---

From: Hector Santos <[email-masked]>
Date: Thu, 06 May 2021 21:15:02 -0400

On 5/6/2021 8:02 PM, Douglas Foster wrote:
> I have begun data collection on the effectiveness of the MX and A 
> tests.   Wildcard DNS entries increase the frequency of false 
> positives and reduce the usability of the test.   For example, 
> "msaqq189.ford.com <http://msaqq189.ford.com>" returns a set of MX 
> results, but I rather doubt that I made a lucky guess and found a 

You are adding an human element to this that doesn't exist.

At best, all you can do is enforce the protocol requirements, the MUST 
semantics for sure, the SHOULD, most of the time (it is not a MUST) 
and the possible MAYS.   You have to be ready for all that independent 
of reputation.

The beauty of the DKIM Policy-based Model that began with DomainKeys, 
extended with DKIM which included SSP, reduced to ADSP when splitting 
SSP from DKIM-BASE, then abandoned and now DMARC which brought it back 
to life by adding Reporting, is the DOMAIN now giving the world a hint 
about its operations.

DMARC is very limited to three policies: reject, quarantine & none.

Reject and Quarantine is equivalent to an exclusive, restrictive 
policy which gives SMTP transport rejection authorization. Otherwise, 
you did nothing with a "none" policy.

There are the protocol rules.  The restrictive policies has alignment 
rules and there are procedures to getting to these results, like 
lookup DNS requirements.

Independent of DMARC,  MX is a SHOULD for a domain, you can still send 
mail to a domain that does not have MX records.   AAAA is obviously a 
SHOULD because not everyone is TCP6 ready.  Everyone is not going to 
have a DMARC record, nor a DKIM record.  SSP, ADSP and now DMARC are 
the only way to get a DOMAIN policy above and beyond standard SMTP.  
SPF is also an extension to SMTP with its own independent requirements 
that DMARC MUST match.

So whats the easiest for a domain not to have any trouble with any of 
this?

Don't support it.  Don't pretend to support it.  Just ignore SPF, DKIM 
and its add-ons.

SMTP Receivers are not at a point where we can enforce what may not 
exist - a domain policy extractable at two points:

SMTP.MAIL FROM:  for SPF
SMTP.DATA.FROM: for DMARC

I have proposed that we exploit the SUBMITTER protocol and optimized 
this high overhead protocol, by passing the 5322.FROM field to the 
MAIL FROM: line

MAIL FROM:<return-path>  submitter=5322.from

Now SMTP has the ability to check for the DMARC policy to see how 
strong SPF SHOULD be and if its fails or not.

This will allow for the short circuiting and optimization of MAIL data 
I/O which today is increasingly getting larger with multi-media data 
transfer.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: "John Levine" <[email-masked]>
Date: 6 May 2021 21:45:06 -0400

>sent.  Is your experience different?

Yes.  We are not going to rewrite RFC 5321 here.  Please stop.

R's,
John

---

From: Seth Blank <[email-masked]>
Date: Thu, 6 May 2021 18:52:29 -0700

> Yes.  We are not going to rewrite RFC 5321 here.  Please stop.

Doug, I don’t understand what textual consideration within the DMARCbis
documents you are discussing.

Please reference the text in question and your proposed modifications, or
move on to a topic which is material to driving this bis documents to
completion, which is our current work item.

Seth, as Chair
-- 

*Seth Blank* | VP, Product
*e:* [email-masked]
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Douglas Foster <[email-masked]>
Date: Thu, 6 May 2021 23:13:22 -0400

This is about
Section 3.8. Non-existent Domains

   For DMARC purposes, a non-existent domain is 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 [RFC8020].

My argument is that that A/AAAA/MX has no useful relevance to
determining whether the RFC5322.FROM address of a message should be
evaluated based on SP or NP.  NP is described as testing
"non-existent", rather than "possibly able to receive mail".   We need
a test that evaluates whether the domain exists or not, and is
maximally protected from false positives caused by host names and
wildcards.

If this group is convinced that A/AAAA/MX is meaningful for the
distinction between SP and NP, I am asking someone to provide the
justification and define the algorithm.  Right now I have seen
neither.

---

From: Todd Herr <[email-masked]>
Date: Fri, 7 May 2021 10:54:50 -0400

On Thu, May 6, 2021 at 11:13 PM Douglas Foster <
[email-masked]> wrote:

> My argument is that that A/AAAA/MX has no useful relevance to determining whether the RFC5322.FROM address of a message should be evaluated based on SP or NP.  NP is described as testing "non-existent", rather than "possibly able to receive mail".   We need a test that evaluates whether the domain exists or not, and is maximally protected from false positives caused by host names and wildcards.
>
> If this group is convinced that A/AAAA/MX is meaningful for the distinction between SP and NP, I am asking someone to provide the justification and define the algorithm.  Right now I have seen neither.
>
>
>
For what it's worth, the text in question was copied directly from
draft-ietf-dmarc-psd
<https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/>  (Section 2.7 of
that document, to be precise). As I understand it, draft-ietf-dmarc-psd
imposes some requirements on the text in DMARCbis, and so to support
satisfying those requirements, other bits of text were imported, too.
-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*m:* 703.220.4153

---

From: Douglas Foster <[email-masked]>
Date: Fri, 7 May 2021 12:05:36 -0400

I objected vigorously during the PSD review, but the Area Director directed
me to defer the discussion so the experiment could move forward.

Nonetheless, repeating inadequate language does not render it adequate.

Separating NP from SP should enable a significant improvement in threat
management if we can get the test right.  Unfortunately, a test that is
prone to both false positives and false negatives does not serve the
purpose well, especially if those problems are swept under the rug rather
than being articulated.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 May 2021 12:06:16 -0700

On Thu, May 6, 2021 at 5:02 PM Douglas Foster <
[email-masked]> wrote:

> the usability of the test.   For example, "msaqq189.ford.com" returns a
> set of MX results, but I rather doubt that I made a lucky guess and found a

There's no need to guess.  You can query for wildcard records:

$ host -t mx '*.ford.com'
*.ford.com mail is handled by 10 cluster4.us.messagelabs.com.
*.ford.com mail is handled by 20 cluster4a.us.messagelabs.com.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 May 2021 12:09:51 -0700

On Fri, May 7, 2021 at 9:06 AM Douglas Foster <
[email-masked]> wrote:

> I objected vigorously during the PSD review, but the Area Director
> directed me to defer the discussion so the experiment could move forward.
>

Can you please cite what I said to give you this impression?  I don't
remember saying anything that rose to the level of "directed".

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Fri, 7 May 2021 16:02:45 -0400

Here are the tests that I am looking to define:

*The existence / non-existence test:*
Given an identifier which is presumed to be a DNS domain name, perfrom a
DNS lookup based on that name.
The query may:
- return results using data from the identifier domain
- return results using data from a parent domain
- return NXDOMAIN

If the result is definitely from the identifier domain, the domain name
exists
If the result is NXDOMAIN, the domain does not exists
If the result is from the parent domain, the results are uncertain.

Is there a query or collection of queries that can ensure that we only
accept results from the identifier domain and not from the parent?

*Wildcard DNS:*

Wildcard entries create intentional ambiguity.   How do we suggest that
wildcard results should be factored into the evaluation?

*The mail-enabled test:*

Once existence / non-existence is determined, is it desirable to test for
"mail enabled"?
If so, what role should parent-domain results play in answering this
question?
If "Mail Enabled" is relevant, why is the existence of an SPF policy
irrelevant?

If "mail enabled" is used, this creates implicit DNS configuration
requirements on the domain owner.  New requirements should be stated quite
explicitly.

---

From: "John Levine" <[email-masked]>
Date: 7 May 2021 17:12:55 -0400

>accept results from the identifier domain and not from the parent?

This is a meaningless question.  DNS queries ask about a specific name
and RRTYPE and you get back the answer for that name and RRTYPE.

>*Wildcard DNS:*
>
>Wildcard entries create intentional ambiguity.

That is simply false.  Wildcards are perfectly well defined.  I have
occasionally found wildcard MX records to be useful.

I have taken another look at ticket #111 and found that the questions
it asks misunderstand both the way that the DNS works and the way that
SMTP has used the DNS since RFC 1123 over 30 years ago.

Please close this ticket, there is nothing to fix.

R's,
John

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 7 May 2021 17:17:11 -0400

Folks that deploy wildcard MX usually have a reason.   It may not be a
reason that makes sense to others,
but there's usually a reason.

In those cases, np won't work.  We should perhaps spell that out in the
text a bit more clearly.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 May 2021 14:24:50 -0700

On Fri, May 7, 2021 at 1:03 PM Douglas Foster <
[email-masked]> wrote:

> [...]

Can you give an example?  Otherwise I don't know what distinction you're
trying to make.

> accept results from the identifier domain and not from the parent?

I don't understand.  In the "answer" portion of a DNS record, you either
get what you asked for (or something matching it like a wildcard), or you
don't.  Anything else you might get is "glue" data, which as I recall is
easy to identify and exclude.

> wildcard results should be factored into the evaluation?

You can't, as far as I know.  That's the nature of wildcard records.

*The mail-enabled test:*
> Once existence / non-existence is determined, is it desirable to test for

It may be, but it's historically an expensive test with false negatives, as
far as I recall from my time working on mailing list software.  Those sorts
of probes get you into block lists if you do them a lot.

> If "Mail Enabled" is relevant, why is the existence of an SPF policy

I don't understand the purpose of the latter question.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 May 2021 14:31:35 -0700

> sent.  Is your experience different?

I interpret the cited RFC 7208 text to mean: "If you do SPF checking, then
don't generate an NDR to an address that has failed the SPF test."  It
doesn't supersede the more general guidance of RFC 5321, to which SPF is
basically an add-on.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 May 2021 14:43:10 -0700

On Thu, May 6, 2021 at 8:14 PM Douglas Foster <
[email-masked]> wrote:

> My argument is that that A/AAAA/MX has no useful relevance to determining
> whether the RFC5322.FROM address of a message should be evaluated based on
> SP or NP. NP is described as testing "non-existent", rather than "possibly
> able to receive mail". We need a test that evaluates whether the domain
> exists or not, and is maximally protected from false positives caused by
> host names and wildcards.
>
I continue to be unclear on why you think that test suite against a name is
inadequate.  Can you demonstrate a live case of a false positive or false
negative?  Perhaps an actual example will help to move this from the
abstract to the concrete.

In the meantime, here's what I think is the justification: If you try to
send me mail apparently from a domain that appears to have no email-related
presence in the DNS, that strikes me as a reasonable situation in which to
bounce such a message, and accordingly, a viable test for DMARC to use.
It's also relatively cheap, given that the DNS is a globally distributed
highly resilient database specifically built to answer such questions.  An
"email-related presence" is the three RRTYPEs that SMTP specifically uses
in trying to make use of a reverse path, and since this is an email
application, that also strikes me as reasonable.

You could (and some have) go one step further and attempt to make a
connection to whatever address that test resolved, on port 25, and see if
something answers.  You could go even further and try to interact via SMTP
with the server you find there, and test to see if the RFC5322.From address
responds 250 to RCPT.  But those are far more heavyweight tests, which can
add substantial time to DMARC processing, and such tests can get you
blocked from further interaction with those sites as they look like
address  harvesting probes.

Wildcards are a fact of life.  We will make no progress asserting that
everyone has to stop using them because they muddy DMARC's waters.  DMARC
could confirm on getting a positive MX reply that there is (or is not) a
wildcard MX in play, but I don't know how you would use that information
because the answer is the same both for "real" names and "fake" ones.  Is
this the basis for your position that the triple query done today is
inadequate?

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Fri, 7 May 2021 22:52:46 -0400

Murray, thank you for attempting to answer the question.

My problem with MX/A/AAA is that it IS a "mail enabled" test, which is
exactly the concept that you rejected in a recent previous post.   It is
also an SMTP-dependent test.  Since SMTP addressing is independent of
Message addressing, it is a poor fit at best for distinguishing between NP
and SP.

NP and SP do provide us with the opportunity to begin distinguishing
between two classes of threats.    Explaining the two classes requires a
longer post than I can provide right now.  Time for bed, and tomorrow is a
busy day for me.

On Fri, May 7, 2021 at 5:43 PM Murray S. Kucherawy <[email-masked]>
wrote:

> I continue to be unclear on why you think that test suite against a name
> is inadequate.  Can you demonstrate a live case of a false positive or
> false negative?  Perhaps an actual example will help to move this from the

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 May 2021 20:43:52 -0700

On Fri, May 7, 2021 at 7:53 PM Douglas Foster <
[email-masked]> wrote:

> exactly the concept that you rejected in a recent previous post.
>

I don't know how to answer that, since I don't know what "mail enabled"
means.

It is also an SMTP-dependent test.  Since SMTP addressing is independent of
> Message addressing, it is a poor fit at best for distinguishing between NP

I don't know what those middle two terms mean either.

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Sat, 8 May 2021 15:46:39 -0400

Justification and Implementation of the NP Policy

The NP Policy is used to hinder attacks of type “Invention”, as defined
below:

·         *Impersonation* attacks utilize an existing subdomain of the
parent.  The domain owner can hinder impersonation attacks using DMARC and
SPF policies published on the subdomain, as well as with the SP clause of
the parent domain’s DMARC policy.   The number of existing subdomains is
finite, although it may be a large number in some cases.

·         *Invention* attacks utilize a non-existent subdomain of the
parent.   Therefore, no SPF or DMARC policy is available on the
subdomain.   The domain owner can hinder impersonation attacks by
converting them to existing domains, or by publishing a parent domain DMARC
policy with SP>none (in the current specification) or NP>none (in the
proposed specification.)    The number of non-existent subdomains is
essentially infinite, limited only by the available character set, the
64-character length of a segment, and the 255-character limit of a full
domain.

Most recipient systems operate on a default-open basis, meaning that
messages which have no negative indicators are allowed through.   Attackers
using false identity will choose a parent domain with a favorable
reputation, so that the parent domain will be unlikely to cause a message
to be blocked.

However, recipient systems will also learn from messages received, so the
feasibility of false-identity attacks will diminish with repeated use of
any single identity.    Since invention attacks draw from an essentially
infinite pool of possible identifiers, the possibility of an
invention-based attacks is of significant concern to the recipient.

When a DMARC policy uses SP>none, both impersonation and invention attack
types are hindered.   However, operational reports indicate that SP>none is
often the last step in a long DMARC implementation process.   Without an NP
policy, invention attacks remain viable as long as SP=none.

The new NP policy reverses this process.   Once all subdomains are
considered to exist in DNS, the organization policy can be set to NP>none,
hindering invention attacks.    Since unused domains have no users,
organizational resistance to setting NP=reject should be minimal.
 Hindering invention attacks can now become one of the first steps in the
DMARC rollout process, rather than one of the last.
Test Design Considerations One-sided error curve

When designing a non-existent test, the test needs to have a one-sided
error curve.  The test must be trusted to produce no false classifications
of existing domains as non-existent, because such errors will lead to an
abandonment of the test and a return to infinite possibilities.
Operators should be able to accept a test which sometimes accepts a
non-existent domain as existent, because such events can be handled by
exception as needed.
Ambiguous Results – the A/AAAA query type

The A and AAAA tests are examples of an ambiguous test.   When a result is
returned, the result could be one of two things:

1.       The first segment represents a host record in a parent domain
<hostname>.parentdomain, or

2.       The first segment represents a null host name so that the host
name is the domain name
<null host><subdomain>.parentdomain

When the goal is to determine whether a specific identifier represents a
DNS domain, the A record must be coupled with another test to resolve the
ambiguity.
Ambiguous Results - Wildcards

Wildcards are another source of ambiguity.  If a query for
“subdomain.parentdomain” returns a result, it may be appropriate to requery
using “*.parentdomain”.  If the wildcard does not exist, then the subdomain
is confirmed to exist.  If a wildcard is confirmed, then the results are
ambiguous and disposition must be made based on the unresolved ambiguity.
Testing for non-existence:  The TXT test

One way to test for non-existent domain is to type for type=TXT,
query=domainname.   If the query returns NXDOMAIN, non-existence is fully
confirmed.   If the test returns NODATA or result data, then the domain is
tentatively confirmed to exist.    A wildcard test is recommended to
determine whether existence is fully confirmed (no wildcard) or ambiguous
(wildcard detected.)

The elegance of this test is that it is simple and lightweight, requiring
at most 2 DNS lookups.   Result possibilities are:

·         NXDOMAIN – domain does not exist

·         Confirmed – domain existence is confirmed without wildcard

·         Ambiguous – domain existence is confirmed with wildcard.

·         TempError – any DNS error, including DNS SEC failures that cause
server error.
Testing for non-existence:  The Mail Enabled Test

An alternative test examines DNS for the presence of MX, A/AAAA, and
possibly SPF records.  If any of these are found, the domain is assumed to
exist, and if none are found, the domain is assumed to not exist.    This
test is based on the assumption that any domain used in a FROM domain must
also have a server infrastructure for receiving messages to that domain.
Consequently, the validity of this test depends on the validity of that
assumption.

Because the Mail Enabled test involves specific content, the level of
content checking will affect the results.   Since RFC 7505 documents a way
to use MX records to indicate non-mail status, results should at minimum be
tested for this condition.    More thorough testing would verify that each
host name resolves to an IP address, and that returned IP addresses are, or
at least include, routable addresses.

Because this test involves substantially more DNS queries, it is more
susceptible to TempError results.

Possible test results include:

·         Confirmed – one of the required queries returned acceptable
results

·         Non-Existent – all queries returned NXDomain, NoData, or a
RFC7505-compliant non-mail MX record.

·         PermError – one or more queries returned non-resolvable host
names, or host names that resolved to non-routable IP addresses

·         TempError – any other DNS error, including DNS SEC failures that
cause server error.
The Edge Case – Requirements on Domain Owners

Assume that the marketing department wants to send messages from a new
subdomain, with address [email-masked], using a third-party
mailing service.   The domain will not be used for any other purpose and
does not require a server infrastructure at this time.

Requirements to satisfy the TXT test:
Before using the new subdomain in a FROM address, the subdomain must be
registered in DNS.   No assumptions are imposed about DNS content.

Requirements to satisfy the Mail Enabled:
Before using the new subdomain in a FROM address, the subdomain must either
have an actual mail infrastructure implemented and published in DNS, or at
least a placeholder set of DNS entries which create the appearance that an
actual mail infrastructure exists.   However, the use of placeholder data
may have unpredictable effects on subdomain reputation.

---

From: Douglas Foster <[email-masked]>
Date: Tue, 18 May 2021 01:18:56 -0400

Fatal flaws with the MX/A/AAAA test

   - During DMARC policy evaluation, the process may have retrieved an SPF
   policy or a DKIM public key which is associated with the RFC5322.From
   domain or one of its descendants, even though the SPF test did not pass and
   any relevant DKIM tests did not verify.   Obtaining such data provides
   evidence that the domain name is in use by the domain owner and therefore
   the failure should be handled as SP rather than NP.   But adding this
   condition into the evaluation means that the evaluation is no longer
   deterministic, since the pool of supplementary information can vary from
   one message to the next..
   - If the RFC5321.MailFrom domain is a parent of, or unrelated to, the
   RFC5322.From domain,. then the DMARC evaluation will not have checked for
   an SPF policy on the From domain.   The presence of an SPF policy indicates
   that the domain does exist and that the domain owner has implemented this
   sender authentication mechanism.    If SPF is present, the policy
   evaluation should be SP, not NP, but the SPF policy is not considered by
   the MX/A/AAAA rule.

Problematic ambiguity, depending on the presumed justification for the
MX/A/AAAA test

   - Both MX and SPF can be used to allow or block traffic.   MX can block
   message delivery using a host name of "." (RFC 7505) or any other invalid
   or non-routable name.   SPF can be used to block traffic if the policy is
   "-ALL".   If the selection of MX is intended to score the domain for a
   probability that it is used for email, then the block signals should be
   considered as indicators of NP, and the non-blocking signals should be
   considered as SP.   But then what to do if the signals are not in the same
   direction?

Constraints imposed by DNS

DNS Queries for a specific RR type produce one of three results

   - Data:  An entry matches the requested name, exactly or by wildcard,
   and also matches the requested RR type.
   - NoData:   An entry matches the requested name, exactly or by wildcard,
   but the requested RR type cannot be matched
   - NXDomain:  No entry exists for the name, either exactly or wildcard,
   for any RR type.

When multiple query types are checked for the same domain name, the
multiple three-way results must be consolidated into a single binary
conclusion: SP or NP.    That conclusion will be heavily influenced by
assumptions about how domain administrators will configure their domains,
and such assumptions are difficult to apply globally.

The one exception to this problem is the NS query.   It acts as a query for
type=ANY with the specific results discarded.   As a result, it has only
two outcomes:

   - Data:  The name is used in DNS (policy applied = SP)
   - NXDomain:  The name is not used in DNS.(policy used = NP)

This query has no dependencies on other mail message attributes, so it is
deterministic.
It directly addresses the stated question:   "Has the domain administrator
configured this name into DNS, and therefor has been given the opportunity
to implement sender authentication controls?"
It does not attempt to guess whether the domain configuration indicates
mail system participation or not.
If eliminates the possible need to evaluate specific RR types for allow or
block signals.
It is simple to define and simple to implement.

Doug Foster

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 17 May 2021 23:19:09 -0700

On Mon, May 17, 2021 at 10:19 PM Douglas Foster <
[email-masked]> wrote:

>    - During DMARC policy evaluation, the process may have retrieved an
>    SPF policy or a DKIM public key which is associated with the RFC5322.From
In what way does the SPF and DKIM information fetched for one message taint
the resolution of the message coming after it from the same domain?

> The same is true for an unaligned DKIM signature.

To me, this just means trying to piggyback the MX/A/AAAA semantics off of
the presence of DKIM and SPF results is fallible.

> MX/A/AAAA test
>
>    - Both MX and SPF can be used to allow or block traffic.   MX can
>    block message delivery using a host name of "." (RFC 7505) or any other
>    invalid or non-routable name.   SPF can be used to block traffic if the
>    policy is "-ALL".   If the selection of MX is intended to score the domain
>    for a probability that it is used for email, then the block signals should
>    be considered as indicators of NP, and the non-blocking signals should be
> I don't follow this at all.  A "." MX is an indication that the domain
exists but wishes to publish that it offers no way to receive mail.  It
might send perfectly legitimate and possibly even desirable email.  An SPF
"-all" is an indication that the sender handles all of its own mail (or at
least thinks it does).  It, too, might send perfectly legitimate and
possibly even desirable mail.  Neither of those strike me as equivalent to
"this domain doesn't exist for the purposes of email".

>    -
>    - NoData:   An entry matches the requested name, exactly or by
>    wildcard, but the requested RR type cannot be matched

DMARC is clear about this, in my opinion: RFC 7489, Appendix A.4, says
NXDOMAIN and NODATA are equivalent because in both cases "no such records
were published".  If you're arguing that this definition is hurting DMARC's
efficacy, I'd love to see some data.

> Interesting.  Are there any data to suggest this is more effective or
accurate than the MX/A/AAAA test?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 18 May 2021 12:28:16 -0400

It appears that Murray S. Kucherawy  <[email-masked]> said:
>-=-=-=-=-=-
> [ various things ]

I have reread this ticket and found nothing actionable, and a lot of misconceptions aboout how the DNS works.

There is nothing to fix.  We can close it now.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Wed, 19 May 2021 07:18:01 -0400

Then please explain yourself, John.

---

From: Douglas Foster <[email-masked]>
Date: Wed, 19 May 2021 10:43:31 -0400

It all depends on what problem this is trying to solve, Murray.

"Name exists", as defined by NS data/nxdomain, provides a clear and simple
boundary between names that are in use and names that are not in use.
This is based on the principle that when a name is created in DNS, the
domain administrator has the opportunity to protect it with SPF and DMARC
policies if desired.   A name that has never been used for any purpose
cannot be protected, except with SP=reject, because all other defenses make
the name used, and the scope of possible names is infinite.   The purpose
of the NP test is to allow domain owners to deploy NP=reject early in the
DMARC process, long before they are willing to deploy SP=reject.

I do not see that MX/A/AAA creates a useful and well-defined boundary
between two risk categories, which is why I asked for a justification from
someone who did understand the theoretical foundation.   What I hear is
that nobody knows with any certainty how this test relates to a real-world
boundary problem.

As best I can tell, thd MX/A/AAAA test is creating and attempting to
enforce a rule that "any mail domain used in a FROM address must also have
a physical server for receiving messages to that mail domain."   I do not
see that such a requirement is either necessary or appropriate, and I do
not believe that it will be true that 100% of all legitimate messages will
meet this requirement.

As for filtering characteristics of the two tests:

   - If MX/A/AAAA produces pass and SP, then the NS test will also produce
   pass and SP.

   - If NS produces fail and NP, then the MX/A/AAA test will also produce
   fail and NP

   - There is a bunch of stuff in the middle where NS produces a pass
   because the name is used, but MX/A/AAA produces fail because the required
   types of RR types are not used.    If the middle area could be scored
   reliably, it would exclude some additional threat vectors, but I don't see
   reliability.   The A/AAAA test is so broad that it will allow many names
   that are not actually mail servers, allowing the attempted enforcement to
   be easily defeated.    I expect it will also produce false positives, as
   the volume of no-reply messages from ESPs is large, and such messages
   simply do not need an MX for the FROM domain.   As I tried to observe in
   the previous note, the MX/A/AAAA test could score "host1.div1.example.com"
   as exists/SP, but "div1.example.com" as does-not-exist/NP.    I just
   don't see any value in that level of scrutiny.

In short, MX/A/AAA involves more complexity for less usable results.  That
is a big double negative for me.

We have no data submitted on either test rule, so it is not yet a
distinguishing characteristic.   I think I can build filters to
begin collecting that data, but my data set is relatively small.

Doug Foster

On Tue, May 18, 2021 at 2:19 AM Murray S. Kucherawy <[email-masked]>
wrote:

> In what way does the SPF and DKIM information fetched for one message
> taint the resolution of the message coming after it from the same domain?
>
>
>>
>>    - NXDomain:  No entry exists for the name, either exactly or
>>    wildcard, for any RR type.
>>
> The one exception to this problem is the NS query.   It acts as a query
>> for type=ANY with the specific results discarded.   As a result, it has
>> only two outcomes:
>>

---

From: Douglas Foster <[email-masked]>
Date: Sun, 23 May 2021 15:24:52 -0400

Murray, here is some data:   (I only receive IP4 data and my tool did not
check AAAA)

Sample size:
 3643 messages from 780 unique From domains
  611 domains (78%) passed validation using DMARC criteria  (DMARC policies
were not checked)

599 of 611 (98%) DMARC-verified domains also had MX or A records
12 DMARC-verified domains did not have MX or A records.  Of these 12:
- 8 had NS records and were judged legitimate,
- 2 lacked NS records but were judged legitimate
- 2 were judged spam but had NS records.

145 of 169 (86%) of non-verified domains had MX or A records,
Of the 24 without MX or A records, 23 were spam and 1 was legitimate
For 20 of the 24 , SPF on the From address returned NXDomain and were
obvious spam without checking NS
All of the remaining 4 domains had NS records

One surprise for me:
NS lookup on email3.reachmd.com returns NXDomain, but NS lookup on
sg.email3.reachmd.com returns NS data.
I thought that the existence of a subdomain would be sufficient for a
domain to return NS data.

Summary:
- MX/A produced 11 false positives
- NS lookup produced only 3 false positives
- For messages that originate with DMARC-compliance, false positives only
matter if the message path causes the DMARC-validation to be lost.
- The reachmd.com situation suggests that neither lookup can prevent all
false positives.

Doug Foster

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 25 May 2021 12:39:12 -0700

> All of the remaining 4 domains had NS records

I believe this means that for 2.4% of the non-verified domains, or 0.65% of
the total domains, the proposed NS check yielded useful signal beyond the
standard checking of MX/A/AAAA.

> domain to return NS data.

Right, it isn't.

> - MX/A produced 11 false positives

Is that 11 false positive messages, or 11 false positive unique domains?
If the former, we're talking about around 0.3%.  If the latter, we're
talking about 1.8%.

So based on the data you collected, what conclusion are you proposing?

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Tue, 25 May 2021 22:04:43 -0400

My expectations of what is feasible have collapsed greatly.  My numbers
were unique domains.

I was hoping that the boundary between existent and non-existent would
align along a natural boundary, and as a result would require little or no
effort for domain owners to ensure that their legitimate mail was in the
"existent" category.   If so, the NP=reject policy could be deployed
early.  Instead, it seems that ensuring "existence" becomes just another
burden on the DMARC implementation process, and N{=reject will be the final
step in the deploymnent process.

Because we do not have a natural boundary, we need to create a signalling
system to define the SP/NP boundary.  The signal must be purposefully
implemented by the domain owner, so any signalling system could be chosen.
MX/A/AAAA has an obvious advantage, because pre-existing compliance rates
are high.   But when MX/A/AAA records do not exist, they do not exist
because an ESP-based mail source does not need them.   Any invented
MX/A/AAA record will need an IP address, but the choice of IP address
becomes arbitrary and possibly problematic.   MX, A, AAAA, and SPF are all
used to communicate meaning into the SMTP context, so we may have
unexpected consequences from adding one of those records where they are not
needed.

Consequently, I think the search list should be MX/A/AAA/TXT.   The
TXT record content seems unimportant, and it could be as simple as
TXT="This Domain Exists".    The domain owner simply needs a way to provide
an "existent" signal without affecting other functions.  TXT seems like the
appropriate way to do this.

Doug Foster

On Tue, May 25, 2021 at 3:39 PM Murray S. Kucherawy <[email-masked]>
wrote:

> I believe this means that for 2.4% of the non-verified domains, or 0.65%
> of the total domains, the proposed NS check yielded useful signal beyond
> the standard checking of MX/A/AAAA.
>
> One surprise for me: