There is no universal definition of private data, so I don't think we should make universal claims about there being no private data involved. It's true that some concerns might be assuaged by such an assurance, but I don't think that's a good reason to do it as I don't think the statement is accurate.
Also, I think if some aren't comfortable with reporting feedback, that's fine. I don't think 100% feedback coverage is a DMARC goal. As long as there's enough for a statistically valid sampling, that's sufficient. Scott K Scott K On April 25, 2023 5:32:23 PM UTC, "Brotman, Alex" <[email protected]> wrote: >I'm not disagreeing with the idea below, just that by omitting this in the >draft, we could leave it open to interpretation that it *always* will be a >privacy violation. This could justify decisions by some receivers to decline >to send reports. > >Otherwise, I'll remove 6.3. > >-- >Alex Brotman >Sr. Engineer, Anti-Abuse & Messaging Policy >Comcast > >> -----Original Message----- >> From: dmarc <[email protected]> On Behalf Of Scott Kitterman >> Sent: Tuesday, April 25, 2023 1:14 PM >> To: [email protected] >> Subject: Re: [dmarc-ietf] [EXTERNAL] Re: I-D Action: draft-ietf-dmarc- >> aggregate-reporting-09.txt >> >> Assuming for a moment that single user domains can't have a privacy violation >> (I'm not sure I agree), how about a two person domain? Three? Unless it's >> impossible to have a report that contains personal information, mail >> receivers >> (report senders) absolutely can't rely on the assertion in question since >> they have >> no way of knowing. >> >> This is a pointless rabbit hole. Let's not go down it. >> >> Scott K >> >> On April 25, 2023 4:58:26 PM UTC, Alessandro Vesely <[email protected]> wrote: >> >John is not alone, I too can recognize single posts. However, I'd argue >> >that in >> such cases there is no privacy violation. You violate privacy when you >> collect >> personal data of (several) people *different from yourself*. >> > >> >Best >> >Ale >> > >> > >> >On Tue 25/Apr/2023 18:36:34 +0200 Scott Kitterman wrote: >> >> My suggestion is delete all of it. It's accurate for some cases, not for >> >> others. >> If you want to keep any of it, I think it needs to be properly caveated. I >> expect >> that would be a Sisyphean task that's not worth the effort. >> >> >> >> Scott K >> >> >> >> On April 25, 2023 2:54:46 PM UTC, "Brotman, Alex" >> <[email protected]> wrote: >> >>>> As explained in 6.1, that's not actually true if the domains are small >> enuogh. >> >>>> In some of my tiny domains I can often recognize individual >> >>>> messages I've sent. I'd just delete these sentences. >> >>> >> >>> I'd argue that you're in a (mostly) unique situation where you're the >> >>> sender >> and the report reviewer. That being said, would you prefer I remove all of >> 6.3? >> Does the remaining sentence have enough value to keep? Or sweep it up to 6.1? >> >>> >> >>> -- >> >>> Alex Brotman >> >>> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast >> >>> >> >>>> -----Original Message----- >> >>>> From: John R. Levine <[email protected]> >> >>>> Sent: Monday, April 24, 2023 10:18 PM >> >>>> To: Brotman, Alex <[email protected]>; [email protected] >> >>>> Subject: [EXTERNAL] Re: [dmarc-ietf] I-D Action: >> >>>> draft-ietf-dmarc-aggregate- reporting-09.txt >> >>>> >> >>>> > I removed the small section that faced objections. >> >>>> > >> >>>> > I updated the ridtxt definition and discovered that mmark was >> >>>> > making a >> >>>> mess of those asterisks. When there are more than one/some on a >> >>>> single line, it believes you would like some subset to be defined as >> >>>> "<em>" >> things. >> >>>> >> >>>> Looks pretty good. Minor points: >> >>>> >> >>>> The first paragraph in 2.6 says: >> >>>> >> >>>> Where the URI specified in a "rua" tag does not specify otherwise, >> >>>> a >> >>>> Mail Receiver generating a feedback report SHOULD employ a secure >> >>>> transport mechanism. >> >>>> >> >>>> Since the only mechanism is mail and nobody's going to S/MIME >> >>>> encrypt their reports, I suggest just deleting it. >> >>>> >> >>>> 6.3: >> >>>> >> >>>> Mail Receivers should have no concerns in sending reports as they >> >>>> do >> >>>> not contain personal information. ... >> >>>> >> >>>> Domain Owners should have no concerns in receiving reports as they >> >>>> do >> >>>> not contain personal information. >> >>>> >> >>>> As explained in 6.1, that's not actually true if the domains are small >> enuogh. >> >>>> In some of my tiny domains I can often recognize individual >> >>>> messages I've sent. I'd just delete these sentences. >> >>>> >> >>>> R's, >> >>>> John >> >>>> >> >>>> >> >>>> >> -----Original Message----- >> >>>> >> From: dmarc <[email protected]> On Behalf Of >> >>>> >> [email protected] >> >>>> >> Sent: Monday, April 24, 2023 7:39 PM >> >>>> >> To: [email protected] >> >>>> >> Cc: [email protected] >> >>>> >> Subject: [dmarc-ietf] I-D Action: >> >>>> >> draft-ietf-dmarc-aggregate-reporting-09.txt >> >>>> >> >> >>>> >> >> >>>> >> A New Internet-Draft is available from the on-line >> >>>> >> Internet-Drafts >> >>>> directories. >> >>>> >> This Internet-Draft is a work item of the Domain-based Message >> >>>> >> Authentication, Reporting & Conformance (DMARC) WG of the IETF. >> >>>> >> >> >>>> >> Title : DMARC Aggregate Reporting >> >>>> >> Author : Alex Brotman >> >>>> >> Filename : draft-ietf-dmarc-aggregate-reporting-09.txt >> >>>> >> Pages : 28 >> >>>> >> Date : 2023-04-24 >> >>>> >> >> >>>> >> Abstract: >> >>>> >> DMARC allows for domain holders to request aggregate reports from >> >>>> >> receivers. This report is an XML document, and contains >> >>>> >> extensible >> >>>> >> elements that allow for other types of data to be specified later. >> >>>> >> The aggregate reports can be submitted to the domain holder's >> >>>> >> specified destination as supported by the receiver. >> >>>> >> >> >>>> >> This document (along with others) obsoletes RFC7489. >> >>>> >> >> >>>> >> The IETF datatracker status page for this Internet-Draft is: >> >>>> >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/dra >> >>>> >> ft-ie >> >>>> >> tf-dmarc- >> >>>> >> aggregate- >> >>>> >> >> >>>> >> reporting/__;!!CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVy >> >>>> qsr7 >> >>>> >> nLWuCbVwCDo_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqF46TKSvg$ >> >>>> >> >> >>>> >> There is also an HTML version available at: >> >>>> >> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draf >> >>>> >> t-iet >> >>>> >> f-dmarc- >> >>>> >> aggregate-reporting- >> >>>> >> >> >>>> >> 09.html__;!!CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr >> >>>> 7nL >> >>>> >> WuCbVwCDo_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqEqNRr1SA$ >> >>>> >> >> >>>> >> A diff from the previous version is available at: >> >>>> >> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff >> >>>> >> ?url2 >> >>>> >> =draft- >> >>>> >> ietf-dmarc-aggregate-reporting- >> >>>> >> >> >>>> >> 09__;!!CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr7nLW >> >>>> uC >> >>>> >> bVwCDo_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqFdWqTU2g$ >> >>>> >> >> >>>> >> Internet-Drafts are also available by rsync at >> >>>> >> rsync.ietf.org::internet-drafts >> >>>> >> >> >>>> >> >> >>>> >> _______________________________________________ >> >>>> >> dmarc mailing list >> >>>> >> [email protected] >> >>>> >> >> >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/d >> >>>> marc >> >>>> __;! >> >>>> >> >> >>>> >> !CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr7nLWuCbV >> >>>> wCD >> >>>> >> o_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqEDBiM7_A$ >> >>>> > >> >>>> > >> >>>> >> >>>> Regards, >> >>>> John Levine, [email protected], Primary Perpetrator of "The Internet >> >>>> for Dummies", Please consider the environment before reading this >> >>>> e-mail. <a >> >>>> href="https://urldefense.com/v3/__https://jl.ly__;!!CQl3mcHX2A!Fpku >> >>>> 2qYC >> TuZKAA4K08a9mXXHN3ECaWvI28GCiy40HeEi8kyMh5bKjQWeT7UFbqsfeN5N >> >>>> v88e0Nj1WqU$">https://urldefense.com/v3/__https://jl.ly__;!!CQl3mcH >> >>>> >> X2A!Cto4yMwda7b3nRK8gpGY7nKgl02tjSkT__FGFJ10Z6Tz6ib1muDEKkCAuWufI- >> y >> >>>> 7H7WVv7bkc3rHyFM3vJ9QPB69uRg$ </a> >> >>> >> >>> _______________________________________________ >> >>> dmarc mailing list >> >>> [email protected] >> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dm >> >>> >> arc__;!!CQl3mcHX2A!Cto4yMwda7b3nRK8gpGY7nKgl02tjSkT__FGFJ10Z6Tz6ib1 >> m >> >>> uDEKkCAuWufI-y7H7WVv7bkc3rHyFM3vJ9QTLYW37U$ >> >> >> >> _______________________________________________ >> >> dmarc mailing list >> >> [email protected] >> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dma >> >> >> rc__;!!CQl3mcHX2A!Cto4yMwda7b3nRK8gpGY7nKgl02tjSkT__FGFJ10Z6Tz6ib1m >> uD >> >> EKkCAuWufI-y7H7WVv7bkc3rHyFM3vJ9QTLYW37U$ >> > >> >_______________________________________________ >> >dmarc mailing list >> >[email protected] >> >https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc >> >__;!!CQl3mcHX2A!Cto4yMwda7b3nRK8gpGY7nKgl02tjSkT__FGFJ10Z6Tz6ib1mu >> DEKkC >> >AuWufI-y7H7WVv7bkc3rHyFM3vJ9QTLYW37U$ >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;! >> !CQl3mcHX2A!Cto4yMwda7b3nRK8gpGY7nKgl02tjSkT__FGFJ10Z6Tz6ib1muDEKk >> CAuWufI-y7H7WVv7bkc3rHyFM3vJ9QTLYW37U$ > >_______________________________________________ >dmarc mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
