Thanks. That refreshes my memory.
I think it's a proposal that has potential to be an eventual standardized
replacement for using the public suffix and we should look into publishing a
DMARC specific variation.
It doesn't, however, seem to address the issue described in the draft's privacy
co
https://www.ietf.org/archive/id/draft-levine-dbound-dns-01.txt
On Fri, Nov 30, 2018 at 8:04 PM Scott Kitterman
wrote:
> On Friday, November 30, 2018 07:33:00 PM John Levine wrote:
> > In article <3881693.rR9BVk4Dlq@kitterma-e6430> you write:
> > >2. Externalize signaling about PSD participati
On Friday, November 30, 2018 07:33:00 PM John Levine wrote:
> In article <3881693.rR9BVk4Dlq@kitterma-e6430> you write:
> >2. Externalize signaling about PSD participation. As discussed in the
> >Privacy Considerations (section 4.1), we were concerned about the privacy
> >implications of feedback
In article <3881693.rR9BVk4Dlq@kitterma-e6430> you write:
>2. Externalize signaling about PSD participation. As discussed in the
>Privacy Considerations (section 4.1), we were concerned about the privacy
>implications of feedback on organizational domain traffic for organizational
>domains tha
On November 30, 2018 9:40:33 PM UTC, Zeke Hendrickson
wrote:
>On Wed, Nov 21, 2018 at 02:37:19AM -0500, Scott Kitterman wrote:
>> While we were discussing making draft-kitterman-dmarc-psd a working
>group
>> item, the main discussion point was about the use of an IANA registry
>to
>> identif
On Fri, Nov 30, 2018 at 1:40 PM Zeke Hendrickson wrote:
>
> I feel that restricting the additional PSD check to nonexistent
> organizational domains is the best approach,
I disagree...see below
> as it preserves the opt-in nature of DMARC,
granted
> limits privacy concerns,
No - this is
On Wed, Nov 21, 2018 at 02:37:19AM -0500, Scott Kitterman wrote:
> While we were discussing making draft-kitterman-dmarc-psd a working group
> item, the main discussion point was about the use of an IANA registry to
> identify participating public suffix domains. I think it would be useful to
>
On Fri, Nov 30, 2018, at 8:54 PM, Barry Leiba wrote:
> Murray, would you please copy the relevant IANA Considerations
> sections from RFC 7601 into 7601bis and change the tenses
> appropriately (perhaps just with a sentence in each subsection that
> says, "The following was done in the previous edi
In case it’s not obvious, that would be sufficient for me to clear.
Thanks!
Ben.
> On Nov 30, 2018, at 2:54 PM, Barry Leiba wrote:
>
> Murray, would you please copy the relevant IANA Considerations
> sections from RFC 7601 into 7601bis and change the tenses
> appropriately (perhaps just with a
Murray, would you please copy the relevant IANA Considerations
sections from RFC 7601 into 7601bis and change the tenses
appropriately (perhaps just with a sentence in each subsection that
says, "The following was done in the previous edition of this
document, RFC 7601:", or some such), and then le
On Fri, Nov 30, 2018 at 11:00 AM Alexey Melnikov
wrote:
> Hi all,
>
> On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote:
> > I actually agree with this: I think the better answer is to go back to
> > "obsoletes" and to have this document include the details of what was
> > put in the registries
Hi all,
On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote:
> I actually agree with this: I think the better answer is to go back to
> "obsoletes" and to have this document include the details of what was
> put in the registries before. But the working group decided to do it
> the other way, and
12 matches
Mail list logo
