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

"Murray S. Kucherawy" <> Tue, 18 May 2021 06:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CC5D3A045E for <>; Mon, 17 May 2021 23:19:24 -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 7sno9zGkP6yj for <>; Mon, 17 May 2021 23:19:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF8203A048D for <>; Mon, 17 May 2021 23:19:22 -0700 (PDT)
Received: by with SMTP id w3so1789642vkb.4 for <>; Mon, 17 May 2021 23:19:22 -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=3JkITQMujIyOTt6A3ZaIZC7dKdL0+1j1YPdlFUhE5e8=; b=fZaXJH1EjW3AERrC1FnxFFl/t0+fpQOMuuL1dGePweQZ84YNtcRk9kvA1ZjkUdcp9T 7FnImsjlDs3B2crtfsxkNZ4tQCOYwdrbZJJonHCNlENyN3+3sV7eo/lpVWJW+dIYZ3cu pMqnmuJeiAR7ckKJ3mNa7pB93BP3Rx++pBZ4GA7Cjy6JAPgsgONF4mb6gyPcfE5gVPRI cEEq/jfq+MWF/wEsVs1t6prKkn38KL2JuzVdHkWyXTH1AjEP3M2MaIw3CXgLuXGC8HiO fK3YP20he6bOb2QtNHthTWLYvtDzabaq94Ze19QCgT66pOGbzPr1a4JGUbVqeOX0ztZX mjTQ==
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=3JkITQMujIyOTt6A3ZaIZC7dKdL0+1j1YPdlFUhE5e8=; b=qCvUJwRyjyMAKZrU/zjlMClHRhddhOD1an0oBq3OYrCurNnfcaWYFID5qwtXdwL6qM /YUTf4Q8PQhbOaxfdib2G41dv51KTf5n+l9SMmN7+LtHzEOf1Mhma69Q1ShYC5jGRkgv z6qg5WzurSDdHFQ6aM2V9repVTk336MX3hmipALaLPJVNjctWi2Ja9/XHVGFSQnqwyL2 DfTW12iNaSJjv/9MGwSvxrcij5p6Q8RLc22qM01wKA49T0yuOw50xOtfTPr3n7E5Z6XL PpCJYzHDzVYG8rQQ7So+9NWfoIYLNiPlq9DGL4o9zsZPCSYBTvDTlUgzE2pbfJIiUDKM jq0g==
X-Gm-Message-State: AOAM532A3TOHQrNDJyqb2BvOGmO4puLa8eWXyqDBdHYBgibstRpGDgJi YYDcPYYH2G65I6BoLmwDNAmnnw06naVfzbdalne/zMVqZ6w=
X-Google-Smtp-Source: ABdhPJyIPqZY7Wx23iVcLi7WNu8jc7Tvp4PhavtLUmUz8HLa1CUKsxKf94tq5tGQEzezWE04EhWVyVXvr87ktL19HQ4=
X-Received: by 2002:a1f:2d92:: with SMTP id t140mr4358689vkt.13.1621318760999; Mon, 17 May 2021 23:19:20 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210507014508.78064719D42@ary.qy> <> <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Mon, 17 May 2021 23:19:09 -0700
Message-ID: <>
To: Douglas Foster <>
Content-Type: multipart/alternative; boundary="000000000000d1309905c294b0b7"
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: Tue, 18 May 2021 06:19:35 -0000

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?