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
