On Fri, Feb 3, 2023 at 3:35 AM Douglas Foster < [email protected]> wrote:
> Time to eat crow. > > You are right, the RFC5322.From address is the default Reply-To. The > rest of the argument stands. > I'm at a bit of a loss to understand what argument you're making here. I'm going to answer on the assumption that your argument is "People send mail with non-existent RFC5322.From domains all the time, and that mail is wanted mail, and also the np tag shouldn't exist." Apologies if that's not your argument. If that's the case, please describe your argument and I'll reply again. > > So let's do a simple test on real mail: Somebody implement the proposed > NP test to detect non-existent subdomains of legitimate mail. Don't count > messages that are rejected because of NXDOMAIN on the SPF policy lookup. > Don't count messages that are rejected because of DMARC QUARANTINE or > REJECT. That leaves messages with these characteristics: > I don't understand your use of the phrase "NP test to detect non-existent subdomains of legitimate mail". The np tag is defined as a policy assertion for non-existent subdomains of the domain publishing a DMARC record, one that should be applied to messages using non-existent subdomains that fail DMARC validation checks. As I've stated before, I don't believe messages using a non-existent domain as their RFC5322.From domain (or RFC5321.From domain, for that matter) don't deserve the privilege of being accepted, but I haven't had a say in such matters since 2010. For the purposes of this message, I'll agree to the stipulation that I'm wrong on this topic, and that messages using non-existent domains in either From header are worthy of being accepted. > - MailFrom domain exists > - From organization domain exists > - From domain does not exist based on your NP language, or any other > non-replyable rule you want to use. > Section 3.2.6 of DMARCbis, titled "Non-existent Domains", reads in its entirety: "For DMARC purposes, a non-existent domain is consistent with the term's meaning as described in [RFC8020 <https://www.rfc-editor.org/info/rfc8020>]. That is, if the response code received for a query for a domain name is NXDOMAIN, then the domain name and all the names under it do not exist." That's not my language. So, we're at a state where the RFC5322.From domain does not exist, and the DMARC policy to be used for this message must come from a domain above it in the DNS hierarchy, because _dmarc.RFC5322.From.domain cannot exist based on RFC8020. Process between 1000 and 1,000,000 messages and review the ones that are > flagged by your test. Report (a) number of messages flagged as suspicious > based on your rule, and (b) number of unwanted messages flagged within > that group. My testing indicates that the (a) group will be small and > the (b) group will be very close to zero. > > The reality is that attackers have very little reason to attack a > non-existent subdomain, because they always have existent subdomains that > will be more promising targets because they are real. If they do start > attacking non-existent subdomains, there are existing options to defend: > > - To protect non-existent subdomains only, without affecting mailing > lists: use domain-level p=none policies on all subdomains that send mail, > and sp=reject on the organization domain. > This option cannot be implemented, as one cannot publish a domain-level p=none policy on a non-existent subdomain that sends mail. _dmarc.RFC5322.From.domain cannot exist if RFC5322.From.domain does not exist in the DNS. This would require that the 'sp' tag be applied to the non-existent subdomain, and sp=reject would only apply to those messages that fail DMARC authentication checks. In your scenario, I'm presuming that the message would pass DMARC authentication checks, because there's a DMARC policy published at the org domain, and either the MailFrom domain or the DKIM signing domain aligns with the non-existent RFC5322.From domain and SPF or DKIM passes. Is my understanding of your scenario correct? Understand too that "p=none" even if it could be published for this non-existent domain is not a guarantee that a message will be accepted even if it fails DMARC authentication checks. "p=none" effectively means "Don't take the DMARC authentication results into account as part of your message disposition decision, which doubtless include many factors other than the DMARC validation results. I understand that that decision can still be 'deliver to spam', 'reject', or anything you deem appropriate, based on those many other factors." > > - To protect all subdomains: use sp=reject on the organization domain. > This is the only option that will apply to non-existent subdomains in the absence of an np tag. Again though, sp=reject would only apply to those messages using a non-existent RFC5322.From domain if those messages don't pass DMARC validation checks. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* [email protected] *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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
