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

Douglas Foster <> Sat, 08 May 2021 02:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB2193A2F20 for <>; Fri, 7 May 2021 19:53:00 -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 8Dm7BkjtbPiw for <>; Fri, 7 May 2021 19:52:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AD2D3A2F1A for <>; Fri, 7 May 2021 19:52:58 -0700 (PDT)
Received: by with SMTP id m13so10507988oiw.13 for <>; Fri, 07 May 2021 19:52:58 -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; bh=5ohAb+hTQsyKUuDsRl4gq9XM4HgNuqMfIZ184iAV4Zo=; b=VuEnWVQ3q523zWPpbuuo3qNSKUOOJ60NkVyJmYrghXCqIrIL1QKiXzh5SswXNcXwUw 4TXdMth/omUiXI0ZmVmxJJrfUxRirlvh+7Y4npLS+yW6zBcBOyOwbO3baW8axXKaYdRy SRjxU/n3GP9K05YfUtKu4iipu0gz1UwM3ii5/EJX7Tx+DwG7uSnALY9O2rmw9AYuyHEL +mO4n4vEzP+fhMblbY0YTXMtvwsFvsaxPAd2w0Hk417I0QpPHSwoIw3rOkSru65PPe2t p48R38fO6iFFN1Dn2HKBF0Cufqvd456EOISTUa3xhc6lINshoI1GdI848/6bBNoFjEZn Xs1w==
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; bh=5ohAb+hTQsyKUuDsRl4gq9XM4HgNuqMfIZ184iAV4Zo=; b=XN6HbGWY6ZG7ogGorifrd9S/x5qRVDL0dnVUWBjwpgTlV9+ZQrsujvO7tfbkAcJFBL 1kJbuc1KSHCo+tUTA2Krcg76PaiiDx7mJpf3Gspn29PxsmRE4ZmhlBaKOfmO7+LG2EOh XOc+vnCnPpcph7gUmv9srk2zKbdSuvckAIDiZ9XAUNJAr3R/oEX0HD6RQT8PprdXVn+g cUM1ZhE7Xmy5lFOI8BAXIRE3cmKOrIpIL64SLGrh1l0E4NSukMLM7GyaqYTjzvTJQxuY EY+l1fiuR0bJ/IeTa7oPlDcgOgcZpDtdIMcHwbTAY7gzu5PvuXYJChEbieRJNomFCEUh TjXg==
X-Gm-Message-State: AOAM531OKbzGV8mr1dhQWxmBqqE6aAupfISez1CojETnSmdpDEZ4AEMr KLe0/idj/GrNkrUi6wuHrUT405RUnpg2yKLZw3PtVAVn
X-Google-Smtp-Source: ABdhPJzCflEHOrQBjZVFZ/XmswOAtj9oYv8xSxYawWfvErgI6GhBHk08yWe2+whMp0UT9Z6opl+QcXfOQCg/9hsWMqc=
X-Received: by 2002:aca:5856:: with SMTP id m83mr17045275oib.20.1620442376785; Fri, 07 May 2021 19:52:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210507014508.78064719D42@ary.qy> <> <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Fri, 7 May 2021 22:52:46 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000003f530b05c1c8a4f9"
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: Sat, 08 May 2021 02:53:01 -0000

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 <>

> 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
> inadequate?
> -MSK