Yes, I am looking for a high degree of certainty, comparable to what I get with DMARC PASS. (For example, the DKIM private key might have been compromised, but I choose not to worry about that possibility.)
As I have said several times recently, DMARC FAIL is an ambiguous result, and it is desirable to partition the set of all failures to see if certainty can be obtained for some of them. ARC is an attempt to solve uncertainty for a subset of messages by providing a new authentication method which says ARC-satisfactory messages are definitely not malicious impersonations. NP is, at least to my mind, is an attempt to solve uncertainty in the opposite direction by identifying a subset of failures that can only be malicious impersonations. When acceptable impersonation occurs, it is always on behalf of an actual user. If there is no actual user, impersonation can only be malicious. For simplicity, and of necessity, we ignore risks associated with the local-part and focus on the domain name. We ask whether an entire domain can be categorized as never-valid, so that messages to that domain can be moved from unverified-with-uncertain-risk to unverified-with-confirmed-risk. At minimum, to satisfy the PSD goal, we need to be able to say that "DoesNotExist.tld" is invalid because the organization is not registered with a PSD. For that to work, we also need to not block messages from valid names. The NXDOMAIN test is sufficient to solve the PSD problem, so the only issue for registered domains is to ensure that valid domains do not return NXDOMAIN. A more complex rule can block more non-mail names from impersonation attacks, but they increase the compliance issues. DF On Sun, Dec 19, 2021 at 3:42 PM Scott Kitterman <skl...@kitterman.com> wrote: > If the domain owner has suggested that you reject mail from a sub-domain > that has none of A, AAAA, or MX records, why would you not do that? Just > as with any DMARC policy it's on the sender to ensure authorized email > conforms to the policy. My impression is that you think that rejecting > mail from such sub-domains is inherently risky somehow? > > My view is that it's substantially less risky than for more usual > sub-domains. Note that I don't claim it's risk free. No filtering > decision is risk free, so I don't find suggestions that it's not totally > free of uncertainty particularly useful. > > My sense is that you are still searching for something that the np= tag > was never meant to be. It might be more fruitful to try and specify what > problem you are trying to solve and how we might go about it independent of > the non-existent domain definition. Maybe you can propose a totally new > tag that addresses the issues you are concerned about. If this new tag > gets support from the group then we could look at if np= is still needed or > if it's redundant. > > Scott K > > On December 19, 2021 7:35:30 PM UTC, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >What I said was that reception of NDRmessages is only a requirement for > the > >SMTP From address, so they are only required for the RFC5322.From address > >when the two From addresses match. For msiling list messages, tbe two do > >not match. > > > >My topic was about the ability or inability to detect a never-valid > RFC5322 > >>From address. I am not engaged in any effort to change mailing lists. > > NP=reject MUST never reject mailing list traffic. If we cannot do that, > >NP is useless. > > > >But we can meet that requirement, if we construct the right test. I can > >support several different variations of the test, which differences in > >strictness and complexity. I just cannot support the MX-A-AAAA test. > > > >Doug > > > >Doug > > > >On Sat, Dec 18, 2021, 12:15 PM John Levine <jo...@taugh.com> wrote: > > > >> It appears that Jeremy Harris <j...@wizmail.org> said: > >> >On 18/12/2021 03:47, Douglas Foster wrote: > >> >> MX checks are a valid tool for assessing SMTP MailFrom addresses, > since > >> the > >> >> sender is supposed to be ready to accept non-delivery reports and > other > >> >> automated messages. Of course, this has applicability if (but only > if) > >> >> the RFC5322.From domain is the same as the RFC5321.MailFrom domain. > >> > > >> >I disagree. It is well-established practice for a mailing list manager > >> >to accept and process NDRs accepted on the 5321.mailfrom (which differs > >> >from the 5322.from). > >> > >> Jeremy is right. Mailing lists always, and I mean always, put their > >> own 5321 bounce address on the messages so they can do bounce > >> management. If you look at the mail from this list, the bounce address > >> is dmarc-boun...@ietf.org. > >> > >> I have to say I am dismayed that we are spending time dealing with such > >> utterly basic misconceptions here. > >> > >> R's, > >> John > >> > >> _______________________________________________ > >> dmarc mailing list > >> dmarc@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmarc > >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
