Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

[Douglas Foster <[e-mail]>]

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.

Valid addresses are needed to hinder usage of bogus addresses to defeat the
test.

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.

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.

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.

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.

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-identificaion.

I want the protocol to address all of Laura's concerns.  I think ensuring
aggregation is the best way to do this.

Doug

On Mon, May 3, 2021, 7:37 AM Laura Atkins <[e-mail]> wrote:

> In the bulk email space most messages are sent with a unique 5321.from
> address (VERP). Are you suggesting that no DMARC reports should be sent for
> commercial bulk mail?
>
> laura
>
>
>
> On 3 May 2021, at 12:21, Douglas Foster <
> [e-mail]> wrote:
>
> To address Laura's concerns about individual targeting, the
> reporting needs to ensure a minimum level of aggregation on all reports.
>
> This starts with MailFrom.   If less than N unique recipient addresses are
> included, the report should not be sent at all
>
> If a DKIM selector occurs on less than N unique recipient addresses, the
> DKIM selector should be replaced with * or Null.
>
> I do not have a strong opinion about N, but am thinking 10.
>
> Doug Foster
>
>
>
> On Mon, May 3, 2021 at 4:49 AM Laura Atkins <[e-mail]>
> wrote:
>
>>
>>
>> On 3 May 2021, at 07:27, Hans-Martin Mosner <[e-mail]> wrote:
>>
>> Am 02.05.21 um 22:30 schrieb John Levine:
>>
>> It appears that Matthäus Wander <[e-mail]> said:
>>
>> envelope_to allows you to automatically correlate these reports and
>> reconstruct the forwarding path. This helps to identify the culprit who
>> is breaking DKIM signatures, especially with longer forwarding chains.
>> Without envelope_to, reconstructing the mail flow requires guessing and
>> manual work.
>>
>> It is none of your business to whom I forward my mail.
>>
>>
>> True, unless you (generic you, not John L.) make it my business by
>> complaining about not receiving my mail either in a
>> support request (which may cause quite some work) or in a public forum
>> (which might damage my reputation and even cause
>> more work).
>>
>>
>> I will point out that for a lot of us online (specifically those of us
>> who don’t check any or all of the the cis-het-white-male categories)
>> forwarding mail and protecting our identities are crucial to our ability to
>> actually participate in an online life. Stalking and harassment are real.
>> I, personally, have been being low-level stalked by someone for over a
>> decade now. I have been put into positions where I have to make calculated
>> decisions about my ability to participate in places based on my personal
>> safety. I have involved the police in the past for specific threats against
>> me. The first time I was threatened and stalked online was more than 20
>> years ago. This is not some ‘oh, it only happens to some people’, it
>> happens to a lot of people, regularly.
>>
>> The threats I’ve had to deal with, just for being a woman in an online
>> environment, are minor compared to some threats other women, BIPOC and
>> members of other marginalized groups have had to put up with. I’ve never
>> had to move out of my house for my safety. ISPs HAVE doxxed individuals in
>> the past, both accidentally and through deliberate policy decisions. Adding
>> personally identifiable information into DMARC reports is problematic in a
>> way I don’t think many men here realize.
>>
>> It is not anyone’s business how I might route mail to protect my safety.
>> And, frankly, the issues of data privacy and safety for people online
>> significantly trump the concern that someone’s reputation might be slightly
>> impacted because they can’t troubleshoot an individual mail failure.
>>
>> I am too often in a position of being requested to solve a problem but
>> the requestors don't even provide the minimal
>> logging info or even error texts to even start analyzing their problem.
>> In such cases I want to be able to look at as
>> much info as possible so as to provide a decent service.
>>
>> I don't snoop on mail logging info to satisfy my curiosity or to increase
>> my revenue, but to solve my user's problems.
>>
>>
>> This is irrelevant. How, in fact, do you protect your users safety and
>> privacy? How do you ensure that the request is actually coming from your
>> user and not from someone attempting to discover where they are and defeat
>> personal safety measures your user has put in place to protect themselves
>> from harassment and stalking? Maybe they don’t provide the minimum logging
>> info or texts because they’re attempting to social engineer you into
>> revealing someone’s information and identity that forms a chain that leads
>> to their safety being compromised.
>>
>> Whether envelope_to would help my work isn't clear, but apparently it
>> would help Matthäus in his work.
>>
>>
>> But is that work necessary and relevant? Does that process protect
>> people? Does it faciliate online threats, harassment and stalking? Will
>> someone who is trying to hide their location due to a credible threat be
>> harmed by this protocol decision?
>>
>> laura
>>
>> --
>> Having an Email Crisis?  We can help! 800 823-9674
>>
>> Laura Atkins
>> Word to the Wise
>> [e-mail]
>> [phone]
>>
>> Email Delivery Blog: https://wordtothewise.com/blog
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> dmarc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
> --
> Having an Email Crisis?  We can help! 800 823-9674
>
> Laura Atkins
> Word to the Wise
> [e-mail]
> [phone]
>
> Email Delivery Blog: https://wordtothewise.com/blog
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>