You or the others seem to be confusing NXDOMAIN on RFC5321.MailFrom lookup with NXDOMAIN on RFC5322.FROM. The issues are very different.
NXDomain on the MailFrom lookup says neither the SPF policy nor the SMTP domain exist, and therefore there is no reverse path. Rejecting such messages makes a lot of sense and, as has been said, has nothing to do with DMARC. NXDomain on RFC5322.From is a completely different issue. It means that the name is only used for service provider messaging, and is therefore not linked to any IP address or other physical infrastructure. It affects the ability to define a meaningful NP test. The issue becomes irrelevant to DMARC if and only if we drop the NP policy idea completely. The proposed MX/A/AAAA/SPF test has two significant problems: - It incorrectly classifies some names as NP because they do not need MX/A/AAAA/SPF records because they are not tied to an IP address, and we have provided a very poor mechanism for a domain owner to come into compliance. - It incorrectly classifies some names that are not used for email as not NP, simply because they have an A/AAAA record. It provides no method for the domain owner to signal that the name is not used for email and therefore should be treated as NP. With the expectation of significant errors in both directions, we do not have a usable definition of NP. Doug Foster On Wed, Jun 16, 2021 at 1:51 PM Alessandro Vesely <[email protected]> wrote: > On Wed 16/Jun/2021 18:01:08 +0200 John Levine wrote: > > It appears that Alessandro Vesely <[email protected]> said: > >>However, to reject based just on NXDOMAIN is too harsh. > > > > I dunno, in my experience it's quite common, and if you do, the chances > of losing a message you care > > about are negligible. > > > It's been customary to reject NXDOMAIN in smtp.mailfrom since when I > recall it. > To reject NXDOMAIN in header.from is (was) an ADSP feature which doesn't > seem > to be very widespread. DMARC dropped it a long time ago. > > > > In any event, this has nothing to do with DMARC. If for some reason you > want to do a DMARC evaluation > > of a non-existent domain, you can use the organizational domain or I > suppose PSD. > > > It might make sense to reject that ~30% which doesn't even have an > organizational domain (dubbed totally astray in my previous post). But I > still > receive From: <[email protected]> on a mailing list. > Rejecting that > risks getting unsubscribed. Perhaps mailing lists deserve a special > permission... > > > Best > Ale > -- > > > > > > > > > > > > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
