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

[Douglas Foster <[e-mail]>]

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 "host1.div1.example.com"
   as exists/SP, but "div1.example.com" 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 <[e-mail]>
wrote:

> On Mon, May 17, 2021 at 10:19 PM Douglas Foster <
> [e-mail]> 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
>