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

Reply via email to