Reject only occurs if DMARC fails. No disagreement there. NP only services a useful purpose it is is stricter than SP, So I assume that normal use will be SP=NONE, P=REJECT.
Acceptable impersonation always uses a real email address, so this combination allows mailing lists and acceptable impersonations, without allowing malicious impersonations based on fake subdomains. This is a small potential benefit, if we assume that, in the absence of NP, spammers will attack a fake subdomain even though valid subdomains remain unprotected. On Tue, Feb 7, 2023 at 8:51 AM Todd Herr <todd.herr= [email protected]> wrote: > On Mon, Feb 6, 2023 at 9:25 PM Douglas Foster < > [email protected]> wrote: > >> You actually summarize my points pretty well. Here are the three >> concepts: >> >> 1) People send mail with non-existent RFC5322.From domains (subdomains of >> existent domains) all the time, and that mail is wanted. >> >> Yes, that is my assertion based on research into my mail stream. I >> spent several months checking every From address for NXDomain, MX Exists, >> or A Exists. I found that none of these tests added any value; it was >> mostly an exercise for the benefit of this issue and this group. After a >> while, I stopped checking to reduce overhead. This is an assertion of >> fact, which I have presented several times. Every mail stream is >> different, so maybe someone else can present different data. But oddly, >> no one has presented other data, which makes me wonder if no one else can. >> >> Anyone can prove me wrong with more comprehensive data, or you can accept >> my results on blind faith, but you should not write text based on untested >> assumptions, when actual data will answer the question. >> >> 2) The NP=reject tag is useful when PSD=Y, when applied to the PSD+1 >> organizational domain only. >> >> Every organizatioin MUST be registered. Mail coming from an unregistered >> organization should be rejected. >> >> However, when a PSD's NP clause is applied to non-existent subdomains of >> an existent organization that has no DMARC record, the use is >> inappropriate. Based on #1, it is not only inappropriate but also likely >> to be wrong. With this limitation, PSD policies should always publish >> NP=reject. >> >> 3) The NP tag may be of interest to some organizations. >> >> Whether NP on organization policies is useful or not will depend on >> whether it is applied correctly or not. My expectation is that some >> organizations will publish NP=reject when they should not, causing false >> positives. I also expect that some organizations will publish NP=reject >> correctly, and the test will never fail because spammers are very unlikely >> to send using non-existent subdomains of registered domains. >> >> Assuming that there are exceptions to everything, perhaps someone can >> find some messsages that fits these characteristics. If so, we have to >> look at the signal-to-noise ratio between correctly blocked messages and >> incorrectly blocked messages. If the ratio is wrong, evaluators will >> disable the test anyway. >> >> Finally, I don't have any problem with the definition of non-existent. >> A domain or subdomain is non-existent if it returns NXDOMAIN. If the >> organization domain does not exist, any messages that use that domain >> should be blocked. If the organization domain does exist, I am >> unconcerned whether a particular subdomain exists. If someone wants to >> convince me that I should be concerned, I need data. >> >> > It's not clear to me that your understanding of the np tag matches mine, > so I'm going to ask a clarifying question or two. > > Do you believe that a DMARC policy record containing the tag "np=reject" > means: > > 1. If the RFC5322.From domain (which is necessarily a sub-domain of > the domain publishing the policy record) does not exist, then reject the > message, OR > 2. If the RFC5322.From domain (which is necessarily a sub-domain of > the domain publishing the policy record) does not exist AND the message > does not pass DMARC validation checks, then reject the message > > The current text for DMARCbis describes the np tag as choice 2 here, and > so I don't understand your contention that "some organizations will publish > NP=reject when they should not, causing false positives", because even a > domain so careless (in my opinion) as to permit mail to be emitted using > non-existent sub-domains while still publishing a DMARC policy record > should have things configured to ensure that such mail will pass DMARC > validation checks. A message using a non-existent From domain that also > fails DMARC validation checks where a prevailing DMARC policy exists seems > to me to be the epitome of unauthorized mail, so I don't see how rejecting > it would be a false positive. Can you help me understand why rejecting such > a message would be the wrong thing to do? > > -- > > *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
