That might do it. Scott K
On November 1, 2021 10:03:06 PM UTC, Joe Humphreys <[email protected]> wrote: >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
