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

"Murray S. Kucherawy" <> Fri, 07 May 2021 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F26933A345D for <>; Fri, 7 May 2021 14:43:26 -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 QC7TeXHo1slE for <>; Fri, 7 May 2021 14:43:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCF413A3455 for <>; Fri, 7 May 2021 14:43:23 -0700 (PDT)
Received: by with SMTP id h1so3292364uar.0 for <>; Fri, 07 May 2021 14:43:23 -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=velCqcxWbsSHamESLbkRwi4MOW9rmlHyMSqPRTCUCjs=; b=cxCqGdGW3bZUWyCnv+nAtLNO1X/rz48axBYSzs+eK5vB9mdbx4ud8VLCWlf8kY67Ja aoe+itCqfHF4hBwnObjQc9UtGEws4YEH7AxN1KqCcQ/7AMjRGOIHedP1c2wnEP1gDZZz NB6z69qwApWri8vaY+mOjpM8blQLex84F7sXsQVo97yhmWhYwUnSZS64K8IpV/HaI5qW Ap78/bcLn0KLPlP4T8VpF4lU4p1+idiSSZQiTAfCcfvQ4QAmAQqVsu0Wy81mg6e5eBuc mhG7LlSHo5Vi2iKykJCTnMtk0Cl8L22RNdLYvm7kd20tpDjRmzGx9QSerOIWRrPyZFb7 CFwg==
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=velCqcxWbsSHamESLbkRwi4MOW9rmlHyMSqPRTCUCjs=; b=kmuHb65DrcAt5wr1GUfhHrZTpFX6Vg9QQ/P3Gh/L3KDw86Hc05eb2dz657D27NwlOV ih5KVtMws7J+idcsLvUOUdbIi/d6LdIVsQhsFBTphZgae2yr6h2OzIzQg08KZ8zK6eQq s/k459aPNM4fiCDT5c1oiR5Wmw2x5QA7gbtBjkHIJ56vsGsOtTj/qw35BAAhVbkiIv3O eHnVYykol2T5ALZobkiacdcTNoG6rX6qwVKKz4LWAL8LJNbj3xNpMR4x0B7mnZ3sVEQX Z2fpZTMrgVIvdjK5vchNTYwku6GsLKpwvPEJqH6F+9P8QamOAQBO1L2+PPEXJgh1QM9j u9mw==
X-Gm-Message-State: AOAM531+48YLh/9M+rLkrgOYJtfnR5RDTlKOyJ7FxDpGxkWrperiUv7u HGeaEx+0ztbdQBMXboqmntKSrA2ixsEZD4hChiY=
X-Google-Smtp-Source: ABdhPJz6nFYoXXcjnWg8nQxxlS97uIPqVRO9KKkjl8NEVD6G750RIZUK97UIhJyCvDeKGLQL9JG2fC5YRaEUlzAgccY=
X-Received: by 2002:ab0:2441:: with SMTP id g1mr11571222uan.76.1620423802067; Fri, 07 May 2021 14:43:22 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210507014508.78064719D42@ary.qy> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Fri, 7 May 2021 14:43:10 -0700
Message-ID: <>
To: Douglas Foster <>
Content-Type: multipart/alternative; boundary="0000000000001b9ff605c1c4514e"
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: Fri, 07 May 2021 21:43:27 -0000

On Thu, May 6, 2021 at 8:14 PM Douglas Foster <> 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.
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