On Fri 15/Jul/2022 21:28:09 +0200 Scott Kitterman wrote:
On July 15, 2022 6:26:39 PM UTC, "John R. Levine" wrote:
On Fri, 15 Jul 2022, Alessandro Vesely wrote:
+1 from me too. Note, though, that the (current) DNS is accidentally correct
most of the time, as far as our Tree Walk is
On July 15, 2022 6:26:39 PM UTC, "John R. Levine" wrote:
>On Fri, 15 Jul 2022, Alessandro Vesely wrote:
>> +1 from me too. Note, though, that the (current) DNS is accidentally
>> correct most of the time, as far as our Tree Walk is concerned.
>
>No, it's not an accident. We designed the
On Fri, 15 Jul 2022, Alessandro Vesely wrote:
+1 from me too. Note, though, that the (current) DNS is accidentally correct
most of the time, as far as our Tree Walk is concerned.
No, it's not an accident. We designed the tree walk based on our
knowledge of the way people publish DMARC
On Thu 14/Jul/2022 17:12:19 +0200 Murray S. Kucherawy wrote:
On Thu, Jul 14, 2022 at 6:13 AM Scott Kitterman wrote:
I think a choice within DMARCbis is a bad idea. Effectively the choice
exists. Evaluators will have the choice to stay with an RFC 7489 design or
to upgrade to DMARCbis.
On Thu, Jul 14, 2022 at 11:12 AM Murray S. Kucherawy
wrote:
> On Thu, Jul 14, 2022 at 6:13 AM Scott Kitterman
> wrote:
>
>> >> I think a choice within DMARCbis is a bad idea. Effectively the
>> choice exists. Evaluators will have the choice to stay with an RFC 7489
>> design or to upgrade to
On Thu, Jul 14, 2022 at 6:13 AM Scott Kitterman
wrote:
> >> I think a choice within DMARCbis is a bad idea. Effectively the choice
> exists. Evaluators will have the choice to stay with an RFC 7489 design or
> to upgrade to DMARCbis.
> >
> >The incentive to upgrade is not clear. DMARC filters
On Thu, 14 Jul 2022, Scott Kitterman wrote:
In my view, standardizing two ways to do policy discovery and alignment would
be a substantial danger to interoperability and we'd be stuck with it
approximately forever.
I agree, it's a self-evidently terrible idea. "Temporary" transition
periods
On July 14, 2022 12:11:57 PM UTC, Alessandro Vesely wrote:
>On Wed 13/Jul/2022 17:56:08 +0200 Scott Kitterman wrote:
>> On July 13, 2022 3:10:38 PM UTC, "Murray S. Kucherawy"
>> wrote:
>>> Once again, participating only:
>>> On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster wrote:
[...]
>>>
On Wed 13/Jul/2022 17:56:08 +0200 Scott Kitterman wrote:
On July 13, 2022 3:10:38 PM UTC, "Murray S. Kucherawy"
wrote:
Once again, participating only:
On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster wrote:
[...]
3) The critical question is whether we can treat the PSL as replaced
without
We can limit the transition period by specifying a date, after which any
untagged record is interpreted with strict alignment.
On Wed, Jul 13, 2022, 11:10 AM Murray S. Kucherawy
wrote:
> Once again, participating only:
>
> On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster <
>
It appears that Murray S. Kucherawy said:
>There is indeed more of a burden on sending domains and registry operators
>to publish the needed markers in the DNS before this will all work the way
>we want it to. ...
Not really. If a mail sender has a DMARC record at its org domain, and
there are
Whois vs RDAP isn't the issue. PII about registrants has been
restricted by ICANN policy since GDPR.
Barry
On Wed, Jul 13, 2022 at 11:04 AM Murray S. Kucherawy
wrote:
>
> On Wed, Jul 13, 2022 at 3:05 AM Alessandro Vesely wrote:
>>
>> Uh? manuals recommend to look up WHOIS to determine the
On July 13, 2022 3:10:38 PM UTC, "Murray S. Kucherawy"
wrote:
>Once again, participating only:
>
>On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster <
>dougfoster.emailstanda...@gmail.com> wrote:
>
>> [...]
>>
>
>> 2) I believe that the document needs a vigorous explanation of why the PSL
>>
Once again, participating only:
On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> [...]
>
> 2) I believe that the document needs a vigorous explanation of why the PSL
> needs to be replaced. I made a stab at the effort in the text that I sent
>
On Wed, Jul 13, 2022 at 3:05 AM Alessandro Vesely wrote:
> Uh? manuals recommend to look up WHOIS to determine the owner of
> domains reported to suffer lame delegation and contact them...
> Nowadays, contacts for domain names are not available that way.
>
> We could hijack reporting addresses,
On Tue 12/Jul/2022 17:12:40 +0200 John Levine wrote:
A.6 seems to be dealing with a different subject. I can still
sketch some text to be added there, though. I attach the diff.
I realize this is getting repetitive but:
-- PSDs are very, very rare, and users will generally never see them
1) I believe that replacing the PSL is a good thing, if it is done with
markers present. The domain owner is the best source of information about
the organization boundaries. We MUST provide him with a way to
communicate that knowledge in DNS, and a compliant implementation MUST find
and use
On Wed 13/Jul/2022 07:12:25 +0200 Murray S. Kucherawy wrote:
If we want a migration period, some kind of hybrid model might work:
Do the DNS tree walk, but at each step, if you find you've hit a name
that's present in the PSL, you can stop and pretend you found a marker
you're looking for.
Hatless once again.
On Tue, Jul 12, 2022 at 3:08 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> The tree walk solves the problem IF the policy has boundary information
> provided by the domain owner. Without that, aren't we substituting one
> insufficiently reliable
On July 13, 2022 2:05:45 AM UTC, John Levine wrote:
>It appears that Todd Herr said:
>>On Tue, Jul 12, 2022 at 1:30 PM Douglas Foster <
>>dougfoster.emailstanda...@gmail.com> wrote:
>>
>>> What problem does this tree walk solve? Can anyone explain how this tree
>>> walk improves on RFC7489
It appears that Todd Herr said:
>On Tue, Jul 12, 2022 at 1:30 PM Douglas Foster <
>dougfoster.emailstanda...@gmail.com> wrote:
>
>> What problem does this tree walk solve? Can anyone explain how this tree
>> walk improves on RFC7489 evaluation results?
>>
>>
>RFC 7489 acknowledged that its
The tree walk solves the problem IF the policy has boundary information
provided by the domain owner. Without that, aren't we substituting one
insufficiently reliable solution for another insufficiently reliable one?
As I have said previously: errors in the PSL are expected to
org-fragmenting
On Tue, Jul 12, 2022 at 1:30 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> What problem does this tree walk solve? Can anyone explain how this tree
> walk improves on RFC7489 evaluation results?
>
>
RFC 7489 acknowledged that its methods for discovering the organizational
What problem does this tree walk solve? Can anyone explain how this tree
walk improves on RFC7489 evaluation results?
On Tue, Jul 12, 2022, 11:13 AM John R Levine wrote:
> > A.6 seems to be dealing with a different subject. I can still sketch
> some
> > text to be added there, though. I
A.6 seems to be dealing with a different subject. I can still sketch some
text to be added there, though. I attach the diff.
I realize this is getting repetitive but:
-- PSDs are very, very rare, and users will generally never see them
-- long discussions of PSDs will just confuse people
--
On Mon 11/Jul/2022 21:54:25 +0200 John Levine wrote:
On Mon, 11 Jul 2022, Alessandro Vesely wrote:
We are proposing an alternative to the PSL without having any
experience of it. I think a Proposed Standard should give full
explanations of design choices, so that possible, future amendments
On Mon, 11 Jul 2022, Alessandro Vesely wrote:
We are proposing an alternative to the PSL without having any experience of
it. I think a Proposed Standard should give full explanations of design
choices, so that possible, future amendments can be thoughtful and
considered.
Could you explain,
27 matches
Mail list logo
