Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread Scott Kitterman
On October 30, 2021 3:10:13 AM UTC, Dave Crocker wrote: >On 10/29/2021 7:56 PM, John Levine wrote: >> I asked for some examples of bad things that the PSL would prevent or fix. >> Don’t think we’ve seen any. > > >1. I've reviewed what I believe are all of your relevant postings on >this thread

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery -- PSL Replacement using DNS Flags

2021-10-29 Thread Scott Kitterman
On October 30, 2021 1:58:00 AM UTC, Douglas Foster wrote: >I enthusiastically endorse John's proposal for policy discovery. But as >stated previously, I do not see that it provides a viable mechanism for >eliminating the PSL as an alignment tool. To address that part of the >problem, I submi

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread Dave Crocker
On 10/29/2021 7:56 PM, John Levine wrote: I asked for some examples of bad things that the PSL would prevent or fix. Don’t think we’ve seen any. 1. I've reviewed what I believe are all of your relevant postings on this thread and managed to miss where you asked that. Please point to the me

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread John Levine
I asked for some examples of bad things that the PSL would prevent or fix. Don’t think we’ve seen any. Please consider the environment before reading this message. John Levine, jo...@taugh.com > On Oct 29, 2021, at 22:08, Dave Crocker wrote: > > On 10/29/2021 6:40 PM, John Levine wrote: >> I

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread Dave Crocker
On 10/29/2021 6:40 PM, John Levine wrote: It appears that Dave Crocker said: Except that Alessandro's original reference was in the service of explaining why a mechanism DMARC relies on, for establishing organization authority, should not necessarily rely on everyone's being a good actor. I t

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery -- PSL Replacement using DNS Flags

2021-10-29 Thread Douglas Foster
I enthusiastically endorse John's proposal for policy discovery. But as stated previously, I do not see that it provides a viable mechanism for eliminating the PSL as an alignment tool. To address that part of the problem, I submit my proposal for migrating from the publicsuffix.org list to DNS

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread John Levine
It appears that Dave Crocker said: >Except that Alessandro's original reference was in the service of >explaining why a mechanism DMARC relies on, for establishing >organization authority, should not necessarily rely on everyone's being >a good actor. I take it you are agreeing that we should

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread Dave Crocker
On 10/29/2021 6:06 PM, John R Levine wrote: an you explain what this line of argument has to do with DMARC?  I'm drawing a blank. If it's that any TLD operator might at any time do something horrible, even though they never have before, it seems to me that the only reasonable option is to aba

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread John R Levine
On Fri, 29 Oct 2021, Dave Crocker wrote: Every gTLD operator has a web of contracts with ICANN, and Verisign also with the US government, which severely constrain what they can do with their TLDs. Yes, yes.  All of them are well-behaved, following all the rules, and the rules perfectly protec

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread John Levine
It appears that Scott Kitterman said: >Based on the longest true PSL entry being 4 labels, we could also just jump to >the 5th and walk up from there. It would give every domain that currently has >the ability to express a domain policy the ability to do so and bound the >total number of look

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread Dave Crocker
On 10/29/2021 5:02 PM, John R Levine wrote: Oh, please.  That was the sitefinder fiasco which led to lawsuits and convulsions at ICANN, and considerable contract revision.  Nothing like that will happen again for reasons I can explain privately for anyone who cares. Except that repetition of th

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread John R Levine
Oh, please. That was the sitefinder fiasco which led to lawsuits and convulsions at ICANN, and considerable contract revision. Nothing like that will happen again for reasons I can explain privately for anyone who cares. Except that repetition of the same action is not what was being suggeste

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread Dave Crocker
On 10/29/2021 10:31 AM, John Levine wrote: Oh, please. That was the sitefinder fiasco which led to lawsuits and convulsions at ICANN, and considerable contract revision. Nothing like that will happen again for reasons I can explain privately for anyone who cares. Except that repetition of th

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread Scott Kitterman
On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: > It appears that Scott Kitterman said: > >For a 'normal' domain/sub-domain like eml.example.com where the domain has > >a DMARC policy, every single implementation approach gives the same > >answer, so it doesn't matter. The challe

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread John Levine
It appears that Alessandro Vesely said: >Verisign is not new to abusive behavior. About 20 years ago they used to >reply >with one of their servers' IP addresses to any query like >www..com. ISC came out with the "root-delegation-only" hack >to counter that. Oh, please. That was the sitef

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread Alessandro Vesely
On Fri 29/Oct/2021 03:15:10 +0200 Scott Kitterman wrote: On October 29, 2021 12:58:12 AM UTC, John Levine wrote: It appears that Scott Kitterman said: The key is to get the security and privacy considerations documented so that ICANN and ccTLD operators are informed and can set their own ru

[dmarc-ietf] Nature of the PSL as related to DMARC, was: Re: Topic for IETF 112 - Policy Discovery

2021-10-29 Thread Scott Kitterman
On Friday, October 29, 2021 7:06:18 AM EDT Douglas Foster wrote: > PSL entries are imputed with four important characteristics: > - name not valid for MAILFROM > - name not valid for FROM > - name not valid for DKIM > - name not valid as an alignment point for mismatched names. > > For non-PSL nam

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

2021-10-29 Thread Douglas Foster
PSL entries are imputed with four important characteristics: - name not valid for MAILFROM - name not valid for FROM - name not valid for DKIM - name not valid as an alignment point for mismatched names. For non-PSL names, the reverse is assumed by default - any name is valid for any of these purp