Re: [dmarc-ietf] Tree Walk impact
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 wrote:
>
>
> On October 17, 2023 5:56:47 PM UTC, Alessandro Vesely
> wrote:
> >On Tue 17/Oct/2023 14:03:40 +0200 Scott Kitterman wrote:
> >> On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely
> wrote:
> >>> On Mon 16/Oct/2023 20:00:00 +0200 Scott Kitterman wrote:
> On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely
> 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
Re: [dmarc-ietf] Why Relaxed Alignment?
I’m sorry— the entire ecosystem only uses relaxed alignment. What
operational concern, per charter, are you concerned about? This is what
people do, and we’ve already discussed the data as a working group.
Seth, as Chair, and confused
On Tue, Oct 17, 2023 at 18:51 Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Why do we need to support relaxed alignment at all?
>
> When a domain is suddenly harmed by a PSL error, the necessary fix is to
> implement same-domain policies with same-domain signatures. The
> appropriate technique to prevent that problem, before it happens, is
> exactly the same configuration. This configuration strategy remains in
> effect as long as any imperfect version of the PSL is in use. After that,
> it will persist if tbe TreeWalk ever produces incorrect results. It is
> simply in the domain owner's interest to avoid relaxed alignment and the
> dependency that it creates on an imperfect PSL,
>
> It is also in the evaluator's interest to avoid relaxed alignment.
> Relaxed alignment requires more processing overhead under any algorithm,
> while increasing risk. Relaxed alignment, using a domain policy and
> sibling authentication, is simply not the same risk profile as strict
> alignment using a same-domain policy.
>
> A domain that is not signing its messages is not serious about
> authentication. When adding signatures to a server, configuring a
> same-domain signature should be exactly the same effort as using a
> non-matching one. In fact, a super-majority of aligned signatures already
> provide strict alignment for exactly that reason. Relaxed alignment
> primarily serves to sanctify SPF results and thereby make DKIM appear
> unnecessary.
>
> Instead of asking evaluators to undertake a new design with new overhead,
> we should tell domain owners to do the right thing: provide proof of
> authenticity that can be verified quickly and easily by evaluators. Those
> requirements are met by strict alignment with same-domain policies, and
> anything less is deprecated. Relaxed alignment will continue being
> accepted as long as evaluators grant grace, but domain owners should not
> assume that they will do so forever. We have proven that relaxed alignment
> provides only sloppy security. Building a better version of sloppy will
> not fix the mess.
>
> Doug Foster
>
>
>
>
> On Tue, Oct 17, 2023, 2:41 PM Scott Kitterman
> wrote:
>
>>
>>
>> On October 17, 2023 5:56:47 PM UTC, Alessandro Vesely
>> wrote:
>> >On Tue 17/Oct/2023 14:03:40 +0200 Scott Kitterman wrote:
>> >> On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely
>> 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
Re: [dmarc-ietf] Why Relaxed Alignment?
Why do we need to support relaxed alignment at all?
When a domain is suddenly harmed by a PSL error, the necessary fix is to
implement same-domain policies with same-domain signatures. The
appropriate technique to prevent that problem, before it happens, is
exactly the same configuration. This configuration strategy remains in
effect as long as any imperfect version of the PSL is in use. After that,
it will persist if tbe TreeWalk ever produces incorrect results. It is
simply in the domain owner's interest to avoid relaxed alignment and the
dependency that it creates on an imperfect PSL,
It is also in the evaluator's interest to avoid relaxed alignment.
Relaxed alignment requires more processing overhead under any algorithm,
while increasing risk. Relaxed alignment, using a domain policy and
sibling authentication, is simply not the same risk profile as strict
alignment using a same-domain policy.
A domain that is not signing its messages is not serious about
authentication. When adding signatures to a server, configuring a
same-domain signature should be exactly the same effort as using a
non-matching one. In fact, a super-majority of aligned signatures already
provide strict alignment for exactly that reason. Relaxed alignment
primarily serves to sanctify SPF results and thereby make DKIM appear
unnecessary.
Instead of asking evaluators to undertake a new design with new overhead,
we should tell domain owners to do the right thing: provide proof of
authenticity that can be verified quickly and easily by evaluators. Those
requirements are met by strict alignment with same-domain policies, and
anything less is deprecated. Relaxed alignment will continue being
accepted as long as evaluators grant grace, but domain owners should not
assume that they will do so forever. We have proven that relaxed alignment
provides only sloppy security. Building a better version of sloppy will
not fix the mess.
Doug Foster
On Tue, Oct 17, 2023, 2:41 PM Scott Kitterman wrote:
>
>
> On October 17, 2023 5:56:47 PM UTC, Alessandro Vesely
> wrote:
> >On Tue 17/Oct/2023 14:03:40 +0200 Scott Kitterman wrote:
> >> On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely
> wrote:
> >>> On Mon 16/Oct/2023 20:00:00 +0200 Scott Kitterman wrote:
> On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely
> 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
>
> _
Re: [dmarc-ietf] Tree Walk impact
On October 17, 2023 5:56:47 PM UTC, Alessandro Vesely wrote:
>On Tue 17/Oct/2023 14:03:40 +0200 Scott Kitterman wrote:
>> On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely wrote:
>>> On Mon 16/Oct/2023 20:00:00 +0200 Scott Kitterman wrote:
On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely
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
Re: [dmarc-ietf] Tree Walk impact
On Tue 17/Oct/2023 14:03:40 +0200 Scott Kitterman wrote:
On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely wrote:
On Mon 16/Oct/2023 20:00:00 +0200 Scott Kitterman wrote:
On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely 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?
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree Walk impact
On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely wrote: >On Mon 16/Oct/2023 20:00:00 +0200 Scott Kitterman wrote: >> >> >> On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely 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 >qld.gov.au -> qld.gov.au,n,n,0,r,r,z,z >sa.gov.au -> sa.gov.au,n,n,0,r,r,z,z >vic.gov.au -> vic.gov.au,n,n,0,r,r,z,z >wa.gov.au -> wa.gov.au,n,n,0,r,r,z,z >gov.az -> gov.az,r,r,100,s,s,z,z >gov.bh -> gov.bh,n,n,0,r,r,z,z >gov.bm -> gov.bm,n,n,0,r,r,z,z >gob.bo -> gob.bo,n,n,100,r,r,z,z >ac.gov.br -> ac.gov.br,r,r,100,s,s,z,z >df.gov.br -> df.gov.br,n,n,0,r,r,z,z >ma.gov.br -> ma.gov.br,n,n,0,r,r,z,z >ms.gov.br -> ms.gov.br,n,n,0,r,r,z,z >pe.gov.br -> pe.gov.br,r,r,100,r,r,z,z >pr.gov.br -> pr.gov.br,r,n,0,r,r,z,z >rj.gov.br -> rj.gov.br,n,n,0,r,r,z,z >rn.gov.br -> rn.gov.br,q,q,0,r,r,z,z >rs.gov.br -> rs.gov.br,n,n,10,r,r,z,z >sp.gov.br -> sp.gov.br,n,n,100,r,r,z,z >to.gov.br -> to.gov.br,q,q,0,r,r,z,z >gov.bt -> gov.bt,r,r,0,r,r,z,z >gov.by -> gov.by,r,n,0,s,s,z,z >mil.by -> mil.by,r,r,0,r,r,z,z >gc.ca -> gc.ca,n,n,0,r,r,z,z >gouv.ci -> gouv.ci,q,q,0,r,r,z,z >gob.cl -> gob.cl,n,n,0,r,r,z,z >gov.cl -> gov.cl,n,n,0,r,r,z,z >riik.ee -> riik.ee,q,n,100,r,r,z,z >eun.eg -> eun.eg,n,n,0,r,r,z,z >cci.fr -> cci.fr,n,n,0,r,r,z,z >huissier-justice.fr -> huissier-justice.fr,n,n,0,r,r,z,z >notaires.fr -> notaires.fr,n,n,0,r,r,z,z >gov.gd -> gov.gd,r,r,0,r,r,z,z >gov -> gov,r,n,0,r,r,y,r >my.id -> my.id,q,q,0,r,r,z,z >gov.il -> gov.il,n,n,100,r,r,z,z >nic.in -> nic.in,n,n,0,r,r,z,z >gov.in -> gov.in,q,n,0,r,r,z,z >edu.kz -> edu.kz,n,n,0,r,r,z,z >ac.lk -> ac.lk,n,n,0,r,r,z,z >edu.me -> edu.me,q,q,0,r,r,z,z >ac.me -> ac.me,q,q,100,r,r,z,z >gov.mg -> gov.mg,r,r,100,r,r,z,z >mil -> mil,r,n,0,r,r,y,r >gouv.ml -> gouv.ml,q,q,5,r,r,z,z >gov.mn -> gov.mn,r,r,0,r,r,z,z >edu.mn -> edu.mn,r,r,0,s,s,z,z >pro.mv -> pro.mv,n,n,0,r,r,z,z >info.na -> info.na,q,q,1,r,r,z,z >mil.no -> mil.no,n,n,0,r,r,z,z >stat.no -> stat.no,n,n,0,r,r,z,z >gov.pn -> gov.pn,n,n,0,r,r,z,z >gov.ps -> gov.ps,q,q,100,r,r,z,z >sec.ps -> sec.ps,q,q,100,r,r,z,z >gov.sc -> gov.sc,n,n,100,r,r,z,z >gov.sg -> gov.sg,r,r,0,r,r,z,r >gouv.sn -> gouv.sn,n,n,10,r,r,z,z >gob.sv -> gob.sv,n,n,100,r,r,z,z >net.sy -> net.sy,q,q,0,r,r,z,z >tsk.tr -> tsk.tr,q,q,0,r,r,z,z >gov.tt -> gov.tt,q,q,0,r,r,z,z >mil.tw -> mil.tw,n,n,0,r,r,z,z >km.ua -> km.ua,n,n,100,r,r,z,z >gov.uk -> gov.uk,r,n,0,s,s,z,r >nhs.uk -> nhs.uk,r,n,0,s,s,z,z >police.uk -> police.uk,n,n,0,s,s,z,z >k12.dc.us -> k12.dc.us,n,n,0,r,r,z,z >k12.in.us -> k12.in.us,q,n,0,r,r,z,z >k12.tn.us -> k12.tn.us,q,n,0,r,r,z,z >k12.wa.us -> k12.wa.us,n,n,100,r,r,z,z >agric.za -> agric.za,q,q,30,r,r,z,z >grondar.za -> grondar.za,n,n,0,r,r,z,z >nom.za -> nom.za,n,n,0,r,r,z,z 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. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree Walk impact
On Mon 16/Oct/2023 20:00:00 +0200 Scott Kitterman wrote: On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely 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 qld.gov.au -> qld.gov.au,n,n,0,r,r,z,z sa.gov.au -> sa.gov.au,n,n,0,r,r,z,z vic.gov.au -> vic.gov.au,n,n,0,r,r,z,z wa.gov.au -> wa.gov.au,n,n,0,r,r,z,z gov.az -> gov.az,r,r,100,s,s,z,z gov.bh -> gov.bh,n,n,0,r,r,z,z gov.bm -> gov.bm,n,n,0,r,r,z,z gob.bo -> gob.bo,n,n,100,r,r,z,z ac.gov.br -> ac.gov.br,r,r,100,s,s,z,z df.gov.br -> df.gov.br,n,n,0,r,r,z,z ma.gov.br -> ma.gov.br,n,n,0,r,r,z,z ms.gov.br -> ms.gov.br,n,n,0,r,r,z,z pe.gov.br -> pe.gov.br,r,r,100,r,r,z,z pr.gov.br -> pr.gov.br,r,n,0,r,r,z,z rj.gov.br -> rj.gov.br,n,n,0,r,r,z,z rn.gov.br -> rn.gov.br,q,q,0,r,r,z,z rs.gov.br -> rs.gov.br,n,n,10,r,r,z,z sp.gov.br -> sp.gov.br,n,n,100,r,r,z,z to.gov.br -> to.gov.br,q,q,0,r,r,z,z gov.bt -> gov.bt,r,r,0,r,r,z,z gov.by -> gov.by,r,n,0,s,s,z,z mil.by -> mil.by,r,r,0,r,r,z,z gc.ca -> gc.ca,n,n,0,r,r,z,z gouv.ci -> gouv.ci,q,q,0,r,r,z,z gob.cl -> gob.cl,n,n,0,r,r,z,z gov.cl -> gov.cl,n,n,0,r,r,z,z riik.ee -> riik.ee,q,n,100,r,r,z,z eun.eg -> eun.eg,n,n,0,r,r,z,z cci.fr -> cci.fr,n,n,0,r,r,z,z huissier-justice.fr -> huissier-justice.fr,n,n,0,r,r,z,z notaires.fr -> notaires.fr,n,n,0,r,r,z,z gov.gd -> gov.gd,r,r,0,r,r,z,z gov -> gov,r,n,0,r,r,y,r my.id -> my.id,q,q,0,r,r,z,z gov.il -> gov.il,n,n,100,r,r,z,z nic.in -> nic.in,n,n,0,r,r,z,z gov.in -> gov.in,q,n,0,r,r,z,z edu.kz -> edu.kz,n,n,0,r,r,z,z ac.lk -> ac.lk,n,n,0,r,r,z,z edu.me -> edu.me,q,q,0,r,r,z,z ac.me -> ac.me,q,q,100,r,r,z,z gov.mg -> gov.mg,r,r,100,r,r,z,z mil -> mil,r,n,0,r,r,y,r gouv.ml -> gouv.ml,q,q,5,r,r,z,z gov.mn -> gov.mn,r,r,0,r,r,z,z edu.mn -> edu.mn,r,r,0,s,s,z,z pro.mv -> pro.mv,n,n,0,r,r,z,z info.na -> info.na,q,q,1,r,r,z,z mil.no -> mil.no,n,n,0,r,r,z,z stat.no -> stat.no,n,n,0,r,r,z,z gov.pn -> gov.pn,n,n,0,r,r,z,z gov.ps -> gov.ps,q,q,100,r,r,z,z sec.ps -> sec.ps,q,q,100,r,r,z,z gov.sc -> gov.sc,n,n,100,r,r,z,z gov.sg -> gov.sg,r,r,0,r,r,z,r gouv.sn -> gouv.sn,n,n,10,r,r,z,z gob.sv -> gob.sv,n,n,100,r,r,z,z net.sy -> net.sy,q,q,0,r,r,z,z tsk.tr -> tsk.tr,q,q,0,r,r,z,z gov.tt -> gov.tt,q,q,0,r,r,z,z mil.tw -> mil.tw,n,n,0,r,r,z,z km.ua -> km.ua,n,n,100,r,r,z,z gov.uk -> gov.uk,r,n,0,s,s,z,r nhs.uk -> nhs.uk,r,n,0,s,s,z,z police.uk -> police.uk,n,n,0,s,s,z,z k12.dc.us -> k12.dc.us,n,n,0,r,r,z,z k12.in.us -> k12.in.us,q,n,0,r,r,z,z k12.tn.us -> k12.tn.us,q,n,0,r,r,z,z k12.wa.us -> k12.wa.us,n,n,100,r,r,z,z agric.za -> agric.za,q,q,30,r,r,z,z grondar.za -> grondar.za,n,n,0,r,r,z,z nom.za -> nom.za,n,n,0,r,r,z,z Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
