Re: [dmarc-ietf] Tree Walk impact

[Barry Leiba]

> The point of the Tree Walk was to detect and prevent the problems caused by 
> PSL errors.

The point of the tree walk was twofold:
1. To eliminate the PSL in DMARC, as the PSL was not designed to be
used by DMARC and has problems in its application to DMARC as a
result.
2. To provide a mechanism for domains to be explicit about what they
want, when that explicitness is needed.

I believe we have consensus that we have accomplished both of those.
If someone can show that in the process we have made the existing
situation significantly worse, we need to consider the implications of
that.  I don't believe we're in that state now.  We knew that there
would be differences for a small portion of domains.  In some cases
those differences are good, as they better reflect what's intended,
and perhaps in some cases the differences are neutral (neither
mechanism gives the answer we really should be getting).

For cases where the differences are worse -- the PSL reflected what
was intended and the tree walk does not -- the domains in question
need to apply (2) above, and it would be great if we could do some
outreach to those domain to suggest that they update their DMARC
records accordingly.

I don't think that any of this is, with the data we have now, at the
level that it merits reconsideration of switching to the tree walk.

Barry

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Douglas Foster]

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  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 
> 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 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

Re: [dmarc-ietf] Tree Walk impact

[Seth Blank]

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] Tree Walk impact

[Scott Kitterman]

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

[Alessandro Vesely]

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

[Scott Kitterman]

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

[Alessandro Vesely]

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

Re: [dmarc-ietf] Tree Walk impact

[Douglas Foster]

Neil, this is a delayed reply to your earlier email about my implementation
efforts, and whether I am on-board with the Tree Walk.   The response has
been delayed while I investigated the algorithm.

I began by building a cache of DMARC policies using the PSL and my mail
stream as input.

The first thing that jumped out was the DNS results of "timeout" (or
"Server failed").   After several re-runs, I have the list of recurring
problems down to 87 domains (79 from the PSL and 8 from my list).  I
envision a real performance bottleneck if timeouts occur in high volume due
to a concentration of messages on a specific DNS server.

To avoid timeouts and obtain other benefits, I concluded that a
database-based cache is necessary.   I envision using database cache
lifetimes that are much longer than DNS TTLs, probably at least a week.
 This avoids the performance risk associated with short TTLs in DNS.   It
also provides a framework for configuring overrides, such as to correct a
policy that specifies strict alignment when the actual messages from the
domain require relaxed alignment.

The resulting code requires a dance:
(1) check for a result using the cache,
(2)  Return a success result if all path elements are in the database and
those entries have not expired.  Otherwise, return a cache failure.
(3) On cache failure, walk the tree to reload the cache, then
(4) requery the cache to get a final result.
(5) repeat for each DKIM domain, as well as the mail from domain and
message from domain.
(6) Exit when a domain check produces a final result.

Some domains, especially TLDs, could be given a long cache life to avoid
repeated queries for unchanging data, but then the cache protocol needs to
provide feedback on the portion of the domain path that needs to be
re-queried, which adds complexity.  Overall, this algorithm feels like an
order of magnitude more difficult to write and to use than the PSL lookup.

When the tree walk cache works, the result will be a database of domains,
with indicators of whether the domain has a policy or not, and the policy
contents when one exists.   Scaling becomes the next concern.   Because we
are tracking descendent paths from PSL entries, rather than PSL entries
themselves, the database size will be multiple orders of magnitude larger
than the PSL table.   The cache size can be contained by reducing cache
life and increasing garbage collection, but the cache reduction reduces
filtering performance and garbage collection increases general overhead.

In short, I conclude that the Tree Walk has a very large cost for the
comparatively small benefit of avoiding specific PSL errors.   But fixing
PSL errors is still desirable, so another approach is needed.

What makes more sense is to collect domain lists from the email logs,
possibly supplemented from other sources.  Then perform Tree Walks in a
background process.  The background process would identify domains where
the Tree Walk produces a different result than the PSL, so that the
difference can be investigated and the local-copy PSL corrected.Perhaps
some web service will even do the work and publish results to its clients
or the whole web.

As a batch algorithm, the Tree Walk has potential.   As a real-time
algorithm, the Tree Walk algorithm seems like a poor fit.

Doug Foster


On Fri, Oct 13, 2023 at 3:29 PM Neil Anuskiewicz 
wrote:

> If I read that right it gives you what you think is a desirable outcome.
> That is, this might be a strong sign that you’re at least considering
> supporting DMARCbis!
>
> Yes, we all need to be prepared for headaches no matter which direction
> this all goes.
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Scott Kitterman]

On October 16, 2023 9:20:26 PM UTC, Neil Anuskiewicz 
 wrote:
>
>
>> On Oct 16, 2023, at 11:00 AM, 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)?
>> 
>> Scott K
>
>Are TLD’s typically responsive to these sorts of requests? Do they each have 
>to be sold on the idea?

It was mostly a rhetorical question.  I'm reasonably confident that no such 
TLDs exist.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Neil Anuskiewicz]

> On Oct 16, 2023, at 11:00 AM, 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)?
> 
> Scott K
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

Are TLD’s typically responsive to these sorts of requests? Do they each have to 
be sold on the idea?

Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Scott Kitterman]

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)?

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Alessandro Vesely]

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?

Best
Ale
--



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Neil Anuskiewicz]

If I read that right it gives you what you think is a desirable outcome. That is, this might be a strong sign that you’re at least considering supporting DMARCbis!Yes, we all need to be prepared for headaches no matter which direction this all goes.On Oct 13, 2023, at 3:59 AM, Douglas Foster  wrote:The first step in my research has been to do DMARC policy lookups on the PSL domains   About 400 of them have DMARC policies.  A super-majority specify relaxed authentication without specifying a NP policy.   This indicates that the policy was created before the PSD for DMARC spec.   I conclude that these domains want to be treated as organizations, not PSOs, and tbe stop-last Tree Walk will enable what they have been wanting.DougOn Fri, Oct 13, 2023, 1:06 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:

> On Oct 10, 2023, at 11:57 AM, Alessandro Vesely  wrote:
> 
> On Tue 10/Oct/2023 19:16:10 +0200 Todd Herr wrote:
>>> On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely  wrote:
>>> On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote:
 Both approaches have problems.   Stop-at-last enables the walk to exit the current organization and stop on a private registry, for both alignment evaluation and for aggregate report transmission.   This is not a minor problem, even if it is arguably infrequent.
>>> 
>>> The illustrative example in the draft says:
>>> 
>>> _dmarc.a.b.c.d.e.mail.example.com
>>> _dmarc.e.mail.example.com
>>> _dmarc.mail.example.com
>>> _dmarc.example.com
>>> _dmarc.com
>>> 
>>> That is, no stop at all.  In this respect, a psd=n at example.com would save a lookup.  However, it is not something that we can recommend, after we chose the obscure tag name. >
>> I'm not sure I understand what you're saying...
>> The illustrative example cited is intended to illustrate a full tree walk
>> that follows the steps for a full tree walk that are spelled out in the
>> numbered list just prior to the illustrative example.
> 
> 
> Yup, I'm not criticizing the text (I wouldn't know how to better it).
> 
> Just wondering how to implement it.  It is understood that programs must behave /as if/ they followed the letter of the spec, but don't have to actually do so.

Would it be possible to test these scenarios with a working prototype or some other way to provide proof. Due to other obligations I haven’t been able to lurk here much but upon coming back I think the tree walk issues touched on today are possibly the only things standing in the way of dmarcbis. Though I saw there’s a nascent save our PSL movement that I read about. I’m not sure how serious or influential this movement is and why they’d feel so strongly that they’d step in with somewhat dubious play reviews on the 10 yard line. 

I’m just an observer.

I’d be shocked if DMARCbis to emerge perfect and triumphant. I expect problems will be addressed, there’s going to be stress, but ultimately another hack such as the hosts file for DNS will become largely irrelevant in the big picture, taking the Internet another step out of childhood toward adulthood. That’s a good thing even if some things go wrong along the way that need to be fixed or mitigated. The Internet is a place where the perfect is often more blatantly the enemy of the good.

Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Neil Anuskiewicz]

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.On Oct 13, 2023, at 6:50 AM, Douglas Foster  wrote:Neil, the list is attached. .I used "Z" in the PSD and NP columns to indicate "not specified".   For the other columns, defaults have been inserted.Since everybody has their own copy of the PSL, others may find minor variants of this data.Doug FosterOn Fri, Oct 13, 2023 at 7:18 AM Neil Anuskiewicz  wrote:

> On Oct 13, 2023, at 3:59 AM, Douglas Foster  wrote:
> 
> 
> The first step in my research has been to do DMARC policy lookups on the PSL domains   About 400 of them have DMARC policies.  A super-majority specify relaxed authentication without specifying a NP policy.   This indicates that the policy was created before the PSD for DMARC spec.   I conclude that these domains want to be treated as organizations, not PSOs, and tbe stop-last Tree Walk will enable what they have been wanting.

Doug, you’re saying there’s 400? That means anyone of us or, better, several of us could make calls to talk to a representative sample. We’d then greatly improve our knowledge of both the concerns and wants of this set of domain operators. Then you’d be in a better position to understand what they want and that, of course, can’t help but influence your decisions. The low numbers at this stage make getting the basic data much easier. 

Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Douglas Foster]

Neil, the list is attached. .
I used "Z" in the PSD and NP columns to indicate "not specified".   For the
other columns, defaults have been inserted.

Since everybody has their own copy of the PSL, others may find minor
variants of this data.

Doug Foster

On Fri, Oct 13, 2023 at 7:18 AM Neil Anuskiewicz 
wrote:

>
>
> > On Oct 13, 2023, at 3:59 AM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> >
> > 
> > The first step in my research has been to do DMARC policy lookups on the
> PSL domains   About 400 of them have DMARC policies.  A super-majority
> specify relaxed authentication without specifying a NP policy.   This
> indicates that the policy was created before the PSD for DMARC spec.   I
> conclude that these domains want to be treated as organizations, not PSOs,
> and tbe stop-last Tree Walk will enable what they have been wanting.
>
> Doug, you’re saying there’s 400? That means anyone of us or, better,
> several of us could make calls to talk to a representative sample. We’d
> then greatly improve our knowledge of both the concerns and wants of this
> set of domain operators. Then you’d be in a better position to understand
> what they want and that, of course, can’t help but influence your
> decisions. The low numbers at this stage make getting the basic data much
> easier.
>
> Neil


PSL entries with DMARC policies.xlsx
Description: MS-Excel 2007 spreadsheet
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Neil Anuskiewicz]

> On Oct 13, 2023, at 3:59 AM, Douglas Foster 
>  wrote:
> 
> 
> The first step in my research has been to do DMARC policy lookups on the PSL 
> domains   About 400 of them have DMARC policies.  A super-majority specify 
> relaxed authentication without specifying a NP policy.   This indicates that 
> the policy was created before the PSD for DMARC spec.   I conclude that these 
> domains want to be treated as organizations, not PSOs, and tbe stop-last Tree 
> Walk will enable what they have been wanting.

Doug, you’re saying there’s 400? That means anyone of us or, better, several of 
us could make calls to talk to a representative sample. We’d then greatly 
improve our knowledge of both the concerns and wants of this set of domain 
operators. Then you’d be in a better position to understand what they want and 
that, of course, can’t help but influence your decisions. The low numbers at 
this stage make getting the basic data much easier. 

Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Douglas Foster]

The first step in my research has been to do DMARC policy lookups on the
PSL domains   About 400 of them have DMARC policies.  A super-majority
specify relaxed authentication without specifying a NP policy.   This
indicates that the policy was created before the PSD for DMARC spec.   I
conclude that these domains want to be treated as organizations, not PSOs,
and tbe stop-last Tree Walk will enable what they have been wanting.

Doug

On Fri, Oct 13, 2023, 1:06 AM Neil Anuskiewicz  wrote:

>
>
> > On Oct 10, 2023, at 11:57 AM, Alessandro Vesely  wrote:
> >
> > On Tue 10/Oct/2023 19:16:10 +0200 Todd Herr wrote:
> >>> On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely 
> wrote:
> >>> On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote:
>  Both approaches have problems.   Stop-at-last enables the walk to
> exit the current organization and stop on a private registry, for both
> alignment evaluation and for aggregate report transmission.   This is not a
> minor problem, even if it is arguably infrequent.
> >>>
> >>> The illustrative example in the draft says:
> >>>
> >>> _dmarc.a.b.c.d.e.mail.example.com
> >>> _dmarc.e.mail.example.com
> >>> _dmarc.mail.example.com
> >>> _dmarc.example.com
> >>> _dmarc.com
> >>>
> >>> That is, no stop at all.  In this respect, a psd=n at example.com
> would save a lookup.  However, it is not something that we can recommend,
> after we chose the obscure tag name. >
> >> I'm not sure I understand what you're saying...
> >> The illustrative example cited is intended to illustrate a full tree
> walk
> >> that follows the steps for a full tree walk that are spelled out in the
> >> numbered list just prior to the illustrative example.
> >
> >
> > Yup, I'm not criticizing the text (I wouldn't know how to better it).
> >
> > Just wondering how to implement it.  It is understood that programs must
> behave /as if/ they followed the letter of the spec, but don't have to
> actually do so.
>
> Would it be possible to test these scenarios with a working prototype or
> some other way to provide proof. Due to other obligations I haven’t been
> able to lurk here much but upon coming back I think the tree walk issues
> touched on today are possibly the only things standing in the way of
> dmarcbis. Though I saw there’s a nascent save our PSL movement that I read
> about. I’m not sure how serious or influential this movement is and why
> they’d feel so strongly that they’d step in with somewhat dubious play
> reviews on the 10 yard line.
>
> I’m just an observer.
>
> I’d be shocked if DMARCbis to emerge perfect and triumphant. I expect
> problems will be addressed, there’s going to be stress, but ultimately
> another hack such as the hosts file for DNS will become largely irrelevant
> in the big picture, taking the Internet another step out of childhood
> toward adulthood. That’s a good thing even if some things go wrong along
> the way that need to be fixed or mitigated. The Internet is a place where
> the perfect is often more blatantly the enemy of the good.
>
> Neil
> ___
> 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] Tree Walk impact

[Neil Anuskiewicz]

I’d say it’s best practice to have a separate policy subdomains. We should encourage it.foo.example.com’s spoofed by one vendor most likely, so switching vendors isn’t too big a task. No need to roll example.com back to none. Just role foo back. It’s clearly a better way to go. Set things up so when you make changes, you open up a tiny security hole for as short a time as possible. So if dmarcbis exncourages subdomain dmarc policies then let’s encourage that with clear words and clear policies.On Oct 7, 2023, at 11:44 AM, Douglas Foster  wrote:No, this is not a false positive.  The PSL put all of the identifiers in a 2LD organization, which I reviewed and judged to be correct.The problem happens when Mail From u...@bounce.example.com authenticates u...@example.com and both domains have DMARC policies.  Removing the lower policy is the only remedy.   For SPF, this pattern of child-authenticates-parent is quite common.  Hsving multipke DMARC policies is less common. Again, what previous data was presented to justify the consensus that we would see no probems? DougOn Sat, Oct 7, 2023, 1:26 PM Richard Clayton  wrote:-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message 
hgv...@mail.gmail.com>, Douglas Foster 
com> writes

>    So initially, I am asking for a compsrison between my results and 
>    the data used to justify the asserted consensus.

if you published the data (just the right hand side of relevant
addresses is needed) we could check your working ...

>    Was 2% previuosly observed and judged acceptable?  Were the 
>    previous error rates judged acceptable because they were computed 
>    using a different denominator definition?

clearly if you get 10 messages from odd-domain and 10 messages from
Google then you will see a different percentage than someone who gets 3
(or some days 0) messages from odd-domain and 100 from Google ...
but provided odd-domain isn't just sending to you then any large mailbox
provider should have seen enough mail to provide a sensible measure of
the impact by counting domains not %age of overall mail.

>    With our present design, the necessary response to these errors is 
>    for the domain owner to remove intermediate DMARC policies.

that's strange ... isn't the intent of the new scheme to encourage
subdomain owners to add them !

I do wonder if this is the PSL raising its ugly head again. A remarkable
number of the people who have added entries have not understood how they
now need to publish rather more DNS records than previously ...

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZSGUTN2nQQHFxEViEQKHpQCeP4SAEJFQbCG74hSpmKPugIWLWs0An2e5
DMtrmcDBziCPFM9PVB0Vx6dI
=aCqk
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Neil Anuskiewicz]

> On Oct 10, 2023, at 11:57 AM, Alessandro Vesely  wrote:
> 
> On Tue 10/Oct/2023 19:16:10 +0200 Todd Herr wrote:
>>> On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely  wrote:
>>> On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote:
 Both approaches have problems.   Stop-at-last enables the walk to exit the 
 current organization and stop on a private registry, for both alignment 
 evaluation and for aggregate report transmission.   This is not a minor 
 problem, even if it is arguably infrequent.
>>> 
>>> The illustrative example in the draft says:
>>> 
>>> _dmarc.a.b.c.d.e.mail.example.com
>>> _dmarc.e.mail.example.com
>>> _dmarc.mail.example.com
>>> _dmarc.example.com
>>> _dmarc.com
>>> 
>>> That is, no stop at all.  In this respect, a psd=n at example.com would 
>>> save a lookup.  However, it is not something that we can recommend, after 
>>> we chose the obscure tag name. >
>> I'm not sure I understand what you're saying...
>> The illustrative example cited is intended to illustrate a full tree walk
>> that follows the steps for a full tree walk that are spelled out in the
>> numbered list just prior to the illustrative example.
> 
> 
> Yup, I'm not criticizing the text (I wouldn't know how to better it).
> 
> Just wondering how to implement it.  It is understood that programs must 
> behave /as if/ they followed the letter of the spec, but don't have to 
> actually do so.

Would it be possible to test these scenarios with a working prototype or some 
other way to provide proof. Due to other obligations I haven’t been able to 
lurk here much but upon coming back I think the tree walk issues touched on 
today are possibly the only things standing in the way of dmarcbis. Though I 
saw there’s a nascent save our PSL movement that I read about. I’m not sure how 
serious or influential this movement is and why they’d feel so strongly that 
they’d step in with somewhat dubious play reviews on the 10 yard line. 

I’m just an observer.

I’d be shocked if DMARCbis to emerge perfect and triumphant. I expect problems 
will be addressed, there’s going to be stress, but ultimately another hack such 
as the hosts file for DNS will become largely irrelevant in the big picture, 
taking the Internet another step out of childhood toward adulthood. That’s a 
good thing even if some things go wrong along the way that need to be fixed or 
mitigated. The Internet is a place where the perfect is often more blatantly 
the enemy of the good.

Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Alessandro Vesely]

On Tue 10/Oct/2023 19:16:10 +0200 Todd Herr wrote:

On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely  wrote:

On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote:
Both approaches have problems.   Stop-at-last enables the walk to exit the 
current organization and stop on a private registry, for both alignment 
evaluation and for aggregate report transmission.   This is not a minor 
problem, even if it is arguably infrequent.


The illustrative example in the draft says:

_dmarc.a.b.c.d.e.mail.example.com
_dmarc.e.mail.example.com
_dmarc.mail.example.com
_dmarc.example.com
_dmarc.com

That is, no stop at all.  In this respect, a psd=n at example.com would 
save a lookup.  However, it is not something that we can recommend, after 
we chose the obscure tag name. >

I'm not sure I understand what you're saying...

The illustrative example cited is intended to illustrate a full tree walk
that follows the steps for a full tree walk that are spelled out in the
numbered list just prior to the illustrative example.



Yup, I'm not criticizing the text (I wouldn't know how to better it).

Just wondering how to implement it.  It is understood that programs must behave 
/as if/ they followed the letter of the spec, but don't have to actually do so.



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Todd Herr]

On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely  wrote:

> On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote:
> > Both approaches have problems.   Stop-at-last enables the walk to exit
> the
> > current organization and stop on a private registry, for both alignment
> > evaluation and for aggregate report transmission.   This is not a minor
> > problem, even if it is arguably infrequent.
>
>
> The illustrative example in the draft says:
>
> _dmarc.a.b.c.d.e.mail.example.com
> _dmarc.e.mail.example.com
> _dmarc.mail.example.com
> _dmarc.example.com
> _dmarc.com
>
> That is, no stop at all.  In this respect, a psd=n at example.com would
> save a
> lookup.  However, it is not something that we can recommend, after we
> chose the
> obscure tag name.
>
> I'm not sure I understand what you're saying...

The illustrative example cited is intended to illustrate a full tree walk
that follows the steps for a full tree walk that are spelled out in the
numbered list just prior to the illustrative example.

That numbered list includes conditional stops (i.e., if one record is found
with the specified condition, stop) in steps 2 and 7.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Alessandro Vesely]

On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote:
Both approaches have problems.   Stop-at-last enables the walk to exit the 
current organization and stop on a private registry, for both alignment 
evaluation and for aggregate report transmission.   This is not a minor 
problem, even if it is arguably infrequent.



The illustrative example in the draft says:

_dmarc.a.b.c.d.e.mail.example.com
_dmarc.e.mail.example.com
_dmarc.mail.example.com
_dmarc.example.com
_dmarc.com

That is, no stop at all.  In this respect, a psd=n at example.com would save a 
lookup.  However, it is not something that we can recommend, after we chose the 
obscure tag name.


For implementation, it might be faster and politer to lookup .com in the strict 
PSL (ICANN domains) than querying _dmarc.com.  If you have a dedicated caching 
DNS, .com SOA min TTL is 86400, so the empty _dmarc.com stays there for the 
whole day and the local DNS might be quicker.  Yet, I'd keep comparing with the 
PSL, at least for an initial period.


Certainly one is not going to re-start the tree walk from scratch for each 
authorizing domain.


I'll try coding that in the next but one zdkimfilter release.  (Will that still 
be before DMARCbis publication?)



Best
Ale
--



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Scott Kitterman]

Thanks for confirming that your list of "problem domains" was not based on the 
tree walk design in the draft.

There's been no discussion of the how and the why of the design the design 
other than on the list.  I'm also mystified how it's possible you don't know.

Scott K

On October 9, 2023 10:19:56 PM UTC, Douglas Foster 
 wrote:
>Great question.   On Feb 23rd, I had this exchange which John settled:
>It appears that Douglas Foster   said:
>
>>-=-=-=-=-=-
>>
>>I seem to have missed this redesign.   I thought the plan had always been
>>to take the top-most policy not flagged as PSD=Y.
>
>
>The current design has been in the draft since October, and we discussed
>it on this list at great length.
>
>
>R's,
>John
>
>Today, re-reading draft version 28, it says to use the top version.   I
>missed when stop-first was chosen "after discussion at great length", and I
>also seem to have missed the decision to switch back, presumably after
>equally vigorous discussion?
>
>Both approaches have problems.   Stop-at-last enables the walk to exit the
>current organization and stop on a private registry, for both alignment
>evaluation and for aggregate report transmission.   This is not a minor
>problem, even if it is arguably infrequent.
>
>Given that the problem with PSL is imperfect data, the solution is better
>data.   Instead we have chosen a heuristic, and consequently we can be
>certain of heuristic-induced harm.   We should give domain owners full
>control over their organizational boundary, and stop guessing.
>
>Doug Foster
>
>
>
>
>
>On Mon, Oct 9, 2023 at 9:00 AM Scott Kitterman  wrote:
>
>> Where does it say to stop at the first policy found?
>>
>> Scott K
>>
>> On October 9, 2023 12:51:33 PM UTC, Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>> >Right, but we walk up from both domains separately, and each walk stops at
>> >the first policy found.  Since the two walks stop at different policies,
>> >they are presuned to be different organizations.
>> >
>> >Doug
>> >
>> >
>> >On Mon, Oct 9, 2023, 5:35 AM Alessandro Vesely  wrote:
>> >
>> >> On Sun 08/Oct/2023 04:00:31 +0200 Douglas Foster wrote:
>> >> > Attached it is a spreadsheet with the problems from my data set.
>> >>
>> >> I see no blocking.  For example, the list shows From: bayer.com,
>> >> d=crm.bayer.com, the latter deemed blocking.  Both domains feature a
>> >> DMARC
>> >> record and (unsurprisingly) none has a psd= tag.
>> >>
>> >> According to the spec, one should look up:
>> >> _dmarc.bayer.com
>> >> _dmarc.com
>> >>
>> >> And then
>> >> _dmarc.crm.bayer.com
>> >> _dmarc.bayer.com
>> >> _dmarc.com
>> >>
>> >> The organizational domain is bayer.com and they are aligned.  No
>> blocking.
>> >>
>> >> Best
>> >> Ale
>> >> --
>> >>
>> >>
>> >>
>> >> ___
>> >> 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

Re: [dmarc-ietf] Tree Walk impact

[Douglas Foster]

Great question.   On Feb 23rd, I had this exchange which John settled:
It appears that Douglas Foster   said:

>-=-=-=-=-=-
>
>I seem to have missed this redesign.   I thought the plan had always been
>to take the top-most policy not flagged as PSD=Y.


The current design has been in the draft since October, and we discussed
it on this list at great length.


R's,
John

Today, re-reading draft version 28, it says to use the top version.   I
missed when stop-first was chosen "after discussion at great length", and I
also seem to have missed the decision to switch back, presumably after
equally vigorous discussion?

Both approaches have problems.   Stop-at-last enables the walk to exit the
current organization and stop on a private registry, for both alignment
evaluation and for aggregate report transmission.   This is not a minor
problem, even if it is arguably infrequent.

Given that the problem with PSL is imperfect data, the solution is better
data.   Instead we have chosen a heuristic, and consequently we can be
certain of heuristic-induced harm.   We should give domain owners full
control over their organizational boundary, and stop guessing.

Doug Foster





On Mon, Oct 9, 2023 at 9:00 AM Scott Kitterman  wrote:

> Where does it say to stop at the first policy found?
>
> Scott K
>
> On October 9, 2023 12:51:33 PM UTC, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> >Right, but we walk up from both domains separately, and each walk stops at
> >the first policy found.  Since the two walks stop at different policies,
> >they are presuned to be different organizations.
> >
> >Doug
> >
> >
> >On Mon, Oct 9, 2023, 5:35 AM Alessandro Vesely  wrote:
> >
> >> On Sun 08/Oct/2023 04:00:31 +0200 Douglas Foster wrote:
> >> > Attached it is a spreadsheet with the problems from my data set.
> >>
> >> I see no blocking.  For example, the list shows From: bayer.com,
> >> d=crm.bayer.com, the latter deemed blocking.  Both domains feature a
> >> DMARC
> >> record and (unsurprisingly) none has a psd= tag.
> >>
> >> According to the spec, one should look up:
> >> _dmarc.bayer.com
> >> _dmarc.com
> >>
> >> And then
> >> _dmarc.crm.bayer.com
> >> _dmarc.bayer.com
> >> _dmarc.com
> >>
> >> The organizational domain is bayer.com and they are aligned.  No
> blocking.
> >>
> >> Best
> >> Ale
> >> --
> >>
> >>
> >>
> >> ___
> >> 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

Re: [dmarc-ietf] Tree Walk impact

[Scott Kitterman]

Where does it say to stop at the first policy found?

Scott K

On October 9, 2023 12:51:33 PM UTC, Douglas Foster 
 wrote:
>Right, but we walk up from both domains separately, and each walk stops at
>the first policy found.  Since the two walks stop at different policies,
>they are presuned to be different organizations.
>
>Doug
>
>
>On Mon, Oct 9, 2023, 5:35 AM Alessandro Vesely  wrote:
>
>> On Sun 08/Oct/2023 04:00:31 +0200 Douglas Foster wrote:
>> > Attached it is a spreadsheet with the problems from my data set.
>>
>> I see no blocking.  For example, the list shows From: bayer.com,
>> d=crm.bayer.com, the latter deemed blocking.  Both domains feature a
>> DMARC
>> record and (unsurprisingly) none has a psd= tag.
>>
>> According to the spec, one should look up:
>> _dmarc.bayer.com
>> _dmarc.com
>>
>> And then
>> _dmarc.crm.bayer.com
>> _dmarc.bayer.com
>> _dmarc.com
>>
>> The organizational domain is bayer.com and they are aligned.  No blocking.
>>
>> Best
>> Ale
>> --
>>
>>
>>
>> ___
>> 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] Tree Walk impact

[Douglas Foster]

Right, but we walk up from both domains separately, and each walk stops at
the first policy found.  Since the two walks stop at different policies,
they are presuned to be different organizations.

Doug


On Mon, Oct 9, 2023, 5:35 AM Alessandro Vesely  wrote:

> On Sun 08/Oct/2023 04:00:31 +0200 Douglas Foster wrote:
> > Attached it is a spreadsheet with the problems from my data set.
>
> I see no blocking.  For example, the list shows From: bayer.com,
> d=crm.bayer.com, the latter deemed blocking.  Both domains feature a
> DMARC
> record and (unsurprisingly) none has a psd= tag.
>
> According to the spec, one should look up:
> _dmarc.bayer.com
> _dmarc.com
>
> And then
> _dmarc.crm.bayer.com
> _dmarc.bayer.com
> _dmarc.com
>
> The organizational domain is bayer.com and they are aligned.  No blocking.
>
> Best
> Ale
> --
>
>
>
> ___
> 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] Tree Walk impact

[Alessandro Vesely]

On Sun 08/Oct/2023 04:00:31 +0200 Douglas Foster wrote:

Attached it is a spreadsheet with the problems from my data set.


I see no blocking.  For example, the list shows From: bayer.com, 
d=crm.bayer.com, the latter deemed blocking.  Both domains feature a DMARC 
record and (unsurprisingly) none has a psd= tag.


According to the spec, one should look up:
_dmarc.bayer.com
_dmarc.com

And then
_dmarc.crm.bayer.com
_dmarc.bayer.com
_dmarc.com

The organizational domain is bayer.com and they are aligned.  No blocking.

Best
Ale
--



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Douglas Foster]

The 2% of messages statistic is probably the wrong measure.The
alternative measure is to examine the percentage of domain pairs that have
a result change.   Using that measure, we have

70 of 881 (7.9%) pairs change from "PASS using relaxed alignment" to "FAIL
because unaligned."
3 of 21 pairs change from "FAIL because relaxed alignment is present but
strict alignment is required" to "FAIL because unaligned"
7 of 235 pairs change from "NO POLICY with relaxed alignment" to "NO POLICY
and unaligned."

In total 80 of 1137 (7.0%) change to an inferior trust state.

Whether the best number is 7% or 7.9%, the error rate is too high to ignore.

Doug



On Sat, Oct 7, 2023 at 10:00 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Attached it is a spreadsheet with the problems from my data set.  If it is
> dropped during the forwarding process, let me know and I will re-post it in
> the body of the message.
>
> The WG needs to prove that "The Tree Walk will cause no significant
> disruption".We should have understood that trying to prove a negative
> is a very difficult undertaking.   Only one counterexample is needed to
> disprove the assumption, and there is a near-infinite number of
> counterexamples to be considered.   In this case, we embraced one favorable
> report, without obtaining additional data, and without even asking whether
> the mail stream used for testing is a plausible proxy for the general
> Internet.
>
> We do not need to speculate about "what the domain owner expected".   We
> can reliably assume that the domain owner expected his message to be
> evaluated by RFC 7489 rules using a correct PSL.   Did the Tree Walk
> actually expose any PSL errors?  If not, then the RFC 7489+PSL result is
> what was intended.
>
> One could postulate this approach to finding and fixing problems in the
> PSL:
> 1) Evaluate incoming messages using both PSL and Tree Walk.
> 2) When the two techniques produce different results, study the message,
> and consult other resources, to determine whether the PSL is correct or
> not.   If the conclusion is a PSL error, make the PSL correction and note
> the entry as verified.   If the Tree Walk result is in error, document that
> result as well.
> 3) Repeat for each new discrepancy between the two methods.
>
> My suspicion is that PSL errors will be very difficult to find by this
> method, because the PSL will be correct in the overwhelming majority of
> cases.   When the payback is infrequent, most evaluators will conclude that
> the labor investment is not sufficient to the benefits gained.
>
> I am not opposed to deprecating the PSL, just opposed to deprecating it
> with a one-sided redesign of the protocol, using rosy assumptions.   I do
> not want to create a clone of the mailing list problem.
>
> Doug
>
>
> On Sat, Oct 7, 2023 at 3:46 PM John Levine  wrote:
>
>> It appears that Richard Clayton   said:
>> >I do wonder if this is the PSL raising its ugly head again. A remarkable
>> >number of the people who have added entries have not understood how they
>> >now need to publish rather more DNS records than previously ...
>>
>> Definitely. In the few cases we've found where a tree walk would
>> provide a different result to the PSL, it is not clear which one the
>> domain owner expected.
>>
>> R's,
>> John
>>
>> ___
>> 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] Tree Walk impact

[Douglas Foster]

Attached it is a spreadsheet with the problems from my data set.  If it is
dropped during the forwarding process, let me know and I will re-post it in
the body of the message.

The WG needs to prove that "The Tree Walk will cause no significant
disruption".We should have understood that trying to prove a negative
is a very difficult undertaking.   Only one counterexample is needed to
disprove the assumption, and there is a near-infinite number of
counterexamples to be considered.   In this case, we embraced one favorable
report, without obtaining additional data, and without even asking whether
the mail stream used for testing is a plausible proxy for the general
Internet.

We do not need to speculate about "what the domain owner expected".   We
can reliably assume that the domain owner expected his message to be
evaluated by RFC 7489 rules using a correct PSL.   Did the Tree Walk
actually expose any PSL errors?  If not, then the RFC 7489+PSL result is
what was intended.

One could postulate this approach to finding and fixing problems in the PSL:
1) Evaluate incoming messages using both PSL and Tree Walk.
2) When the two techniques produce different results, study the message,
and consult other resources, to determine whether the PSL is correct or
not.   If the conclusion is a PSL error, make the PSL correction and note
the entry as verified.   If the Tree Walk result is in error, document that
result as well.
3) Repeat for each new discrepancy between the two methods.

My suspicion is that PSL errors will be very difficult to find by this
method, because the PSL will be correct in the overwhelming majority of
cases.   When the payback is infrequent, most evaluators will conclude that
the labor investment is not sufficient to the benefits gained.

I am not opposed to deprecating the PSL, just opposed to deprecating it
with a one-sided redesign of the protocol, using rosy assumptions.   I do
not want to create a clone of the mailing list problem.

Doug


On Sat, Oct 7, 2023 at 3:46 PM John Levine  wrote:

> It appears that Richard Clayton   said:
> >I do wonder if this is the PSL raising its ugly head again. A remarkable
> >number of the people who have added entries have not understood how they
> >now need to publish rather more DNS records than previously ...
>
> Definitely. In the few cases we've found where a tree walk would
> provide a different result to the PSL, it is not clear which one the
> domain owner expected.
>
> R's,
> John
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


Tree Walk Error Details.xlsx
Description: MS-Excel 2007 spreadsheet
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[John Levine]

It appears that Richard Clayton   said:
>I do wonder if this is the PSL raising its ugly head again. A remarkable
>number of the people who have added entries have not understood how they
>now need to publish rather more DNS records than previously ...

Definitely. In the few cases we've found where a tree walk would
provide a different result to the PSL, it is not clear which one the
domain owner expected.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Douglas Foster]

No, this is not a false positive.  The PSL put all of the identifiers in a
2LD organization, which I reviewed and judged to be correct.


The problem happens when Mail From u...@bounce.example.com authenticates
u...@example.com and both domains have DMARC policies.  Removing the lower
policy is the only remedy.   For SPF, this pattern of
child-authenticates-parent is quite common.  Hsving multipke DMARC policies
is less common.

Again, what previous data was presented to justify the consensus that we
would see no probems?

Doug

On Sat, Oct 7, 2023, 1:26 PM Richard Clayton  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message  hgv...@mail.gmail.com>, Douglas Foster  com> writes
>
> >So initially, I am asking for a compsrison between my results and
> >the data used to justify the asserted consensus.
>
> if you published the data (just the right hand side of relevant
> addresses is needed) we could check your working ...
>
> >Was 2% previuosly observed and judged acceptable?  Were the
> >previous error rates judged acceptable because they were computed
> >using a different denominator definition?
>
> clearly if you get 10 messages from odd-domain and 10 messages from
> Google then you will see a different percentage than someone who gets 3
> (or some days 0) messages from odd-domain and 100 from Google ...
> but provided odd-domain isn't just sending to you then any large mailbox
> provider should have seen enough mail to provide a sensible measure of
> the impact by counting domains not %age of overall mail.
>
> >With our present design, the necessary response to these errors is
> >for the domain owner to remove intermediate DMARC policies.
>
> that's strange ... isn't the intent of the new scheme to encourage
> subdomain owners to add them !
>
> I do wonder if this is the PSL raising its ugly head again. A remarkable
> number of the people who have added entries have not understood how they
> now need to publish rather more DNS records than previously ...
>
> - --
> richard   Richard Clayton
>
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
>
> -BEGIN PGP SIGNATURE-
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBZSGUTN2nQQHFxEViEQKHpQCeP4SAEJFQbCG74hSpmKPugIWLWs0An2e5
> DMtrmcDBziCPFM9PVB0Vx6dI
> =aCqk
> -END PGP SIGNATURE-
>
> ___
> 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] Tree Walk impact

[Douglas Foster]

I have seen assertions about the diffetential impact of Tree Walk, but no
specifics.  I don't know how I missed that information when it was shared

So initially, I am asking for a compsrison between my results and the data
used to justify the asserted consensus.

Was 2% previuosly observed and judged acceptable?  Were the previous error
rates judged acceptable because they were computed using a different
denominator definition?

With our present design, the necessary response to these errors is for the
domain owner to remove intermediate DMARC policies.  I know that I proposed
other mitigations which were rejected as unnecessary.  Given my results, I
think they are necessary.

Doug



On Fri, Oct 6, 2023, 8:58 PM Seth Blank  wrote:

> Doug, are you suggesting we relitigate consensus on this matter? That is a
> high bar we do not wish to undertake lightly.
>
> Seth, as Chair
>
> On Fri, Oct 6, 2023 at 19:49 Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> I have only recently implemented all of the tools needed to be able to
>> test PSL vs Tree Walk.
>>
>> I looked at messages which had passed reputation filtering and content
>> filtering, to isolate messages where DMARC alone could be determinative.
>>  Within that group, 75% of the messages did not need tree walk, either
>> because of strict alignment or no alignment.
>>
>> For the subset where relaxed alignment would be applicable, about  11%
>> had no policy, and 1.6% had false failures because the domain owner had
>> published strict alignment.
>>
>> For the subset where relaxed alignment was both specified and applicable,
>> the Tree Walk caused about 2% to switch from PASS to FAIL because the
>> domains being compared were incorrectly viewed as different organizations.
>>
>> Is this consistent with the previous research into this issue?
>>
>> Doug Foster
>> ___
>> 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] Tree Walk impact

[Seth Blank]

Doug, are you suggesting we relitigate consensus on this matter? That is a
high bar we do not wish to undertake lightly.

Seth, as Chair

On Fri, Oct 6, 2023 at 19:49 Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I have only recently implemented all of the tools needed to be able to
> test PSL vs Tree Walk.
>
> I looked at messages which had passed reputation filtering and content
> filtering, to isolate messages where DMARC alone could be determinative.
>  Within that group, 75% of the messages did not need tree walk, either
> because of strict alignment or no alignment.
>
> For the subset where relaxed alignment would be applicable, about  11% had
> no policy, and 1.6% had false failures because the domain owner had
> published strict alignment.
>
> For the subset where relaxed alignment was both specified and applicable,
> the Tree Walk caused about 2% to switch from PASS to FAIL because the
> domains being compared were incorrectly viewed as different organizations.
>
> Is this consistent with the previous research into this issue?
>
> Doug Foster
> ___
> 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-ietf] Tree Walk impact

[Douglas Foster]

I have only recently implemented all of the tools needed to be able to test
PSL vs Tree Walk.

I looked at messages which had passed reputation filtering and content
filtering, to isolate messages where DMARC alone could be determinative.
 Within that group, 75% of the messages did not need tree walk, either
because of strict alignment or no alignment.

For the subset where relaxed alignment would be applicable, about  11% had
no policy, and 1.6% had false failures because the domain owner had
published strict alignment.

For the subset where relaxed alignment was both specified and applicable,
the Tree Walk caused about 2% to switch from PASS to FAIL because the
domains being compared were incorrectly viewed as different organizations.

Is this consistent with the previous research into this issue?

Doug Foster
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc