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