Sorry, I missed that. But I disagree with this statement: I think that if we changed the relaxed definition to the same as or a sub-domain of the From domain it would avoid potential issues like that without practical impact. I don't think I have ever seen legitimate mail where Mail From or DKIM signing domain wasn't either the same or a sub-domain of From that were in the same org domain.
We send tens of millions of such messages daily. These are messages where the From address is [email protected], and the DKIM signing domain is just organization.com. I suggest again that the simple answer is for the DMARC record itself to specify the organizational domain. This is orthogonal to how you discover the DMARC record. Regards, Joe Humphreys On Mon, Nov 1, 2021 at 4:26 PM Scott Kitterman <[email protected]> wrote: > That was addressed in Message-ID: > <[email protected]>. > > Scott K > > On Monday, November 1, 2021 3:30:13 PM EDT Joe Humphreys wrote: > > Scott, your proposal says to remove any reference to organizational > domain, > > but you don't explain how you will define DKIM and SPF alignment without > > reference to organizational domain. > > > > In your proposal, if the query at step 1 does return a record, and the > > record specifies relaxed alignment, then the receiver does not have > enough > > information to evaluate alignment. > > > > This is not an academic point. The organization I work for relies on > > relaxed alignment, and we sometimes create DMARC records for subdomains > > (usually because we've identified a subdomain that we're not yet ready to > > apply p=none to). I don't see how this will work under your proposal. > > > > Regards, > > Joe Humphreys > > > > > > On Sun, Oct 31, 2021 at 10:46 PM Scott Kitterman <[email protected]> > > > > wrote: > > > On November 1, 2021 2:19:02 AM UTC, Douglas Foster < > > > > > > [email protected]> wrote: > > > >Currently, the Publicssuffix.org list protects the PSL names. > Although > > > >I > > > >don't believe it is covered anywhere in the DMARC v1 document, any > DMARC > > > >implementer will have to notice that a PSL name must produce DMARC > FAIL, > > > >because it cannot be authenticated itself, and it cannot be > authenticated > > > >by alignment with any other domain name. > > > > > > > >If we could publish a rule which limits alignment to only work from an > > > >authenticated domain name downward to a child subdomain, we would > have a > > > >secure design, because we would not need to worry about leaving the > > > >authenticated organization. But as long as upward alignment is > > > >necessitated by current practice, we need to be concerned about > leaving > > > > > > the > > > > > > >authenticated organization in the upward direction into the PSL. > > > > > > > >A specific example: > > > >MailFrom is "[email protected]" and From is "trustme@com". > > > >Any acceptable replacement for the PSL must ensure that this > identifier > > > >configuration is rejected. > > > > > > > >When moving up the domain tree, the only way to avoid transiting from > an > > > >authenticated organization into the PSL, is to know what names are in > the > > > >PSL. The alternatives seem to be (a) an externally obtained list, > no > > > >matter how imperfect, or (b) DNS entries, no matter how imperfect. > The > > > >list seems the best option in the near term, but the DNS option might > > > > > > prove > > > > > > >valuable over time. > > > > > > What's wrong with what I already proposed? > > > > > > Your analysis is backwards. Modulo the few PSDs that have published > > > records for PSD DMARC and for receivers that check for it, the DMARC > > > results for mail to such domains is none, not fail. > > > > > > Scott K > > > > > > _______________________________________________ > > > 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
