On Mon, Jun 27, 2022 at 8:36 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> My testing was done more than a year ago. My recollection is that I > discovered it based on something in the wild, and then confirmed it with a > locally-configured experiment. This time I am having trouble finding > examples. > > The only one I can verify is from a previous email exchange on this forum: > > mail.foodnetwork.com > returns NXDOMAIN > > but > _dmarc.mail.foodnetwork.com > returns DATA for type=TXT > Thank you for the further information. In regards to RFC 8020, rev -10 of DMARCbis currently reads as follows: 7.8. <#section-7.8>Domain Existence Test <#name-domain-existence-test> RFC 7489 used the test specified in [RFC5321 <#RFC5321>] to determine a domain's existence. This test requires up to three DNS lookups for the MX, A, and AAAA RRs for the name in question.ΒΆ <#section-7.8-1> This version of the protocol relies solely on the test for existence as defined in [RFC8020 <#RFC8020>]. If a query for a name returns NXDOMAIN, then the name does not exist. <#section-7.8-2> But I'm not sure that this is correct, especially not the first sentence, because here's what RFC 7489 has to say on the topic: <https://datatracker.ietf.org/doc/html/rfc7489#appendix-A.4> A.4 <https://datatracker.ietf.org/doc/html/rfc7489#appendix-A.4>. Domain Existence Test A common practice among MTA operators, and indeed one documented in [ADSP <https://datatracker.ietf.org/doc/html/rfc7489#ref-ADSP>], is a test to determine domain existence prior to any more expensive processing. This is typically done by querying the DNS for MX, A, or AAAA resource records for the name being evaluated and assuming that the domain is nonexistent if it could be determined that no such records were published for that domain name. * The original pre-standardization version of this protocol included a* * mandatory check of this nature. It was ultimately removed, as the* * method's error rate was too high without substantial manual tuning* * and heuristic work.* There are indeed use cases this work needs to address where such a method would return a negative result about a domain for which reporting is desired, such as a registered domain name that never sends legitimate mail and thus has none of these records present in the DNS. The first two sentences in the second paragraph from RFC 7489 seem to contradict the statement in DMARCbis that "RFC 7489 used the test specified in RFC 5321 to determine a domain's existence." This would argue for the text of "Domain Existence Test" in DMARCbis to be reworded. The "np" tag didn't exist in RFC 7489, and it's not clear to me that RFC 7489 cared all that much about whether a domain existed. In DMARCbis, however, the "np" tag does exist, and so it seems we must settle on a way to determine whether or not a domain exists, and RFC 8020 seems to be the more efficient method than RFC 5321, as it requires just one query, not three. As to the particulars of your example, I'm not sure there's any difference regardless of the method chosen, as queries for an A, AAAA, and MX records for the name "mail.foodnetwork.com" all return NXDOMAIN just as does a query for ANY. Those results are, for me, enough reason to reject a message prior to attempting any DMARC processing, because if the domain in the From: or Return-Path: header doesn't exist, then the message cannot be replied to and is therefore not worthy of being accepted. This is consistent with the above statement from RFC 7489 - "A common practice among MTA operators ... is a test to determine domain existence prior to any more expensive processing." The fact that AWS's DNS servers don't adhere to RFC 8020 and return an answer for _dmarc.mail.foodnetwork.com would be meaningless to me here, because I'd never ask the question. For those MTA operators who don't think like I do, DMARCbis is clear on which policy to use for a non-existent RFC5322.From domain: If the DMARC policy to be applied is that of the RFC5322.From domain, then the DMARC policy is taken from the p= tag of the record. If the DMARC policy is taken from either the Organizational Domain or the Public Suffix Domain and that domain is different than the RFC5322.From domain, then the DMARC policy is taken from the sp= tag (if any) if the RFC5322.From domain exists and the np= tag (if any) if the RFC5322.From domain does not exist. In the absence of applicable sp= or np= tags, the p= tag policy is used for subdomains. This would mean in this case that for those sites that adhere to the DMARCbis specification and elect to accept mail from non-existent domains, the policy published at "_dmarc.foodnetwork.com" would apply to this message (p=none), rather than the policy published at "_dmarc.mail.foodnetwork.com" (p=reject), and if the domain owner of mail.foodnetwork.com wanted different behavior, they would ensure that mail.foodnetwork.com passes an existence test in DNS. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
