Re: [dmarc-ietf] NXDOMAIN

[Douglas Foster <[e-mail]>]

NXDOMAIN and Return-Path-Check are two different ways of identifying
non-existent domains.    I believe NXDOMAIN to be the better one, but since
the group seemed to be in love with return-path-check, I was willing to go
there.    Whichever one could solve the problem best, the issue for us is
that the problem has not been solved.

Prior to PSD for DMARC, the IETF role in sender authentication could be
summarized as follows:

"An attacker may seek to hide his own reputation and acquire a better one
by impersonating another domain.  This is of interest to IETF and has been
addressed by the specifications for SPF and DMARC.  An attacker may also
seek to hide his own reputation and acquire a neutral one by impersonating
a non-existent domain.   This is of no interest to IETF.;"

This dichotomy is hard to defend.   It has been made worse by embracing PSD
for DMARC.   The statement must now be revised to say:

"IETF is interested in attacks of the form
'otherdomain.nonexistentdomain.psd', but IETF is not interested in attacks
of the form 'nonexistentdomain.otherdomain.psd'.

Todd's comments suggest that the whole issue of non-existent domains is a
non-problem because everybody who matters is already well protected from
non-existent domains, because they have implemented non-IETF tests such as
return-path-check.    If this were true, attackers would move on to other
strategies and PSD for DMARC would have no advocates.

When we start using ARC to accept results which cannot be independently
tested, we need to know what tests were peformed.   Since address rewrite
can eliminate the ability to reproduce earlier tests for NXDOMAIN or
Return-Path, it must be part of the ARC results.  The success of ARC
depends on having this information included, and the success of "new" DMARC
has been tied to ARC.

Non-existent domain usage is not a minor issue and not an issue that is
already solved.   It is the elephant in the room, and it needs to be
addressed.

Doug


On Thu, Apr 8, 2021 at 1:06 AM Murray S. Kucherawy <[e-mail]>
wrote:

> Further to what Todd said:
>
> On Wed, Apr 7, 2021 at 5:04 AM Douglas Foster <
> [e-mail]> wrote:
>
>> I am hearing that we have a defacto standard to check return-path using
>> MX/A/AAAA.  It is implemented with sufficient breadth,that (unlike SPF)
>> senders should consider it mandatory.    Additionally, and more importantly
>> for this group, it is presumed to be equally applicable for validation of
>> the RFC5322.From, even though that address is unrelated to the
>> SMTP return-path.  But because the test is not explicitly documented, some
>> products (my vendors) do not implement it at all, leaving a protection gap.
>>
>
> I think I'm confused about how this ties to DMARC.  What you're describing
> is, I believe, a common anti-spam tactic that was in use even before SPF or
> DKIM were a thing.  It probably still is, irrespective of those protocols.
>
> However, RFC 7489's Appendix A.4 points out that earlier versions of DMARC
> had such a test, but it was removed because of too many false negatives.
>
>
>> If DMARC is to be dependent on return-path-check and inter-dependent with
>> ARC, then I do not see how we can avoid producing a formal specification
>> for the test and integrating it into A-R, as a co-requisite to the DMARC
>> specification.
>>
>
> How is DMARC dependent on a return path check?  SPF is, but DMARC isn't.
> DMARC only cares what the SPF result was, and whether the domain it
> evaluated is aligned with the RFC5322.From domain.  In fact, a DMARC filter
> could operate correctly with no knowledge of what the return path was,
> provided the A-R fields are correct and complete.
>
> Another perspective: If the RFC5322.From domain doesn't exist, it's not
> possible for a DMARC policy to be discovered for it, nor is it possible
> that SPF or DKIM will pass for it or align to it.  Therefore, is such a
> domain even in scope here, much less a need to describe a way to test it?
>
> -MSK
>