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
