On Friday, April 22, 2022 10:57:21 AM EDT Todd Herr wrote: > On Fri, Apr 22, 2022 at 9:15 AM Scott Kitterman <[email protected]> > > wrote: > > On April 22, 2022 7:35:29 AM UTC, Robert <[email protected]> wrote: > > >In section 4.8. Organizational Domain Discovery, we have: > > > Note: There is no need to perform Tree Walk searches for > > > > > > Organizational Domains under any of the following conditions: > > >... > > > > > > * There is no SPF pass result and no DKIM pass result for the > > > > > > message. In this case, there can be no DMARC pass result, and so > > > the Organizational Domain of any domain is not required to be > > > discovered. > > > > > >--- > > >We would still want to find a record to know who to send failure > > >reports to no? And this would involve some sort of tree walk if the > > >MAIL FROM doesn't have a record. Should it be changed to something it > > > > > >like: > > > * There is a DMARC record at the RFC5321.MailFrom domain and there > > > > > > is no SPF pass result and no DKIM pass result for the > > > message. In this case, there can be no DMARC pass result, and so > > > the Organizational Domain of any domain is not required to be > > > discovered. > > > > I agree the current text is a problem. > > > > This case is guaranteed not to pass, so you would need to know what policy > > to apply. There's another item in the note that addresses the portion of > > this case where the 5322.From domain has a DMARC record. If the 5322.From > > domain doesn't have a DMARC record then we do need to find the org domain > > to determine the policy to apply. I think this should be deleted, not > > modified. > > I believe when I wrote what's current section 4.8 that I was operating from > the assumption that tree walks would be performed sequentially, not > simultaneously, and in the following order: > > 1. DMARC Policy Discovery > 2. Organizational Domain Discovery > > Note that the second bullet in this section, which is elided in the thread, > reads: > > > - No applicable DMARC policy is discovered for the RFC5322.From domain > during the *first* tree walk. In this case, the DMARC mechanism does not > apply to the message in question. > > Further, the thinking here was that the Organizational Domain is only > necessary to discover when relaxed alignment must be determined between the > RFC53222.From domain and either the SPF or DKIM domain (or both) don't > match the RFC5322.From domain, and we've already determined that DMARC is > in play because we found the applicable DMARC policy during the first tree > walk. > > All that aside, I'll happily update the text for the next rev once there is > text proposed.
I've looked at it again and I think the paragraph can simply be deleted (see attached for rfcdiff). It looks to me like this is addressed adequately in the main text of the section, which now includes: > * The RFC5321.MailFrom domain if there is an SPF pass result for the > message. > > * Any DKIM d= domain if there is a DKIM pass result for the message > for that domain. That adequately covers the question of if a tree walk is needed to find an SPF/ DKIM related org domain. Scott K
draft-ietf-dmarc-dmarcbis-07.update.-from-.diff.html
Description: application/xhtml
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
