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

[Todd Herr]

On Sat, May 8, 2021 at 2:12 PM Murray S. Kucherawy 
wrote:

> On Sat, May 8, 2021 at 7:31 AM Alessandro Vesely  wrote:
>
>> > - #62 makes reporting mandatory, which leaves the mail receiver with no
>> > 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.
>
>
#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:* todd.h...@valimail.com
*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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

It appears that Murray S. Kucherawy   said:
>Personally, I think mandatory reporting wouldn't survive Last Call or IESG
>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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Sat, May 8, 2021 at 7:31 AM Alessandro Vesely  wrote:

> > - #62 makes reporting mandatory, which leaves the mail receiver with no
> > 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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Sat 08/May/2021 14:29:11 +0200 Matthäus Wander wrote:

Laura Atkins wrote on 2021-05-08 13:59:


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:




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 .


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:

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

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

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

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




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.



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.




- #62 makes reporting mandatory, which leaves the mail receiver with no
means to mitigate the privacy threat.



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



Best
Ale
--




















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Matthäus Wander]

Laura Atkins wrote on 2021-05-08 13:59:
>> What happens to the existing "envelope_to"?
> 
> The proposal objected to was adding a new piece of information to pass
> along information that would allow reconstruction of a forwarding pathway. 
> 
> Case 1: Identify mail flows along forwarders.

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:


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

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Laura Atkins]

> On 8 May 2021, at 10:50, Matthäus Wander 
>  wrote:
> 
> Barry Leiba wrote on 2021-05-06 16:16:
>> 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.
> 
> 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"?


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

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.

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 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

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







___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Matthäus Wander]

Barry Leiba wrote on 2021-05-06 16:16:
> 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.

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Barry Leiba]

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
 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  On Behalf Of Alessandro Vesely
> > Sent: Tuesday, May 4, 2021 5:07 AM
> > To: dmarc@ietf.org; Douglas Foster
> > 
> > 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 1, 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 dom

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

[Brotman, Alex]

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  On Behalf Of Alessandro Vesely
> Sent: Tuesday, May 4, 2021 5:07 AM
> To: dmarc@ietf.org; Douglas Foster
> 
> 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 1, 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

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

[Alessandro Vesely]

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 1, 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://www.ietf.org/mailman/listinfo/dmarc

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

[Laura Atkins]

> On 4 May 2021, at 03:49, John Levine  wrote:
> 
> It appears that Murray S. Kucherawy   said:
>> Is that enough?  If I control a domain, I can make up any number of
>> apparently-valid envelope addresses I want.
>> 
>> Using DKIM selectors for tracking will also put a huge load on DNS if
>>> 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.

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 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

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







___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

It appears that Murray S. Kucherawy   said:
>Is that enough?  If I control a domain, I can make up any number of
>apparently-valid envelope addresses I want.
>
>Using DKIM selectors for tracking will also put a huge load on DNS if
>> 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


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Douglas Foster]

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?

On Mon, May 3, 2021, 8:14 PM Murray S. Kucherawy 
wrote:

> On Mon, May 3, 2021 at 5:26 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> 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.
>
> Using DKIM selectors for tracking will also put a huge load on DNS if
>> implemented at scale [...]
>>
>
> How so?
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Mon, May 3, 2021 at 5:26 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> 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.

Using DKIM selectors for tracking will also put a huge load on DNS if
> implemented at scale [...]
>

How so?

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Matthäus Wander]

John Levine wrote on 2021-05-02 22:30:
> It appears that Matthäus Wander  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.

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Douglas Foster]

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  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 <
> dougfoster.emailstanda...@gmail.com> 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 
> wrote:
>
>>
>>
>> On 3 May 2021, at 07:27, Hans-Martin Mosner  wrote:
>>
>> Am 02.05.21 um 22:30 schrieb John Levine:
>>
>> It appears that Matthäus Wander  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 

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

[Laura Atkins]

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  
> 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  > wrote:
> 
> 
>> On 3 May 2021, at 07:27, Hans-Martin Mosner > > wrote:
>> 
>> Am 02.05.21 um 22:30 schrieb John Levine:
>>> It appears that Matthäus Wander >> > 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
> la...@wordtothewise.com 
> (650) 437-0741
> 
> Email Delivery Blog: https://wordtothewise.com/blog 
>   
> 
> 
> 
> 
> 
> 
> 

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

[Douglas Foster]

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

>
>
> On 3 May 2021, at 07:27, Hans-Martin Mosner  wrote:
>
> Am 02.05.21 um 22:30 schrieb John Levine:
>
> It appears that Matthäus Wander  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
> la...@wordtothewise.com
> (650) 437-0741
>
> Email Delivery Blog: https://wordtothewise.com/blog
>
>
>
>
>
>
>
> ___
> 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

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

[Laura Atkins]

> On 3 May 2021, at 07:27, Hans-Martin Mosner  wrote:
> 
> Am 02.05.21 um 22:30 schrieb John Levine:
>> It appears that Matthäus Wander  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
la...@wordtothewise.com
(650) 437-0741  

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







___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Hans-Martin Mosner]

Am 02.05.21 um 22:30 schrieb John Levine:
> It appears that Matthäus Wander  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 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


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Douglas Foster]

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

> It appears that Matthäus Wander  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. 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
>
> ___
> 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

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

[John Levine]

It appears that Matthäus Wander  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. 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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Matthäus Wander]

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Todd Herr]

On Wed, Apr 28, 2021 at 9:22 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I understand that additional detail might make the reporting effort
> unacceptable to the big organizations that are creating them, and this
> reason alone may prevent alternatives.
>
> It seems that the potential uses for reports are:
> - Identifying and fixing my own infrastructure problems
> - Celebrating when the reports show that I have no new infrastructure
> problems.
> - Celebrating when malicious impersonators are blocked.
> - Learning about non-malicious impersonators that must be tolerated.
> - Identifying delivery problems that warrant a conversation with the
> recipient organization.
>

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.

>
> I cannot successfully call a recipient help desk and ask them why they are
> blocking my messages.   Instead, I need a message recipient to call his
> help desk and ask why he is not getting my messages, and that subscriber
> might be happy to be asked for assistanceNavigating from a server IP
> address to a known subscriber might be no easy feat, while navigating from
> a server IP and target domain to that subscriber would be easier.
>

I read this and I perceive that you are assuming that DMARC failures will
be the only reason for mail to be rejected, and that all mail that passes
DMARC checks will be accepted. Neither of those assumptions are necessarily
true, and many if not most delivery problems will be independent of DMARC.
DMARC allows for reliable association of an identity and its accumulated
reputation with a mail message, and it's that accumulated reputation that
will drive whether or not the message is delivered.

>
>
> In short, what are the expected uses of the RUA reports?   Are there any
> intended purposes other than fixing my own infrastructure configuration?
>

Regardless of what the original intent of the aggregate reports might've
been, for all practical purposes they're only valuable for auditing one's
own authentication practices and configuration, in my opinion. It's
actually a perhaps underappreciated feature of DMARC, in that one can use
DMARC at p=none to conduct a full and complete audit simply by consuming
aggregate reports over time and addressing problems with one's own mail
streams that the reports might show. Once enough time has passed and the
report consumer is sure that all of its mail streams have been reported
upon and are properly authenticating, the domain owner can publish a more
strict policy (p=quarantine or p=reject) if it so chooses. For
authentication failures shown in the reports that are the result of mail
the domain owner did not send, I haven't yet met an abuse desk that will
act on anything other than headers (assuming that they'll act at all), so
it's not actionable data. The value in this subset of the data really lies
in seeing that such mail ends up failing to reach its destination once the
domain owner changes its policy to something stronger than p=none and
report generators start to honor that policy.


-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Douglas Foster]

I understand that additional detail might make the reporting effort
unacceptable to the big organizations that are creating them, and this
reason alone may prevent alternatives.

It seems that the potential uses for reports are:
- Identifying and fixing my own infrastructure problems
- Celebrating when the reports show that I have no new infrastructure
problems.
- Celebrating when malicious impersonators are blocked.
- Learning about non-malicious impersonators that must be tolerated.
- Identifying delivery problems that warrant a conversation with the
recipient organization.

I cannot successfully call a recipient help desk and ask them why they are
blocking my messages.   Instead, I need a message recipient to call his
help desk and ask why he is not getting my messages, and that subscriber
might be happy to be asked for assistanceNavigating from a server IP
address to a known subscriber might be no easy feat, while navigating from
a server IP and target domain to that subscriber would be easier.

In short, what are the expected uses of the RUA reports?   Are there any
intended purposes other than fixing my own infrastructure configuration?

On Wed, Apr 28, 2021 at 8:34 AM Todd Herr  wrote:

> Apologies to Matt; I sent this originally only to him when I meant to send
> it to the list...
>
> On Wed, Apr 28, 2021 at 4:27 AM Matthäus Wander  40wander.scie...@dmarc.ietf.org> wrote:
>
>> Hello everyone,
>>
>> I'm new to the party. I'd like to bring in some practical experience of
>> working with DMARC rua reports.
>>
>> #23 introduces "receiving_domains" in the report metadata, justified by
>> large infrastructures that host a large number of domains (e.g. Google).
>>
>> I think, this information would be more useful per-record rather than in
>> the global metadata. As large infrastructures tend to include many
>> different records in the report, the analyst needs a correlation between
>> record and recipient domain.
>>
>> The  section has an optional "envelope_to" already:
>> >
>> >> >minOccurs="0"/>
>>
>> Is there a benefit in the global "receiving_domains" over the per-record
>> "envelope_to"?
>>
>> Most reporters don't include "envelope_to" (e.g. Google). This field
>> could be made more prominent in the draft. The main body mentions
>> "header_from" only, but neither "envelope_to" nor "envelope_from".
>>
>
> There is a hole in my understanding of this topic that I'm hoping someone
> can fill here, and that hole is this: I don't understand the value of
> reporting out receiving domains.
>
> The reason I don't understand it is because my expectation as a sender
> receiving a report about my sending domain would be that my DMARC
> validation results from a given receiving infrastructure would generally
> not vary across the different receiving domains, regardless of if there was
> one domain, ten domains, or ten thousand domains hosted by the reporting
> infrastructure. To extend my expectations further, unless I'm dedicating
> part of my infrastructure to sending solely to one and only one receiving
> site, I would expect my DMARC validation results to generally not vary
> across different reporting infrastructures. I'm declaring here that "DMARC
> validation results" are separate from "applied receiver handling policy"
> because as a sender I can only control the former; "DMARC validation
> results" means "whether or not SPF and/or DKIM passed and was aligned and
> consequently resulted in a DMARC pass or fail".
>
> If I'm reading draft-ietf-dmarc-aggregate-reporting-02 correctly,
> receiving_domains, defined as the "List of domains which received messages
> for the domain in this report" I guess it could perhaps help me as a report
> consumer in the case where I receive a report from an previously unknown or
> unfamiliar to me reporter that hosts many domains, and if that's the use
> case, then perhaps the field ought to be amended to "List of the top
> $SMALL_NUMBER domains which received messages for the domain in this
> report" because as a report consumer I don't need to see 837 domains listed
> when realistically one or two will suffice.
>
> What is the value that I'm not seeing in reporting out receiving domains?
> --
>
> *Todd Herr* | Sr. Technical Program Manager
> *e:* todd.h...@valimail.com
> *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.
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>

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

[Brotman, Alex]

Matt,

While, yes, there is the existing envelope_to, there was a request to add this 
to the report format (which I believe I did as the submitter desired).  I would 
assume we’d hash it out on the list and remove one of them.

However, from an operator side of things, I tend to align with Todd on this.  
Could someone provide a real-world example of where reporting the destination 
domain assisted them in resolving an issue?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: dmarc  On Behalf Of Todd Herr
Sent: Wednesday, April 28, 2021 8:34 AM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

Apologies to Matt; I sent this originally only to him when I meant to send it 
to the list...

On Wed, Apr 28, 2021 at 4:27 AM Matthäus Wander 
mailto:40wander.scie...@dmarc.ietf.org>> 
wrote:
Hello everyone,

I'm new to the party. I'd like to bring in some practical experience of
working with DMARC rua reports.

#23 introduces "receiving_domains" in the report metadata, justified by
large infrastructures that host a large number of domains (e.g. Google).

I think, this information would be more useful per-record rather than in
the global metadata. As large infrastructures tend to include many
different records in the report, the analyst needs a correlation between
record and recipient domain.

The  section has an optional "envelope_to" already:
>
>minOccurs="0"/>

Is there a benefit in the global "receiving_domains" over the per-record
"envelope_to"?

Most reporters don't include "envelope_to" (e.g. Google). This field
could be made more prominent in the draft. The main body mentions
"header_from" only, but neither "envelope_to" nor "envelope_from".

There is a hole in my understanding of this topic that I'm hoping someone can 
fill here, and that hole is this: I don't understand the value of reporting out 
receiving domains.

The reason I don't understand it is because my expectation as a sender 
receiving a report about my sending domain would be that my DMARC validation 
results from a given receiving infrastructure would generally not vary across 
the different receiving domains, regardless of if there was one domain, ten 
domains, or ten thousand domains hosted by the reporting infrastructure. To 
extend my expectations further, unless I'm dedicating part of my infrastructure 
to sending solely to one and only one receiving site, I would expect my DMARC 
validation results to generally not vary across different reporting 
infrastructures. I'm declaring here that "DMARC validation results" are 
separate from "applied receiver handling policy" because as a sender I can only 
control the former; "DMARC validation results" means "whether or not SPF and/or 
DKIM passed and was aligned and consequently resulted in a DMARC pass or fail".

If I'm reading draft-ietf-dmarc-aggregate-reporting-02 correctly, 
receiving_domains, defined as the "List of domains which received messages for 
the domain in this report" I guess it could perhaps help me as a report 
consumer in the case where I receive a report from an previously unknown or 
unfamiliar to me reporter that hosts many domains, and if that's the use case, 
then perhaps the field ought to be amended to "List of the top $SMALL_NUMBER 
domains which received messages for the domain in this report" because as a 
report consumer I don't need to see 837 domains listed when realistically one 
or two will suffice.

What is the value that I'm not seeing in reporting out receiving domains?
--
Todd Herr | Sr. Technical Program Manager
e: todd.h...@valimail.com<mailto:todd.h...@valimail.com>
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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Todd Herr]

Apologies to Matt; I sent this originally only to him when I meant to send
it to the list...

On Wed, Apr 28, 2021 at 4:27 AM Matthäus Wander  wrote:

> Hello everyone,
>
> I'm new to the party. I'd like to bring in some practical experience of
> working with DMARC rua reports.
>
> #23 introduces "receiving_domains" in the report metadata, justified by
> large infrastructures that host a large number of domains (e.g. Google).
>
> I think, this information would be more useful per-record rather than in
> the global metadata. As large infrastructures tend to include many
> different records in the report, the analyst needs a correlation between
> record and recipient domain.
>
> The  section has an optional "envelope_to" already:
> >
> > >minOccurs="0"/>
>
> Is there a benefit in the global "receiving_domains" over the per-record
> "envelope_to"?
>
> Most reporters don't include "envelope_to" (e.g. Google). This field
> could be made more prominent in the draft. The main body mentions
> "header_from" only, but neither "envelope_to" nor "envelope_from".
>

There is a hole in my understanding of this topic that I'm hoping someone
can fill here, and that hole is this: I don't understand the value of
reporting out receiving domains.

The reason I don't understand it is because my expectation as a sender
receiving a report about my sending domain would be that my DMARC
validation results from a given receiving infrastructure would generally
not vary across the different receiving domains, regardless of if there was
one domain, ten domains, or ten thousand domains hosted by the reporting
infrastructure. To extend my expectations further, unless I'm dedicating
part of my infrastructure to sending solely to one and only one receiving
site, I would expect my DMARC validation results to generally not vary
across different reporting infrastructures. I'm declaring here that "DMARC
validation results" are separate from "applied receiver handling policy"
because as a sender I can only control the former; "DMARC validation
results" means "whether or not SPF and/or DKIM passed and was aligned and
consequently resulted in a DMARC pass or fail".

If I'm reading draft-ietf-dmarc-aggregate-reporting-02 correctly,
receiving_domains, defined as the "List of domains which received messages
for the domain in this report" I guess it could perhaps help me as a report
consumer in the case where I receive a report from an previously unknown or
unfamiliar to me reporter that hosts many domains, and if that's the use
case, then perhaps the field ought to be amended to "List of the top
$SMALL_NUMBER domains which received messages for the domain in this
report" because as a report consumer I don't need to see 837 domains listed
when realistically one or two will suffice.

What is the value that I'm not seeing in reporting out receiving domains?
-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc