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 considerations. Perhaps we need to step back and see if there is consensus that the privacy considerations in the draft are substantially correct and if risk mitigation is needed as described. Scott K On December 1, 2018 1:06:17 AM UTC, Tim Wicinski <tjw.i...@gmail.com> wrote: >https://www.ietf.org/archive/id/draft-levine-dbound-dns-01.txt > > > >On Fri, Nov 30, 2018 at 8:04 PM Scott Kitterman <skl...@kitterman.com> >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 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 that don't participate in DMARC being >> > >inappropriately captured by public suffix operators. >> > >> > It seems to me this horse left the barn a long time ago. Mail >systems >> > routinely check domains in HELO and in MAIL FROM against DNSBLs, >which >> > is at least as loggy as anything a DNS version of this check will >do. >> > >> > Also, if you really want to keep people from logging your queries, >you >> > can set up a local mirror of the DNS zone, and update it in the >usual >> > way with AXFR and IXFR. Whatever one might have in mind for a text >> > version of this, a binary AXFR would be about as fast and IXFR of >just >> > the occasional change faster. >> > >> > Take a look at my DBOUND proposal. I think it would be just the >> > ticket for this application. >> >> I've lost track. Which draft was that? >> >> I don't agree that a situation being bad is a reasonable reason not >to try >> and >> keep it from getting worse. I think the implications of the DMARC >> feedback >> reports are greater than logging queries. >> >> Scott K >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
