In an organization of non-trivial size the chance that the person making the decision about what to put in DNS can reliably answer the question "used for RC5322.From addressing" is vanishingly small. They can, however, be very confident about if they have set up A/AAAA/MX records. At best you are trading one kind of uncertainty for another.
Scott K On Monday, December 20, 2021 7:12:34 AM EST Douglas Foster wrote: > Scott asked some questions along the lines of "since no test is perfect, > why don't we just run with the easily-understood MX/A/AAA test. I had not > responded to that part of the question previously. > > I have two major problems with the MX/A/AAAA test: > > - If we are only testing for "Does this domain send out SMTP mail?", then > SPF must be included in the criteria. SPF speaks to what the domain sends, > while MX speaks to what the domain receives, and A/AAAA speaks to what the > domain might receive. If we are testing for send behavior, we need to > examine the send authentication attribute. Any test which is based on > SMTP and other things should include SPF for the same reason. > > - Since we are not testing exclusively for SMTP behavior, we need to think > about how to avoid false positives, and how a domain owner changes a test > result from Fail to Pass. I have been calling this action "compliance > measures", hoping that the term was clear. For the MX/A/AAAA test, with > or without SPF, the only way to indicate compliance is to publish false > information about SMTP configurations that do not apply to this domain. > Such false information has the potential for changing the behavior of SMTP > participants, and cannot be acceptable in a standards-track document. > > I have suggested feature-specific DNS flags, to indicate that a particular > domain does or does not participate in FROM addressing, or does not > participate in SMTP addressing. These have the advantage of being very > specific, but they depend on domain owners publishing new information. > A test which minimizes publishing new data has a better chance of being > usable, with confidence, by evaluators. So I suggested an exact-match > DMARC policy as an indicator to mean "used for RC5322.From addressing." > I am not entirely happy with that workaround, as it may have unwanted side > effects about how reporting occurs back to the domain owner. > > DF > > > > On Sun, Dec 19, 2021 at 3:42 PM Scott Kitterman <[email protected]> > > 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 < > > > > [email protected]> 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 <[email protected]> wrote: > > >> It appears that Jeremy Harris <[email protected]> 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 [email protected]. > > >> > > >> 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 > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/dmarc > > > > _______________________________________________ > > dmarc mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
