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

From: Matthäus Wander <[email-masked]>
Date: Sun, 2 May 2021 17:31:04 +0200

I see the following use cases for the envelope_to.

Case 1: Identify mail flows along forwarders.

With an increased adoption of DMARC reporting, we will be getting
reports like this:

Report from $ForwarderOrg:
HeaderFrom=$OriginDomain + EnvFrom=$OriginDomain --> $ForwarderOrg
Report from $RecipientOrg:
HeaderFrom=$OriginDomain + EnvFrom=$ForwarderDomain --> $RecipientOrg

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.

Case 2: Get information for tracing errors.

Let's say you find a DKIM or SPF error from RUA reports and would like
to investigate, because you expect a different outcome. Two real-life
examples I've experienced:

a) We suspect a bug in either our DKIM signer or the recipient's DKIM
verifier (inferred from recipient's RUA report).
b) We are convinced a forwarder breaks DKIM signatures (inferred from a
third-party destination's RUA report).

If one of the involved parties is willing to investigate further, they
ask for the timestamp, sender address and recipient address to trace
their logs. I understand that this is the use case for RUF reports to
shine. I'm arguing that RUA reports suffice, if they contain the day,
sender domain and recipient domain.

Todd Herr wrote on 2021-04-29 14:44:
> I believe all of those things are already possible with the aggregate
> report as it is now, with no need to list the recipient domains. For any
> set of X domains hosted at provider Y, I would expect DMARC validation
> results (i.e., pass or fail) to be consistent across all X domains at
> that provider.

In theory, yes.

In practice:
a) Some forwarders (including large infrastructures) show a wildly
inconsistent behavior with DKIM signatures, which at least to some
degree seems to depend on the recipient domain. If these forwarders
start reporting, I'd need the recipient domain to make sense of their
reports. See also Case 1 above.
b) Some recipients report sporadic SPF or DKIM permerrors for some
messages, while other messages validate correctly. This behavior
probably does not depend on the recipient domain, but see Case 2 above.

Regards,
Matt

---

From: "John Levine" <[email-masked]>
Date: 2 May 2021 16:30:06 -0400

>Without envelope_to, reconstructing the mail flow requires guessing and

It is none of your business to whom I forward my mail. If you think
you know what I am doing and have some objection to the way I am
handling mail you send to my users, you can feel free to stop sending
me mail or stop complaining.

This is a complete non-starter.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Sun, 2 May 2021 19:08:20 -0400

John, your logic is circular. The only way that Matthäus can know if he
objects to what you are doing with his message is to monitor what you are
doing with his message.

It is also irrelevant.  Data privacy is pretty thoroughly lost,
notwithstanding GDMR's efforts to fight the system.   It seems silly to
suggest that you have privacy protection if the RUA report omits the
domain, and privacy loss if it is included.   All the omission does is to
make the problem a little harder, which means the tech giants have an
advantage over the little guy.  As you have already said, and apparently
implemented, one way of gathering this information is to use a different
DKIM selector for every recipient, ensuring feedback that includes both
domain and local-part.

More than anything, your tone bothered me.   This is discussion, not a
battle.  I don't feel a personal stake in the outcome of this discussion,
and I am sympathetic to concerns that reports will get too big.   But
his question is a legitimate topic for discussion..

Doug Foster

On Sun, May 2, 2021, 4:30 PM John Levine <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Hans-Martin Mosner <[email-masked]>
Date: Mon, 3 May 2021 08:27:59 +0200

Am 02.05.21 um 22:30 schrieb John Levine:
> 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 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.

Whether envelope_to would help my work isn't clear, but apparently it would help Matthäus in his work.

Cheers,
Hans-Martin

---

From: Laura Atkins <[email-masked]>
Date: Mon, 3 May 2021 09:48:55 +0100

> On 3 May 2021, at 07:27, Hans-Martin Mosner <[email-masked]> wrote:
> 

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 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
[email-masked]
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

---

From: Douglas Foster <[email-masked]>
Date: Mon, 3 May 2021 07:21:32 -0400

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 <[email-masked]> wrote:

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

---

From: Laura Atkins <[email-masked]>
Date: Mon, 3 May 2021 12:36:46 +0100

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 <[email-masked]> 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.
> 
> On Mon, May 3, 2021 at 4:49 AM Laura Atkins <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 3 May 2021, at 07:27, Hans-Martin Mosner <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> It appears that Matthäus Wander <[email-masked] <mailto:[email-masked]>> said:
> [email-masked] <mailto:[email-masked]>
> (650) 437-0741		
> 
> Email Delivery Blog: https://wordtothewise.com/blog <https://wordtothewise.com/blog>	
> 
> 
> 
> 
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc>

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Douglas Foster <[email-masked]>
Date: Mon, 3 May 2021 08:25:54 -0400

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 <[email-masked]> 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 <
> [email-masked]> wrote:
>
> To address Laura's concerns about individual targeting, the
> reporting needs to ensure a minimum level of aggregation on all reports.
>
>> 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
>> 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
>> 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
>>
>> --

---

From: Matthäus Wander <[email-masked]>
Date: Mon, 3 May 2021 19:21:37 +0200

> It is none of your business to whom I forward my mail.

I'm not quite sure what the problem is, but the solution may be to not
send DMARC reports and to not forward to systems that send DMARC reports.

It's worth noting that even without envelope_from and envelope_to
domains, RUA reports reveal forwarders.

Regards,
Matt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 May 2021 17:13:51 -0700

On Mon, May 3, 2021 at 5:26 AM Douglas Foster <
[email-masked]> wrote:

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

Is that enough?  If I control a domain, I can make up any number of
apparently-valid envelope addresses I want.

> implemented at scale [...]
>

How so?

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Mon, 3 May 2021 21:02:30 -0400

I am open to improvements.  Laura's original point was that an RUA  should
not facilitate stalking.  My inference from that is that it should not
allow reporting on messages to an individual recipient.

One of those attacks would be to use a unique domain to send a single email
to a single recipient.   If I get an RUA report, I have found something
about the individual.   So we need a minimum number of unique recipients
before reporting begins.

As you observe, someone could send a message to the single recipient and a
bunch of messages to made-up targets that are probably invalid.   So
invalid recipients should not count toward the minimum number of unique
recipients.  (Do we want invalid recipients included ever?)

Using many DKIM selectors is the next way to force disaggregation.   If I
use a different DKIM selector for each target domain, I obtain a report
that is substantially disaggregated, in defiance of the omitted To domain.
 If I use a different DKIM selector for each individual, I obtain a report
that tells me something about the disposition and destination of each
individual message (or at least each message which is included in an RUA
report.)

Given the voracious appetite for delivery information, it seems that mass
mailers have an incentive generate DKIM keys for each target email address,
and that when done on a large scale, this will create problems for DNS
performance and email processing performance.   Report generators do not
want that level of complexity in their report generation process, and
privacy advocates do not want to facilitate this level of tracking.

Is there a case to be made that disaggregation is a non-issue?

---

From: "John Levine" <[email-masked]>
Date: 3 May 2021 22:49:41 -0400

>> implemented at scale [...]

Hi.  Passive-aggressive mail operator here.  I have an unlimited number
of addresses in multiple domains (some catchall, some a long list of
explicit addresses) and through the magic of wildcards, every outgoing
message gets a unique DKIM selector.  (If you follow RFC 8198, the DNS
load is insignificant.)

There is a long history of people who thought they did enough
aggregation of various kinds of PII to prevent identification of
individuals and later found out that oops, no, they didn't. So let's
not even try that route.

R's,
John

---

From: Laura Atkins <[email-masked]>
Date: Tue, 4 May 2021 07:59:51 +0100

> On 4 May 2021, at 03:49, John Levine <[email-masked]> wrote:
> 

I agree. My point was not “let’s make this better because...” My point was this is a very bad idea. I used a very personal example, but I’m 100% certain it is not the only relevant use case. 

My opinion is that EnvelopeTo: addresses should not be added to any DMARC reporting. 

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 4 May 2021 11:06:56 +0200

Doug,

On Mon 03/May/2021 14:25:54 +0200 Douglas Foster wrote:
> 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.

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

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

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

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

---

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 5 May 2021 17:58:52 +0000

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 <[email-masked]> On Behalf Of Alessandro Vesely
> Sent: Tuesday, May 4, 2021 5:07 AM
> To: [email-masked]; Douglas Foster
> <[email-masked]>
> Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
>
> Doug,
>
>
> > 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.
>
> changing the envelope from is not enough, From: has to be changed as well
> in order to forward without revealing the final address.
>
>
> However, the aggregate report counts the number of messages, not the
> number of recipients.
>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!R7ZKTY4HhF1wSMZwpruVsXIE5-
> EtRxdlYaxRVkylrlTKnqYLGf-PSpD4ChOUaRGFE27SBql-1Q$

---

From: Barry Leiba <[email-masked]>
Date: Thu, 6 May 2021 10:16:06 -0400

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

---

From: Matthäus Wander <[email-masked]>
Date: Sat, 8 May 2021 11:50:36 +0200

> - We therefore do not have rough consensus to add this.

Allow me to ask for clarification.

- "receiving_domains" has been proposed in #23 as new metadata.
- "receiving_domains" is redundant to "envelope_to", which already
exists in RFC 7489 and is being used in practice by a small portion of
reporters.
- Privacy concerns have been raised, which apply to both elements.
- The proposed "receiving_domains" gets rejected.

What happens to the existing "envelope_to"?

Regards,
Matt

---

From: Laura Atkins <[email-masked]>
Date: Sat, 8 May 2021 12:59:02 +0100

> On 8 May 2021, at 10:50, Matthäus Wander <mail=[email-masked]> wrote:
> 

The proposal objected to was adding a new piece of information to pass along information that would allow reconstruction of a forwarding pathway. 

The current system does not allow for reconstruction of the forwarding pathway. Additionally, there are privacy concerns with reconstruction of the forwarding pathway, among other objections. It is adding more discoverable PII to DMARC. 

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Matthäus Wander <[email-masked]>
Date: Sat, 8 May 2021 14:29:11 +0200

Laura Atkins wrote on 2021-05-08 13:59:
> The proposal objected to was adding a new piece of information to pass
> along information that would allow reconstruction of a forwarding pathway. 
> 

This was not meant as a proposal. It is an explanation of what is
possible with the envelope_to that exists in the spec already:
<https://tools.ietf.org/html/rfc7489#page-69>

> The current system does not allow for reconstruction of the forwarding
> pathway.

I agree in that envelope_to makes it easier for reconstruction of the
pathway, but disagree otherwise. DMARC reporting in principle allows for
reconstruction of the pathway, as noted in the privacy considerations:
<https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-6.1>
Other proposals in the current I-Ds contribute to this privacy threat
and may be worth a separate discussion:
- #57 requires reporting of selectors, which can be exploited for tracking.
- #62 makes reporting mandatory, which leaves the mail receiver with no
means to mitigate the privacy threat.

Regards,
Matt

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 8 May 2021 16:30:48 +0200

> <https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-6.1>

The second paragraph says:

    Aggregate report may expose sender and recipient identifiers,
    specifically the RFC5322.From addresses.

It is bogus.  The email addresses contained in a DMARC aggregate report are 
limited to <report_metadata>.

I'm realizing now that envelope_from has a minOccurs="1".  How come?  I never 
generated one, yet I syntax-checked generated reports and never noticed that 
defect.  And I cannot comply in case of NDRs.

Anyway, given:

Is the meaning of "-->" the guessing of envelope_to?

The latter implies $ForwarderDomain changed the envelope sender.  More often 
it's left intact or emptied.

> - #57 requires reporting of selectors, which can be exploited for tracking.

Yes.  Sender has to keep the selector <---> recipient association.  That way it 
can track the forwarding chain.  Yet, the information gathered isn't much more 
than positive DSNs.  In particular, this method doesn't disclose the local 
parts of the addresses.

> means to mitigate the privacy threat.

Making it mandatory is possible since RFC 8962 established the protocol police.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 8 May 2021 11:11:36 -0700

> > means to mitigate the privacy threat.

#62 (assuming it has WG consensus) makes it clear we really want reporting
to be mandatory, but at a glance I don't see any "MUST generate" sort of
language in the draft.  It may be in the other draft, but I haven't looked
there yet.  This draft does a pretty firm job of extolling the virtues of
report generation, however.

Personally, I think mandatory reporting wouldn't survive Last Call or IESG
Evaluation.  Even if it did, there's no mechanism to enforce it (i.e.,
operators that don't want to send such reports simply won't, and that's
that), other than maybe industry peer pressure, so I think what's in the
draft is as close as we can get.

Making it mandatory is possible since RFC 8962 established the protocol
> police.

I trust we're all aware of the significance of the publication date of that
RFC.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 8 May 2021 14:51:15 -0400

It appears that Murray S. Kucherawy  <[email-masked]> said:
>Evaluation.  Even if it did, there's no mechanism to enforce it ...

Indeed.  I check DMARC on all my incoming mail, but it is unlikely
that I will ever get around to sending reports.  I am not expecting
the Protocol Police to break the door down.

More to the point, IETF standards tell people what to do if you want
to interoperate, not how the document's authors might wish the world
were different. You can obviously implement all of DMARC processing on
inbound mail without ever sending a report, so in this place MUST is
simply wrong.

R's,
John

---

From: Todd Herr <[email-masked]>
Date: Mon, 10 May 2021 08:27:36 -0400

> draft is as close as we can get.
#62 is not consensus. #62 was the impetus for the proposed text on the
topic that is Section 6.7.5 in draft-ietf-dmarc-dmarcbis-01.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 10 May 2021 18:01:41 +0200

NOTE: adjusted ticket number, #23 to #62

On Sat 08/May/2021 20:51:15 +0200 John Levine wrote:
> that I will ever get around to sending reports.

It'd be interesting to know what refrains you to do DMARC aggregate reports.

For the opposite POV, I can say I generate these reports because they make an 
interesting, albeit partial, view of my incoming mail traffic.  Then, among the 
silly reasons why I send them:

* I don't think any PII leaks out that way,
* the spirit of global community suggests helping peers is a Good Thing,
* outgoing reports constitute a relevant part of my nanoscopic outgoing 
traffic, so they help keep my IP warm.

> inbound mail without ever sending a report, so in this place MUST is

Agreed, SHOULD seems to be the right world here.  I'd expect your reply to the 
above question to provide subject matter for the reasons why an operator may 
want to not do it.  In addition, there could be reasons for not sending a 
specific aggregate report, such as locally imposed or remotely requested size 
limits, and local policy about the target domain, its IP(s), country, or whatever.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 10 May 2021 12:09:51 -0400

> It'd be interesting to know what refrains you to do DMARC aggregate reports.

It's a large amount of programming work to manage the database and extract 
and create the reports.  If I had nothing better to do I might do it but 
it is a very very low priority, particulary considering how small my site is.

> Agreed, SHOULD seems to be the right world here.  I'd expect your reply to 
> the above question to provide subject matter for the reasons why an operator 
> may want to not do it.

MAY is correct but I can live with SHOULD.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly