On April 16, 2024 2:36:53 AM UTC, John Levine <[email protected]> wrote:
>It appears that Scott Kitterman <[email protected]> said:
>>>I'm with Scott, pick a number, 5, 8, whatever, and be done with it.
>>>
>>Modulo we do need to explain why 8. Related, I think we also need to explain
>>why the reporting address thing is important for DMARCbis since having an
>>intermediate level record isn't
>>currently supported by DMARC.
>
>What do you mean by intermediate level record? Whatever the tree walk finds is
>by definition the org domain.
>
>There are some PSL entries with one below another so it's not unprecedented.
That's true, although that pattern in the PSL doesn't seem very relevant to
email.
In the case of a.b.c.example.com and example.com is in the PSL, the DMARC
records in a.b.c.example.com (if present) and example.com (otherwise) are
consulted. The only way to get to b.c.example.com or c.example.com would be to
add them to the PSL. These are what I meant by intermediate records.
It's, of course, different for DMARCbis. There we walk up the tree, so those
get checked and as you say, the first one we find is the org domain.
The claim, as I understand it, is that for big orgs that go deeper than 5
levels (in fact up to 8), it is somehow critical to have different reporting
addresses (which leads to a need for org domains 6, 7, and 8 levels deep).
I don't find cases where it looks like such things have been added to the PSL,
so I'm skeptical that this is really critical. It might be helpful and it
might even be a good idea, but I fail to find the evidence I'd expect to find
if it were actually critical for a domain operator to be able to do this.
I agree that we ought to just get this done, but without a rationale for 8 that
holds water, I think we're better off deciding to stick to the number (5) that
we have an articulable rationale for.
I'm sure it will take some time to get through the last call comments, so I
imagine that we can wait a bit for more information before deciding without
delaying the overall progress.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
