Re: [dmarc-ietf] Next draft concerns

2022-06-17 Thread Scott Kitterman
On Sunday, June 12, 2022 10:22:18 PM EDT Douglas Foster wrote: > Why am I unwilling to move on? > > Because I want this document to succeed and actually reduce email-borne > attacks. > > Because stifling of discussion does not lead to consensus. It does, > however, drag out the process. For t

Re: [dmarc-ietf] Next draft concerns

2022-06-15 Thread Murray S. Kucherawy
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 o

Re: [dmarc-ietf] Next draft concerns

2022-06-12 Thread Douglas Foster
Why am I unwilling to move on? Because I want this document to succeed and actually reduce email-borne attacks. 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

Re: [dmarc-ietf] Next draft concerns

2022-06-12 Thread Scott Kitterman
Doug, I believe I have asked you before to provide specific examples of current domains with records that will cause a problem if assessed via the DMARCbis approach. If there's a real problem that needs solving, then surely there are examples of it. If they're none, then how about moving on.

Re: [dmarc-ietf] Next draft concerns

2022-06-12 Thread Douglas Foster
Les' question has returned us to the problem of justifying the tree walk. We need to document the problems with PSL, but we also need to demonstrate that the tree walk solves those problems without creating others. In most cases, the tree walk and PSL will produce the same results, because they w

Re: [dmarc-ietf] Next draft concerns

2022-06-09 Thread John Levine
It appears that Les Barstow said: >-=-=-=-=-=- >I will respectfully disagree that the “psd” tree walk standard is well-defined >based on the remainder of my response – >that the use of the “psd” TLA for the tag is unfortunate/misleading and that >more specificity is desirable. But having >the a

Re: [dmarc-ietf] Next draft concerns

2022-06-09 Thread Les Barstow
Thank you for the history fill-in, John. That does at least explain why we’re here and not somewhere else. I will respectfully disagree that the “psd” tree walk standard is well-defined based on the remainder of my response – that the use of the “psd” TLA for the tag is unfortunate/misleading a

Re: [dmarc-ietf] Next draft concerns

2022-06-09 Thread John Levine
It appears that Les Barstow said: >-=-=-=-=-=- >[Strong opinion follows] > >IMO [from April], determination of a DMARC authority boundary (registrar, >PSD+1, private registry (+1), or internal subdomain >boundary) should really be done outside of the DMARC standard altogether – a >separate DNS

Re: [dmarc-ietf] Next draft concerns

2022-06-08 Thread Les Barstow
[Strong opinion follows] IMO [from April], determination of a DMARC authority boundary (registrar, PSD+1, private registry (+1), or internal subdomain boundary) should really be done outside of the DMARC standard altogether – a separate DNS lookup not dependent or centered around DMARC, and one

[dmarc-ietf] Next draft concerns

2022-06-08 Thread Douglas Foster
Todd, as you prepare for the next draft, I want to restate my significant concerns with the previous draft and subsequent discussions: 1) Private Registres Private registries are a significant design consideration because they cause a single DNS path to have two organizational boundaries instead o