Re: [dmarc-ietf] 3.2.6. Non-existent Domains
On Sunday, December 5, 2021 9:35:15 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >> 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 */ > > > >In the current definition one of MX, A, or needs to return something > >other than NODATA or NXDOMAIN. ... > > > >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. > 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. 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:dmarc_repo...@mail.mil 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
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 wrote: > > > On December 5, 2021 9:54:42 PM UTC, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >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 "u...@junk.junk.ietf.org" > >- (Strict:) The name is not used for SPF mail.An example would be " > >u...@www.ietf.org" > > > >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/ 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/ 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/ 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 > >some
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
It appears that Scott Kitterman said: >> 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 */ > >In the current definition one of MX, A, or needs to return something >other >than NODATA or NXDOMAIN. ... >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. 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
On December 5, 2021 9:54:42 PM UTC, Douglas Foster wrote: >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 "u...@junk.junk.ietf.org" >- (Strict:) The name is not used for SPF mail.An example would be " >u...@www.ietf.org" > >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/ 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/ 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/ 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. 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
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 "u...@junk.junk.ietf.org" - (Strict:) The name is not used for SPF mail.An example would be " u...@www.ietf.org" 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/ 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/ 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/ 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
On 2021-12-05 20:40, John Levine wrote: It appears that Scott Kitterman said: 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/, 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/ 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. 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 */ 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
On 2021-12-05 20:04, John Levine wrote: 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. banks or stores do not know anything about null mx :=) null mx is not that known on many dns hosters :/ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
On 2021-12-05 05:13, Scott Kitterman 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? hope you will not change rules to ignore null MX ? why is it even a question ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
On Sunday, December 5, 2021 2:40:16 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >> 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/, 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/ 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. > > 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 */ In the current definition one of MX, A, or 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
It appears that Scott Kitterman said: >> 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/, 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/ 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. 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
On Sunday, December 5, 2021 2:04:20 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >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. > > 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. 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/, 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/ 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
It appears that Scott Kitterman said: >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. 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
On Sat, Dec 4, 2021 at 11:14 PM Scott Kitterman 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? > > I'll propose text if it's agreed this would be a useful change? > > Scott K > > 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]. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] 3.2.6. Non-existent Domains
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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
