On Wednesday, December 12, 2018 05:46:08 PM Dave Crocker wrote:
> On 12/12/2018 5:27 PM, Scott Kitterman wrote:
> >> And the draft makes no reference to privacy issues. Or rather, the
> >> Privacy Considerations section says the draft doesn't introduce any.
> >
> > As written, it doesn't. If you
On 12/12/2018 5:27 PM, Scott Kitterman wrote:
And the draft makes no reference to privacy issues. Or rather, the
Privacy Considerations section says the draft doesn't introduce any.
As written, it doesn't. If you change it the way you propose, it will.
Please elucidate. I don't have a guess
On December 12, 2018 3:30:20 PM UTC, Dave Crocker wrote:
>On 12/11/2018 9:01 PM, Scott Kitterman wrote:
>> On Tuesday, December 11, 2018 08:17:38 PM Dave Crocker wrote:
>
>>> 1. If the registry is to constrain which public suffix operators
>>> are constrained to assert a default record, then
This new version fixes a handful of minor points raised in the IESG
reviews. It should be good to hand off to the editors...
Name: draft-ietf-dmarc-arc-protocol
Revision: 22
Title: Authenticated Received Chain (ARC) Protocol
Document date: 2018-12-12
Group: dmarc
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting
& Conformance WG of the IETF.
Title : Authenticated Received Chain (ARC) Protocol
Authors : Kurt Ande
On Wed, 12 Dec 2018, Dave Crocker wrote:
The source of the pressure is that the cost of a queriable registry is high.
Very, very high. So creating one needs to have a very compelling
justification. I don't see how this one comes close.
Seems that way to me. Even if it's distributed by DNS,
On 12/12/2018 9:47 AM, John R Levine wrote:
On Wed, 12 Dec 2018, Dave Crocker wrote:
3. Given queries for MX record, don't we already have massive exposure
of this privacy-related info in DNS activity? How would this be so
much more (and/or worse)?
Particularly with large passive DNS databas
On Wed, 12 Dec 2018, Dave Crocker wrote:
we used a DNS scheme like my DBOUND one, whoever runs the DNS policy
server can see all the queries and will have some idea of the mail
traffic from various names. This approach doesn't have that problem.
1. Doesn't the query to the registry suffer t
On 12/12/2018 8:59 AM, John Levine wrote:
In article <1b0bef4b-61e6-776c-79e8-89631efa8...@dcrocker.net> you write:
So I think that the functional goal of kitterman-dmarc-psd is fully
satisfied by merely doing a version of the 3A update to DMARC, directing
the client to query the immediate paren
In article <1b0bef4b-61e6-776c-79e8-89631efa8...@dcrocker.net> you write:
>So I think that the functional goal of kitterman-dmarc-psd is fully
>satisfied by merely doing a version of the 3A update to DMARC, directing
>the client to query the immediate parent of the organizational domain,
>if the
On 12/11/2018 9:01 PM, Scott Kitterman wrote:
On Tuesday, December 11, 2018 08:17:38 PM Dave Crocker wrote:
1. If the registry is to constrain which public suffix operators
are constrained to assert a default record, then I'll claim that's
a false sense of security, given the range of unrela
11 matches
Mail list logo
