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

[Matthäus Wander <[e-mail]>]

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