Re: [dmarc-ietf] Bridging the gap
It appears that Alessandro Vesely said: >I think we found the few critical domains which need a flag. We may have found some domains that need a psd flag, but it's silly to assert we have found all or even most of them. The PSL has 9300 entries and there are surely far more places in the DNS than that where you want sibling domains to be separate. The PSL only cares about web cookies, which do not always separate at the same places that DMARC does. The PSL is often wrong for DMARC and I see no reason to assume that even without PSD that a tree walk would produce less accurate results than the PSL does. On the other hand, it is a whole lot easier to publish a psd=y DMARC record than to get an entry into the PSL so for anyone who cares about this, they have a straightforward way to fix their problems. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Bridging the gap
On Wed 15/Jun/2022 04:40:31 +0200 Douglas Foster wrote: The problem seems rooted in our different attitudes toward the PSL. If one assumes that the Tree Walk must displace the PSL completely and quickly, then it becomes necessary to “make do” with incomplete information about organizational boundaries, even though this introduces unwanted risk to evaluators. I believe that the assumption is unnecessary, because the Tree Walk and the PSL can coexist without harm. We simply specify that the Tree Walk algorithm MUST be used when organizational boundary information is known to be complete and certain, as indicated by specific policy tags, while the PSL MAY be used when boundary information is uncertain or incomplete. I think we found the few critical domains which need a flag. I agree we should monitor the publishing of those flags before publishing the RFC, and possibly also afterwards. At that point, the tree walk should be safe to use for all DMARC filters. Yet, not all DMARC filters will be upgraded overnight. Use of the PSL is going to persist for some time. Mail filters which use the PSL also for other reasons may continue to do so even after upgrading to the tree walk for DMARC purposes. They may also compare tree walk and PSL results. I think that implementing a standard always leaves some leeway to the programmer. As long as the correct result is the outcome of the tree walk, programmers are free to decide how to manage data. They are not forced to throw away PSL lookups. The “Must-use-Tree-Walk” indicator provides the domain owner with a remedy to correct PSL errors, as well as a strategy for avoiding them. The MUST indicator also means that DMARCbis-compliant implementations MUST implement the Tree Walk algorithm, ensuring that the new algorithm becomes deployed with critical mass. I'd be skeptical about user defined “Must-use-Tree-Walk” indicators. The psd= flag (or whatever we'll call it when we'll ask the owners of critical domains to set it) is functional and should be monitored. Any additional flag, statically set and forgotten by the domain owner, would always be questionable. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next draft concerns
On Mon, Jun 13, 2022 at 3:22 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Because I want this document to succeed and actually reduce email-borne > attacks. > I believe we're all wearing the same team jersey here. Please let's try to keep that in mind. > Because stifling of discussion does not lead to consensus. It does, > however, drag out the process. For those who do not want this process to > succeed, accumulated delay may be almost as good as a win. > Please don't conflate being challenged on your assertions with an attempt to silence you. If you make a claim and someone challenges it (as I have done, most commonly because I simply don't understand the claim you're making), then the document will be stronger either because your assertion was correct and you've successfully swung consensus to your position, or because your position is untenable and we decided, as a group all wearing the same jersey, to omit it from the final product because it wasn't a well supported position. Because I don't know your agenda. I am here to voice the evaluator > perspective. What interest group do you represent? > I bristle at this sort of approach. If we're all playing closely held poker hands here, rather than coming with an intent to collaborate openly, then things are in pretty bad shape. As a participant, my "agenda" is to drive DMARC toward something that's as close to universally positive as is practicable. I don't represent my employer or any particular constituency other than, I suppose, my own use of DMARC and perhaps the IETF itself which suffered substantial negative impacts when DMARC was first deployed into the wild in a substantial way. > Because a good security policy does not defend against what has happened, > it defends against what could happen. > I would claim it takes both as input. > Because a new idea like Tree Walk does not get adopted unless people > believe the pain of transition is less than the benefit, so it needs to be > "sold".Currently, the tree walk risk seems greater than the PSL risk, > and you don't know how to sell past that objection. Muzzling me will not > cause millions of system administrators to do something stupid simply > because you put it into print. > I fail to see how asking you for supporting evidence of your claims -- which, to me, is a perfectly reasonable aspect of debate -- constitutes "muzzling". -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
