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

Douglas Foster <> Wed, 19 May 2021 14:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 593F03A1297 for <>; Wed, 19 May 2021 07:43:46 -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, RCVD_IN_DNSWL_BLOCKED=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 BZaET0OOpNNM for <>; Wed, 19 May 2021 07:43:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C946E3A128F for <>; Wed, 19 May 2021 07:43:43 -0700 (PDT)
Received: by with SMTP id 36-20020a9d0ba70000b02902e0a0a8fe36so11935318oth.8 for <>; Wed, 19 May 2021 07:43:43 -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=xVRN8aCC8cIubOQGLtEIVh28LIbqD7gZlZ34eQOLZ2Y=; b=ZDFGokhk/GXOYp1qRXQ2V9vZzOMxezhDV4fzMPD00gIt3eglX6HrxS4hM+uXZUw1zE sUCrlukdmWdGTxPzUlcxBhriYNemAUflnftB6IOyzb4lrDFKRSYOmPuF1YvMDEJKQbXh 1c9jT+rhULWSDH6gieBkOks3PpzhlKV9LOwG8yUdUFXEMiwWRJr8v1hIxjjHcEjcHeq7 2G6Es5fxg6G+1IDynqJM/AVZMHiXmFQaWleTju2QFzY1SMr+4XXu1ZPHkSbOPb/TuNpZ W6Q3kI0tAnULXVE58ibJkS6c3g4a6OCgHPkWUyjII6+CYQexyVgRt0tO/VIsy+e5yf/A 3s+Q==
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=xVRN8aCC8cIubOQGLtEIVh28LIbqD7gZlZ34eQOLZ2Y=; b=VfwPJMMIvy/SPLXGtgk3BLHnDZTIFBscZzkIr8RIRTJ4cc7vE+z6nW/tODDA4166gn fdxpOn92t1egG/d3qHWG0EHMMaiygoKPxayXmAUI8VRt62QHTyNdlTsCfT5uR9n4nxTy bSgIRjV2OEjkM9aPdu1vg0HBem4XbB66p4L+Hu9d98u6pHTHo4Ys1Wq3oIdi8Yfk1DZP qe3TQL9rKnX6rn1w+01ZyQ5FMObpUUjBSsq6tvHetl5xiAPHZIJGJOgpa7BdssX+5rQR 2DIilMzDrRtNJD9SXL2hm/pdfUsM8mBDuTYmB283aw8a7qcHW6yFnwdgDjaLlEqkz6+Z yefA==
X-Gm-Message-State: AOAM533G1mfNV6MBrFLKcO0BVfvMXRoofs7kjG5Hzlu40Ktrd9PTEj2d O5GyqG1YD/RCjKXJH+8cAdTYEHg4EkOYI0Crntg=
X-Google-Smtp-Source: ABdhPJzt+CgsscePJgyfPA+653rtdMx8yq9Zlbn9JtxXeBkXw81SBe3QBUviX7XDG4mIszoaUwN9KHC13rUeRmqBp7Q=
X-Received: by 2002:a9d:7348:: with SMTP id l8mr9660721otk.240.1621435422487; Wed, 19 May 2021 07:43:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210507014508.78064719D42@ary.qy> <> <> <> <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Wed, 19 May 2021 10:43:31 -0400
Message-ID: <>
To: "Murray S. Kucherawy" <>
Content-Type: multipart/alternative; boundary="0000000000006235f805c2afda83"
Archived-At: <>
Subject: Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification
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, 19 May 2021 14:43:46 -0000

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 ""
   as exists/SP, but "" 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 <>

> On Mon, May 17, 2021 at 10:19 PM Douglas Foster <
>> wrote:
>> 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..
> 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?
>>    - 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.
>> 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.
> 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?
>> 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".
>>    -
>> 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.
> 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.
> 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)
>> Interesting.  Are there any data to suggest this is more effective or
> accurate than the MX/A/AAAA test?
> -MSK