On Mon, Jul 11, 2022 at 5:57 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> We should talk about "correct results".
>
> The PSL gets the correct results in 99-dot-something percent of messages,
> but we are proposing a new algorithm because it is wrong on some fraction
> of a
We should talk about "correct results".
The PSL gets the correct results in 99-dot-something percent of messages,
but we are proposing a new algorithm because it is wrong on some fraction
of a percent. The size of the fraction is not a reason to ignore a
problem. I support a change. But is
On Sun 10/Jul/2022 19:04:08 +0200 Scott Kitterman wrote:
On July 10, 2022 11:17:13 AM UTC, Alessandro Vesely wrote:
On Sun 10/Jul/2022 03:05:47 +0200 John Levine wrote:
It appears that Scott Kitterman said:
On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely wrote:
Yeah, /should/! The
On July 10, 2022 11:17:13 AM UTC, Alessandro Vesely wrote:
>On Sun 10/Jul/2022 03:05:47 +0200 John Levine wrote:
>> It appears that Scott Kitterman said:
>>> On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely wrote:
>> Yeah, /should/! The very fact that you yourself changed your mind
I changed it in a pull request a few weeks ago.
If you don't stop on the first psd=y that is not the original domain,
you get the wrong result if there are DMARC records above the psd=y.
I sent this example on June 21, link is
On July 10, 2022 1:05:47 AM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>
>>
>>On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely wrote:
> Yeah, /should/! The very fact that you yourself changed your mind about
> how it works, without going into the hassle
>>of
On Sun 10/Jul/2022 03:05:47 +0200 John Levine wrote:
It appears that Scott Kitterman said:
On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely wrote:
Yeah, /should/! The very fact that you yourself changed
your mind about how it works, without going into the hassle
of explaining your
It appears that Scott Kitterman said:
>
>
>On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely wrote:
Yeah, /should/! The very fact that you yourself changed your mind about
how it works, without going into the hassle
>of explaining your reasoning, ...
>>>
>>> Um, what? Scott and I
On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely wrote:
>On Fri 08/Jul/2022 22:07:09 +0200 John Levine wrote:
The description of the tree walk should be clear enough.
>>>
>>> Yeah, /should/! The very fact that you yourself changed your mind about
>>> how it works, without going into
On Fri 08/Jul/2022 22:07:09 +0200 John Levine wrote:
The description of the tree walk should be clear enough.
Yeah, /should/! The very fact that you yourself changed your mind
about how it works, without going into the hassle of explaining your
reasoning, ...
Um, what? Scott and I went
First, let me be clear here: There will be no further discussion of
this "don't be nasty" issue on the list; if you have more to say to me
about it, please do it off list.
Nothing that Murray or I said is "endorsing the current document" (nor
is it not). It's addressing your behaviour, your way
I see no personal attack. John was clear, and has been clear, that he has
no intention of documenting any limitations or risks associated with the
tree walk, because in his judgement, they are not important. My concern
is about a document that creates a new vulnerability, then fails to
The description of the tree walk should be clear enough.
Yeah, /should/! The very fact that you yourself changed your mind about how
it works, without going into the hassle of explaining your reasoning, ...
Um, what? Scott and I went through some rounds of debugging to be sure
the tree
>> So John has confirmed that it is his intent to hide any information about
>> private registries, because the
>> private registries create complexity for his algorithm which he does not
>> wish exposed.
>
> I submit that equating "this is not worth explaining as it's a corner case"
> to "we
Speaking only as a participant:
On Thu, Jul 7, 2022 at 4:47 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> So John has confirmed that it is his intent to hide any information about
> private registries, because the private registries create complexity for
> his algorithm which
On Thu 07/Jul/2022 22:32:56 +0200 John Levine wrote:
The description of the tree walk should be clear enough.
Yeah, /should/! The very fact that you yourself changed your mind
about how it works, without going into the hassle of explaining your
reasoning, proves that a more extensive walk
So John has confirmed that it is his intent to hide any information about
private registries, because the private registries create complexity for
his algorithm which he does not wish exposed.
Chairs, does IETF support this approach to design?
DF
On Thu, Jul 7, 2022 at 4:33 PM John Levine
It appears that Alessandro Vesely said:
>Anyway, we need an appendix with an example of private (or should we
>call them secondary?) registry, to illustrate both the algorithm and
>the setting of psd='s.
Please, no.
The description of the tree walk should be clear enough. Stacked PSDs
are an
Having a contract with ICANN rather than someone else is not much
relevant. The point of "private" PSDs is that they can be stacked
below a regular DMARC PSD. ("Private" is not the right term IMHO, as
it may sound like "within an org".)
Stacks deeper than two are unlikely because of the
Yes, PSD is still the appropriate term for a PSO-controlled domain. We
need an additional definition for a "Private Registry Domain" (optionally
"PRD" if we want to create another acronym.) Collectively, PSDs and PRDs
are "registry domains". We intend to use a single DNS token for both PSD
That's true, while we won't have the PSL in the algorithm, we will
still be talking about PSDs, so the term will remain defined. OK,
that makes sense, Scott; thanks.
Barry
On Mon, Jun 27, 2022 at 9:46 AM Scott Kitterman wrote:
>
> If we use a different term, we'll need to define it.
If we use a different term, we'll need to define it. Fundamentally, I think
changing the name only adds a level of indirection (and thus complexity).
Current:
PSD (which is defined in the document) yes or no or use tree walk.
Proposed:
Role (needs a definition) PSD (defined), Org (defined as
I have to say, as a participant, that I have more than a little
sympathy for this suggestion or some derivative of it. Using "psd" as
the tag name is rooted in history that will be lost as we move away
from using a public suffix list.
Barry
On Mon, Jun 27, 2022 at 6:20 AM Alessandro Vesely
On Sun 26/Jun/2022 18:05:44 +0200 Barry Leiba wrote:
Please comment in this thread about whether you agree with making the
registration now, or whether you do not agree and why.
I'd like to make a last appeal to use more intuitive symbols to be used instead
of the current ones:
instead of
It appears that Barry Leiba said:
>So: Is the working group ready to register the psd= tag, based on the
>description in the -10 version of the dmarcbis draft? The relevant
>documentation includes the description in Section 4.8 and the formal
>definition in Section 5.3.
Sure.
The changes in
I could accommodate myself to PSD=Y, if we wer to document that "PSD" in
this context means either "Public Suffix Domain" or "Private Suffix Domain"
I oppose use of the PSD=N tag to indicate an organizational domain. The
use of PSD=N originated because some participants believed that explicit
As we've discussed on this mailing list, there is some evangelizing to
be done regarding the domains that should add psd=y to their DMARC
records. We should have the tag added to the relevant IANA registry
before we embark on that, and the current dmarcbis draft is ready for
supporting that
27 matches
Mail list logo
