Great. As I mentioned, I don't currently have access to a large, diverse corpus of email to check against.
Could you perhaps do an assessment of the percentages of email you see where 5322.From == Org domain 5322.From is a sub-domain of Org domain 5321.MailFrom == 5322.From 5321.MailFrom is a sub-domain of 5322.From 5322.From is a sub-domain of 5321.From d= domain == 5322.From d= domain is a sub-domain of 5322.From 5322.From is a sub-domain of d= domain I think that something like this would be very helpful for the group to understand what is currently used. Clearly we need to carefully address current practice. Scott K On November 1, 2021 10:07:46 PM UTC, Tobias Herkula <tobias.herk...@1und1.de> 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? > >-----Ursprüngliche Nachricht----- >Von: dmarc <dmarc-boun...@ietf.org> Im Auftrag von Scott Kitterman >Gesendet: Montag, 1. November 2021 21:24 >An: dmarc@ietf.org >Betreff: Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy >Discovery > >On Monday, November 1, 2021 3:17:05 PM EDT Alessandro Vesely wrote: >> From: u...@sub.example.org, signed by example.org which also publishes >> a policy has to be valid. > >Why? Do you know of this construct being used in any significant way? > >Scott K > > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc