I'm less sanguine about the felicity of the current state of affairs, but it may be the best we can do. At the very least we should make it clear that only the ICANN DOMAINS section of the PSL should be used. Not excluding the private domains from the beginning was a clear mistake (and I just submitted an erratum to document that).
Scott K On Monday, November 1, 2021 7:16:06 PM EDT Tobias Herkula wrote: > I'm more or less thinking we should keep the alignment method as is, and > only rephrase the subordinate clause to something that puts an emphasis on > the fact that we currently don't have a perfect solution, and the PSL has > shown to be a very stable external entity that is fine to use until > something better comes around. If my google-foo is not failing me, the cab > forum already discussed that at the beginning of the last decade, and still > here we are at the end of 2021 and are kind of fine with what the PSL > provides. > Every big change, like reference tags inside of DMARC records or even a more > sophisticated solution that tries to solve that not only for DMARC but for > others as well should be handled outside of this discussion here. We have > enough examples with other standards that opted for a dependency instead of > trying to solve it alone. And if that is so important, "dbound" is not > dead, only concluded... > -----Ursprüngliche Nachricht----- > Von: dmarc <[email protected]> Im Auftrag von Scott Kitterman > Gesendet: Dienstag, 2. November 2021 00:04 > An: [email protected] > Betreff: Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy > Discovery > > > On November 1, 2021 10:51:13 PM UTC, Dotzero <[email protected]> wrote: > > >On Mon, Nov 1, 2021 at 6:08 PM Tobias Herkula <[email protected]> > >wrote: > > > > > >> Yes this is used in a significant way, dropping the mechanic of the > >> org-domain would make a lot of things in processing inbound mail > >> streams a lot more complicated. > >> > >> > >> > >> The PSL does not exists for DKIM or DMARC, it is a product of the CAB > >> forum. And the idea was borrowed for DMARC, but without it, DMARC > >> will have a hard time, and depending standards as well. I don't want > >> to discuss how good or bad BIMI is, but without an "org-domain" it > >> doesn't work. But if DMARC as one of the base requirements for BIMI drops > >> the "org-domain" mechanic, you really need to produce a better > >> alternative than, > >> simply stating that things that are currently OK to do, are not used > >> by enough entities and could be abandoned. > >> > >> > >> > >> I see a couple billion mails per week and can assure you that > >> 5322.From's with a Sub-Domain but signed with the org-domain are a > >> regular picture of totally valid mail streams, and this whole concept > >> goes even deeper for large mail processors. It makes a huge > >> difference for measuring reputation and responsibilities. And I think > >> that this should be the baseline for the discussion here. As a mail > >> receiver, I would at least assume, I and most of my colleagues use > >> the org-domain concept to pin responsibilities to a clear and > >> dedicated entity. If we abandon this, we are opening additional > >> attack vectors without any increase in functionality and even > >> increasing the complexity for almost all parties, only for the sake of > >> getting the PSL out of the equation. >> > >> > >> > >> Querying the PSL in a compiled trie data structure is much faster > >> than even doing one DNS request, and even with the private part of > >> the PSL this is a couple MB of memory. I get Mails that are larger > >> than downloading the PSL once per day for a year. So why are we > >> having this discussion? I know the PSL is not perfect, and I'm > >> totally in for change if something doesn't work, but we have seen > >> that DBound didn't made it and there are no real heavy usage PSL > >> alternatives. >> > >> > >> > >> And one thing I really don't get, why do we want to solve that so > >> heavily that we use scare tactics with phrasing like "if we don't > >> solve it now, we would need to write another RFC in a couple of > >> years", isn't that totally fine, for a standard to evolve and update it > >> if it needs an update? >> > >> > > > > > >Thank you for your voice of reason Tobias. It would appear that some > >are willing to create a larger problem in order to address a smaller > >problem. > > Let me assure you, I'm not trying to break anything, very much the opposite. > It's difficult for people like me without access to tons of data to > generalize from what we do have. It appears that some of my assumptions > are in error, so we shouldn't act on them. > That said, I don't think BIMI's needs should be a factor in the DMARC > design. If BIMI needs an org domain and it turns out DMARC doesn't, then > they can define it to support their needs. > I think we've just started a conversation on how to address change (if any) > in the DMARC alignment algorithm. We're nowhere near the end, so please > don't panic. > 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
