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
