Subject: [dmarc-ietf] 3.2.6. Non-existent Domains

From: Scott Kitterman <[email-masked]>
Date: Sat, 04 Dec 2021 23:13:57 -0500

Should we modify the definition of non-existent domains so that a domain that 
only has an RFC 7505 null mx record is still considered non-existent?

I'll propose text if it's agreed this would be a useful change?

Scott K

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 4 Dec 2021 23:40:54 -0500

> I'll propose text if it's agreed this would be a useful change?
This is a useful addition.

3.2.6 also says:

This is a broader definition than that in [RFC8020].

But RFC8020 only defines "Denied name".  I suggest

This is a broader definition than what is defined as "Denied name" in
[RFC8020].

---

From: "John Levine" <[email-masked]>
Date: 5 Dec 2021 14:04:20 -0500

>only has an RFC 7505 null mx record is still considered non-existent?

How about if it has a null MX and a DMARC record or DKIM keys?  Remember that those
records are at different names than the MX.

This sounds like local policy again.  Personally, I am not crazy about
getting mail that I can't reply to, but my mailbox is full of mail from
my bank and stores from which I have ordered telling me that I can't reply
to their messages.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 05 Dec 2021 14:16:24 -0500

On Sunday, December 5, 2021 2:04:20 PM EST John Levine wrote:
> >Should we modify the definition of non-existent domains so that a domain
> >that only has an RFC 7505 null mx record is still considered non-existent?
> How about if it has a null MX and a DMARC record or DKIM keys?  Remember
> that those records are at different names than the MX.
> 

There's two ways we could go at this question:

1.  A domain that, except for the null mx, would fit the criteria for non-
existent.  This would be kind of weird, since mull mx only makes sense if you 
have an A/AAAA, but I wouldn't think existence of a null mx alone would be 
enough to make the domain 'exist'.

2.  A domain which has an A/AAAA and null mx.  Since it claims to be a no mail 
domain, we could treat it as not existing for DMARC purposes.  Since RFC 7505 
specifies null mx is for domains that don't accept mail, but is silent on 
sending mail, these should probably exist for DMARC purposes.

I think that your point is about #2 and I agree.  #1 is definitely a corner 
case, but if the only thing there is a null mx, I'd be quite comfortable 
saying it doesn't exist.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 5 Dec 2021 14:40:16 -0500

It appears that Scott Kitterman  <[email-masked]> said:
>> that those records are at different names than the MX. ...

It's about both.  What if a domain has a null MX and a DMARC record?  Maybe it
has an SPF record, too.

For your #2 you seem to be saying that if I send no-reply transactional mail,
my DNS would look like this:

notifiy.bigcorp.com. IN MX 0 .   /* we don't receive replies /*
   IN A 0.0.0.0                  /* make the domain exist */
_dmarc.notify.bigcorp.com. IN TXT "v=DMARC1; p=reject; ..." /* it's all aligned */
s._domainkey.notify.bigcorp.com. IN TXT "v=DKIM1; h=sha256; p=MIIBIjANB..." /* it's signed */

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 05 Dec 2021 15:22:08 -0500

On Sunday, December 5, 2021 2:40:16 PM EST John Levine wrote:
> >existent.  This would be kind of weird, since mull mx only makes sense if
> >you have an A/AAAA, but I wouldn't think existence of a null mx alone
> >would be enough to make the domain 'exist'.
> >
> >2.  A domain which has an A/AAAA and null mx.  Since it claims to be a no
> >mail domain, we could treat it as not existing for DMARC purposes.  Since
> >RFC 7505 specifies null mx is for domains that don't accept mail, but is
> >silent on sending mail, these should probably exist for DMARC purposes.
> >
> It's about both.  What if a domain has a null MX and a DMARC record?  Maybe
> it has an SPF record, too.
> 
> For your #2 you seem to be saying that if I send no-reply transactional
> mail, my DNS would look like this:
> 
> _dmarc.notify.bigcorp.com. IN TXT "v=DMARC1; p=reject; ..." /* it's all
> aligned */ s._domainkey.notify.bigcorp.com. IN TXT "v=DKIM1; h=sha256;
> p=MIIBIjANB..." /* it's signed */

In the current definition one of MX, A, or AAAA needs to return something other 
than NODATA or NXDOMAIN.

For #1, I'm not suggesting a change to the existence test based on TXT 
records, so you're correct from my POV.  A domain can (based on the RFC 9091 
definition that has been imported into the draft) already have an SPF record, a 
DKIM key record, and a DMARC record and "not exist".  I think extending that 
to maintain a state of non-existence when there is a null mx doesn't really 
change anything, except to cover a corner case.

For #2, yes.  Something like that.  I don't think we want to make that domain 
not exist since it clearly does.

This is  about if the sp= or np= policy should apply (if defined).  I think 
it's reasonable to apply np= if the only thing that makes the domain exists in 
our terms in the null mx (#1).  For #2, I think the sp= policy should apply.

Scott K

---

From: Benny Pedersen <[email-masked]>
Date: Sun, 05 Dec 2021 21:39:34 +0100

> only has an RFC 7505 null mx record is still considered non-existent?

hope you will not change rules to ignore null MX ?

why is it even a question ?

---

From: Benny Pedersen <[email-masked]>
Date: Sun, 05 Dec 2021 21:43:31 +0100

> my bank and stores from which I have ordered telling me that I can't 

banks or stores do not know anything about null mx :=)

null mx is not that known on many dns hosters :/

---

From: Benny Pedersen <[email-masked]>
Date: Sun, 05 Dec 2021 21:50:20 +0100

> p=MIIBIjANB..." /* it's signed */

thanks for another rule to mx check in mta stage

hopefully any-ip is just an example, not a real world test

should spf allow 0.0.0.0/0 ?, sadly it does

---

From: Douglas Foster <[email-masked]>
Date: Sun, 5 Dec 2021 16:54:42 -0500

It is a relief to finally have this topic open for discussion.  The issues
go deeper than null MX.

The goal is to domain names that the domain owner never uses for
RFC5321.From addresses.   No direct test exists, so there are two candidate
substitutes:
- (Relaxed:)  A name is rejected if it does not exist in DNS, so a lookup
returns NXDOMAIN.   An example would be "[email-masked]"
- (Strict:)  The name is not used for SPF mail.    An example would be "
[email-masked]"

There are problems with either of these, so a domain which intends to
publish an np=reject policy will need to take measures to ensure compliance
before publishing an NP=REJECT policy.

The MX/A/AAAA test is a version of the strict test, so it needs to be
addressed first.  The most  obvious problem is the omission of SPF.
There have been some assertions that SPF can be omitted because any domain
which sends mail must be configured to also receive it.    This is an
assertion which is difficult to defend.  A mail message can obtain both SPF
PASS and DMARC PASS based on SPF alignment, without having a valid MX
record.  We are all receiving no-reply messages, so we should not be
surprised at the existence of no-reply domains.   Therefore the existence
of a valid SPF record must be evidence that the domain exists for purposes
of the Strict test.

The second problem is the inclusion of A/AAAA as a test of SMTP usage.   I
suspect that there are relatively few DNS names which do not contain a host
record, so including A/AAA in the strict version of an existence test is
essentially reducing it to a relaxed test.    But this is not necessary.
 We can assume that a domain which wants to use NP=REJECT is willing to
exert some effort to make this test useful.  Requiring domain owners to
complete the migration from Implicit MX to Explicit MX is a very small ask
with a very big payback.   Therefore, A/AAAA should be dropped from the
Strict test.   Domains that do not wish to migrate to explicit MX can
choose not to publish NP=REJECT.

A third problem is the one that Scott introduced:   If a domain has one or
more MX records, but none of them can be resolved to a public IP address,
then the existence of the MX record indicates that the name is NOT used for
receiving mail.   Similarly, an SPF record of "-ALL" indicates that the
name is not used for sending mail.   For purposes of the Strict test,
invalid MX is equivalent to no MX, and SPF "-ALL" is equivalent to no SPF.

The fourth problem involves domain names that are only used for mass
mailings from service providers, where the service provider domain is used
for SMTP.  The FROM address domains on such mailings have no need to exist
in DNS, and we have had no difficulty finding examples of this occurring.
  This problem affects both relaxed and strict tests.    For domain owners
with subdomains that fit this situation, we need to provide a way to create
something in DNS which indicates that the domain exists for purposes of the
DMARC NP test.  Right now, we have no solution for them.

Doug Foster

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Dec 2021 00:01:16 +0000

>DMARC NP test.  Right now, we have no solution for them.

Nope.  See RFC 5321, Section 5.1, paragraph 2 (implicit MX).  DMARCbis needs to be consistent with existing mail standards.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 5 Dec 2021 21:35:15 -0500

It appears that Scott Kitterman  <[email-masked]> said:
>than NODATA or NXDOMAIN. ...

>our terms in the null mx (#1).  For #2, I think the sp= policy should apply.

The question appears to be whether we believe that null MX means that a
domain never sends mail, as opposed to never receivess mail.  As we said in
RFC 7505 sec 4.2, sending mail from a null MX domain is not a great idea,
but it is a SHOULD NOT, not a MUST NOT.  If you want to say you never send
mail, that's SPF -all.

I don't think this is the place to change the semantics.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Mon, 6 Dec 2021 06:59:56 -0500

Scot raises a valid concern, which calls for a counterproposal, not an end
to discussion.    I can propose one, but I wonder what the group thinks.

Building on other comments, the strict needs this additional logic:

DMARC Policy and the NP test
------------------------------------------
Existence of an exact-match DMARC record is definitely evidence that the
domain name exists for purposes of the NP test.   This is not an extra DNS
lookup, since the tree walk has to occur every time anyway.   The evaluator
simply needs to remember whether an exact-match policy was found.

A domain-level DMARC policy can solve my concern about domain names that
are currently not in DNS but are used for mass mailings.   The domain owner
who wishes to enable the NP test must create a domain-level DMARC policy
for any name that cannot satisfy the "existence" test by some other
method.

DKIM Public Keys and the NP test
----------------------------------------------
A domain also exists if a message has an unverified DKIM signature that (a)
has a key published for the scope ID, and (b) is an exact-match for the
mail domain name.   Of course, If the signature verifies, the result will
be DMARC PASS and the NP test will be ignored.

If the signature does not have a public key, then the failed signature may
be spoofed so it is ignored for purposes of the NP test.    The name may
still be non-existent

I don't think there is any way to answer the more general question, "Does
this domain have at least one DKIM public key?"

Invalid Names
-------------------
A PSD name is always invalid, with or without a DMARC policy found.
A name where any segment starts with an underscore is always invalid, with
or without a DMARC policy found.

Doug Foster

On Sun, Dec 5, 2021 at 7:01 PM Scott Kitterman <[email-masked]> wrote:

>
>
> On December 5, 2021 9:54:42 PM UTC, Douglas Foster <
> [email-masked]> wrote:
> Nope.  See RFC 5321, Section 5.1, paragraph 2 (implicit MX).  DMARCbis
> needs to be consistent with existing mail standards.
>
> Scott K
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Dec 2021 09:24:04 -0500

On Sunday, December 5, 2021 9:35:15 PM EST John Levine wrote:
> >In the current definition one of MX, A, or AAAA needs to return something
> >other than NODATA or NXDOMAIN. ...
> >
> >it's reasonable to apply np= if the only thing that makes the domain exists
> >in our terms in the null mx (#1).  For #2, I think the sp= policy should
> >apply.

I agree it's not the place to change the semantics, but I don't think we are.

The np/sp question is about domain existence, not does it send mail.  Where 
published so far the np tags tend to be a stricter policy than the sp tags.  
For example the current record for .mil:

v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:[email-masked]

The difference then would be that currently mail purportedly sent from 
example.mil would use the reject policy from the np= tag vice the none from 
sp=.  If someone were to publish a null mx record for that domain, should that 
change?

I think not.  My simplistic view of SHOULD NOT is that anyone who does owns 
the results if they do.  In this case if you really did send mail from 
example.mil with just the null mx record you SHOULD NOT have done that and if 
that gets a message rejected, well, you SHOULD NOT have done it that way and 
it's on you.

Scott K