On Mon, Oct 16, 2023 at 8:35 PM Neil Anuskiewicz wrote:
> The reference to DBOUND was sparked by looking around at what w3aawg was
> saying as I generally think they have some good papers and a great video
> series on email authentication. But what I found on DBOUND isn’t
> endorsement. They
On Oct 16, 2023, at 6:48 PM, Neil Anuskiewicz wrote:
>
>
>> On Oct 16, 2023, at 6:43 PM, Seth Blank
>> wrote:
>>
>> I'm sorry, to what are you referring? I co-chair the M3AAWG technical
>> committee, and am unaware of any advocacy for relitigating DBOUND...
Seth, I based my statement on
It appears that Neil Anuskiewicz said:
>-=-=-=-=-=-
>See section V
Enaging with DBOUND is not the same thing as advocating that DBOUND do anything
specific.
Everyone agrees the PSL is awful, including the people who maintain
it. But there's no agreement at all about what would be better.
See section VOn Oct 16, 2023, at 6:43 PM, Seth Blank wrote:I'm sorry, to what are you referring? I co-chair the M3AAWG technical committee, and am unaware of any advocacy for relitigating DBOUND...On Mon, Oct 16, 2023 at 6:36 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:M3AAWG is
On Oct 16, 2023, at 6:43 PM, Seth Blank wrote:I'm sorry, to what are you referring? I co-chair the M3AAWG technical committee, and am unaware of any advocacy for relitigating DBOUND...On Mon, Oct 16, 2023 at 6:36 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:M3AAWG is advocating
I'm sorry, to what are you referring? I co-chair the M3AAWG technical
committee, and am unaware of any advocacy for relitigating DBOUND...
On Mon, Oct 16, 2023 at 6:36 PM Neil Anuskiewicz wrote:
> M3AAWG is advocating for DBOUND as most of you likely know. Does it seem a
> viable alternative?
M3AAWG is advocating for DBOUND as most of you likely know. Does it seem a
viable alternative? We could sure use the support of M3AAWG. How could we earn
their support or are they committed to DBOUND?
Perhaps once we prove that DMARCbis works they’ll reconsider.
Neil
Some time back there was an attempt to solve the PSL problem in DNS via a
Domain Boundaries (DBOUND) working group. It was not successful, unable to
develop consensus among several options, and the working group closed
having not produced anything.
The WG page:
On 4/3/2019 12:19 PM, tjw ietf wrote:
I was going to say CAA but that’s 6 years old.
5 was a random number. I was merely meaning 'recent'.
But suggesting CAA in response to my query means that you think RFC 6844
has received widespread -- ie, at scale -- end to end adoption and use.
Yes?
On 03/04/2019 21:19, Jothan Frakes wrote:
>> ... registrar
>> GUIs are perhaps the main barrier for new RRTYPEs ...
>
> s/registrar/DNS Management/
>
> these are often not one in the same - and the only reason I make that
> pedantic distinction is that the frequent situation where
> DNS
> ... registrar
> GUIs are perhaps the main barrier for new RRTYPEs ...
s/registrar/DNS Management/
these are often not one in the same - and the only reason I make that
pedantic distinction is that the frequent situation where
DNS Management != registrar
heavily impedes DNSSEC end-to-end
Far from widely deployed, but the latest ESNI draft introduced a
new RRTYPE from an experimental range, and it "just worked," which
was a pleasant surprise for me. (And is partly why I am happy to
try that route for RDBD.)
"just worked" here meaning: no registrar web-GUI involved, but
whacking
I appreciate the time you invested in this Dave. I definitely like
that we're thinking in terms of how to leverage DNS and its
distributed model vs emulating the hosts.txt situation, and PSL is
essentially a hosts.txt situation.
Some assert there is a benefit to being able to contain some form
On 4/3/2019 11:45 AM, John R Levine wrote:
On Wed, 3 Apr 2019, Dave Crocker wrote:
In my experience, these days getting a new rrtype that doesn't have
extra semantics into DNS servers happens pretty quickly.
Now, about /end to end/ support, not just publishing...
Please provide some
On Wed, 3 Apr 2019, Dave Crocker wrote:
Section 7's suggestion for using Additional information does not rely on
caching.
Reliance on existing wildcard depends on propagation of a new RR, which
continues to be problematic. There's a reason the Attrleaf table has so many entries...
Now
On 4/3/2019 10:58 AM, John Levine wrote:
In article <3bebe973-0536-96cd-983e-240ba4346...@dcrocker.net> you write:
Comments eagerly sought, of course.
This seems sorta kinda like my dbound draft, only with _tagged TXT
records rather than a new rrtype, and (unless I missed something) a
hope
16 matches
Mail list logo
