Chair weighing in, as chair: We're divided in the sense that there are some who want to add this information, but as I see it the rough consensus is not divided: - This is extra information that's being proposed... so, a new feature. That requires rough consensus to add it. - Serious privacy issues have been raised with respect to adding that information. - No refutation of those privacy issues has been given, and no adequate mitigation has been proposed. The suggestion of requiring a minimum level of aggregation is insufficient, as there's ample general evidence that privacy leaks survive aggregation. - We therefore do not have rough consensus to add this.
The chairs, therefore, declare this issue closed. I'll also note that the IESG *will* bring up the privacy issues and would very likely block the document on those grounds. I don't think we want to go there. Barry On Wed, May 5, 2021 at 9:18 PM Brotman, Alex <Alex_Brotman=40comcast....@dmarc.ietf.org> wrote: > > Are we divided? Seems like use cases have been noted. However, removing > these completely protects some aspects of privacy. Could we perhaps err on > the side of caution, removing these definitions, and leave a note to suggest > that if domain holders need further assistance to reach out to the report > generator. The generator can then make decisions about how much information > to expose. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > > -----Original Message----- > > From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Alessandro Vesely > > Sent: Tuesday, May 4, 2021 5:07 AM > > To: dmarc@ietf.org; Douglas Foster > > <dougfoster.emailstanda...@gmail.com> > > Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23) > > > > Doug, > > > > > > On Mon 03/May/2021 14:25:54 +0200 Douglas Foster wrote: > > > No. I can't talk straight. > > > > > > I meant to say that we need N unique (and valid) smtp TO addresses, so > > > that an attacker cannot send a single email address and wait for an > > > rua report to know where it lands. > > > > > > A simple positive DSN can confirm email addresses better than elaborate > > DKIM design. To confirm delivery is usually not considered a privacy > > violation, given that the sender learned the recipient's address. Privacy > > violation occurs when senders track the recipient's opening of each message, > > which is typically obtained by inserting unique images in HTML messages. > > > > Avoiding to reveal final email addresses requires various precautions, > > which, > > if I understood what Laura wrote, can be put into effect on forwarding. I > > would *add to the Privacy Consideration section* that, due to reporting, > > changing the envelope from is not enough, From: has to be changed as well > > in order to forward without revealing the final address. > > > > > > > Valid addresses are needed to hinder usage of bogus addresses to defeat > > the test. > > > > > > However, the aggregate report counts the number of messages, not the > > number of recipients. > > > > > > > Requiring aggregation on DKIM selector follows the sane logic to hinder > > > tracking an individual. > > > > > > Using DKIM selectors for tracking will also put a huge load on DNS if > > > implemented at scale, so it needs to be obstructed. > > > > > > I think mass mailers have better means to track recipients. But I agree > > that > > to generate, publish, retrieve and report million DKIM selectors would be > > somewhat impractical. Putting a limit on aggregate report size (even if not > > requested by the report consumer) can prevent excessive disaggregation. > > > > > > > It is also not enough to null the DKIM selector; the null aggregate still > > > needs > > > to meet the N recipient requirement. If not, then additional selectors > > > need > > to > > > be nulled or the nulled-selector messages need to be completely excluded > > from > > > the report. > > > > > > Most reports I send have <count>1</count>, given my volumes. Yet, by > > aggregating many of them one could reach significant sums. > > > > > > > If the To domain is included in the report, the aggregation rules should > > > still > > > apply. If they cannot be met, then the To domain must be nulled out or > > the > > > report not sent. > > > > > > This is a recipient's choice. If I wanted to stay anonymous, I'd use a > > domain > > like gmail.com rather than tana.it. > > > > > > > I favor making To domain an option which the owner domain requests and > > the > > > sending domain chooses to follow or ignore. This provides upward > > > compatibility. The request for this data element keeps coming up. The > > > protocol can allow flexibility so that the participants make the final > > > decision. > > > > > > It is already optional in the I-D. (Not that I find it useful.) > > > > > > > I asked previously whether report senders do any filtering based on > > domain > > > reputation, and the answer was "probably not". I think the specification > > > should encourage recipients to omit reporting to sources with negative > > > reputations, as their motive for report collection may be unrelated to > > > self-identification. > > > > > > Some receivers cannot report mail discarded during early SMTP phases at all, > > for example because the DMARC filter is run after the end of data. > > > > > > > I want the protocol to address all of Laura's concerns. I think ensuring > > > aggregation is the best way to do this. > > > > > > DMARC cannot address those concerns directly, IMHO. However, it can note > > under > > what conditions aggregate reporting doesn't violate privacy. It is > > especially > > useful to note that, in most cases, aggregate reports do NOT constitute a > > privacy risk. > > > > > > Best > > Ale > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc > > __;!!CQl3mcHX2A!R7ZKTY4HhF1wSMZwpruVsXIE5- > > EtRxdlYaxRVkylrlTKnqYLGf-PSpD4ChOUaRGFE27SBql-1Q$ > _______________________________________________ > 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
