Perhaps you can connect with a current client or former colleague who is doing mail operations. I am looking for at least one example of an illegitimate message that uses a non-existent subdomain in the From address.
To be clear, I am talking about messages where MAILFROM and FROM are not aligned, because the message is sent by an email service provider. Aligned messages depend on the SPF result, and we all agree that it makes sense to block when SPF=NXDOMAIN. Doug On Tue, Mar 15, 2022 at 10:53 AM Todd Herr <todd.herr= [email protected]> wrote: > On Mon, Mar 14, 2022 at 9:54 PM Douglas Foster < > [email protected]> wrote: > >> I asked this question because I have concluded that NP is only meaningful >> for registrar policy records, to identify unregistered organizations. >> >> For subdomains of registered organizations, SP=reject protects both >> existent and non-existent domains. This means that a NP policy would only >> be relevant when sp=none and np=reject. However, we can assume that a >> malicious impersonator will make an intelligent choice among his options, >> based on what he perceives as most likely to succeed. That order of >> priority would reasonably be: organization, mail-sending subdomain, >> non-mail but existent subdomain, and finally, non-existent subdomain. >> >> At the same time, it is difficult to assume that any >> theoretical expectation will remain valid across many spammers and billions >> of messages. In my limited study, I only see non-existent subdomains used >> for legitimate mail. Since no one has submitted evidence to the contrary, >> I feel emboldened that my theory may indeed be correct. If non-existent >> subdomains of legitimate organizations are being impersonated on a scale >> worthy of checking every message, I would expect that we could find >> evidence of it. >> >> Google and Microsoft have not weighed in, however. I wish they would, >> >> > Were I still in email operations, I would have little to no use for the np > tag, because a non-existent RFC5322.From domain would be reason to reject > the message, full stop, with no need to find a DMARC policy record > associated with it. > > I always believed that if a message couldn't be replied to, it wasn't > worth accepting, and so non-existent domains in either RFC5321.From or > RFC5322.From were met with 5xx replies. > -- > > *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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
