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

[Douglas Foster <[e-mail]>]

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



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

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