> On 8 May 2021, at 10:50, Matthäus Wander > <mail=40wander.scie...@dmarc.ietf.org> 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
