On Fri, Apr 22, 2022 at 9:15 AM Scott Kitterman <skl...@kitterman.com>
wrote:

>
>
> On April 22, 2022 7:35:29 AM UTC, Robert <arad...@gmail.com> 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.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to