Then, Seth, I am confused.
We have a non-trivial number of PSL entries that have DMARC policies which
either specify relaxed alignment or specified nothing and acquired relaxed
alignment by default. Are these organizations that have been victimized
by PSL errors, or are the PSLs that are enabling fraudulent sibling
impersonation? Is it the same answer in every case, or different for
each such entry? I don't think we know, and not knowing is a big problem.
The point of the Tree Walk was to detect and prevent the problems caused by
PSL errors. So now that we have a list of problems, what is the correct
disposition? If the Tree Walk has failed to give certainty in these known
cases, how will it provide certainty for future cases?
Tree Walk is a lot more overhead, but it is not a demonstrably reliable
solution to the relaxed alignment problem. Relaxed alignment requires
certainty about the organizational domain, and we do not have any path to
certainty.
Relaxed alignment is about 25% of the mail stream but 99% of the evaluation
work. It needs to be phased out.
Doug Foister
On Tue, Oct 17, 2023 at 10:07 PM Seth Blank <seth=
40valimail....@dmarc.ietf.org> wrote:
> As Chair, can this thread be brought to a close? It does not seem
> productive as Scott has repeatably observed.
>
> On Tue, Oct 17, 2023 at 11:41 Scott Kitterman <skl...@kitterman.com>
> wrote:
>
>>
>>
>> On October 17, 2023 5:56:47 PM UTC, Alessandro Vesely <ves...@tana.it>
>> wrote:
>> >On Tue 17/Oct/2023 14:03:40 +0200 Scott Kitterman wrote:
>> >> On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely <ves...@tana.it>
>> wrote:
>> >>> On Mon 16/Oct/2023 20:00:00 +0200 Scott Kitterman wrote:
>> >>>> On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely <
>> ves...@tana.it> wrote:
>> >>>>> On Fri 13/Oct/2023 16:35:43 +0200 Neil Anuskiewicz wrote:
>> >>>>>> Thank you, sir. That’s part of the reason to cautiously transition
>> away from the PSL. It has the feel of a throwback to a time when people
>> thought the number of total users would be in the hundreds or thousands.
>> Wouldn’t a cautious transition alleviate your concerns? Not everyone,
>> everywhere will pull the switch at midnight.
>> >>>>>
>> >>>>> Can we engage ICANN for sending a kind request to upgrade their
>> DMARC records to all PSDs? Or can we do it on their behalf? Or on IETF
>> behalf? Or?
>> >>>>>
>> >>>>> Is that a subject for 118?
>> >>>>
>> >>>> Which ICANN managed TLDs have DMARC records (PSDs which are either
>> not TLDs or not ICANN managed TLDs are not anything ICANN has anything to
>> say about)?
>> >>>
>> >>> According to Doug's file:
>> >>>
>> >>> ale@pcale:~/tmp/zdkimfilter/regdom$ for d in $(grep -v '^[/* ]'
>> icann_public_suffix_list.dat); do l=$(grep "^$d,"
>> PSL_entries_with_DMARC_policies.csv); if [ -n "$l" ]; then echo "$d -> $l";
>> fi done
>> >>> ...
>> >>> [list elided]
>> >>> ...
>> >>
>> >> Unless I missed one, none of those are TLDs except gov and mil and all
>> of the rest are under CC TLDs, so doubly nothing to do with ICANN. ICANN
>> doesn't manage gov and mil, but they both have psd=y in their records
>> already, so I'm not sure why they are even on the list.
>> >
>> >
>> >Ok, those are PSDs, not TLDs. They are in the ICANN part of the PSL.
>> Does that imply they have nothing to do with ICANN?!?
>> >
>> >If ICANN cannot help, we can as well consider the so-called private
>> domains of the PSL.
>> >
>> >DMARCbis assumes that PSOs include this tag with a value of 'y' to
>> indicate that the domain is a PSD. Indeed, Section 5.6 specifies:
>> >
>> > In addition to the DMARC Domain Owner actions, if a PSO publishes a
>> DMARC
>> > record it MUST include the psd tag (see Section 5.3) with a value of
>> 'y'
>> > ("psd=y").
>> >
>> >Non-compliance in this case affects all independent subdomains of those
>> PSL domains. Admittedly, they are not so frequently met. However, before
>> switching from PSL to Tree Walk, operators would probably want to see at
>> least a (significant) part of those set their tags, no?
>> >
>>
>> Nothing in the PSL has anything to do with ICANN.
>>
>> Most of those don't have independent sub-domains, so no, most is not
>> relevant.
>>
>> If I were updating an implementation to support DMARCbis, I might want to
>> consider that, but it has nothing to do with actually developing the
>> updated standard, which is what I thought we were trying to do.
>>
>> 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
>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
