On Mon 24/Oct/2022 22:30:06 +0200 Douglas Foster wrote:
If there is detailed ARC reporting, the only target should be the forwarder, as
the message originator and domain owner are not parties to the ARC process.
Consequently, ARC reporting cannot be part of the aggregate report going to the
domain owner.
To send reports to the ARC domain owner, we will need a DNS token for them to
request those reports. This could be a new token in the DMARC policy record,
if we can assume that forwarders would be willing to publish a DMARC policy to
also obtain ARC reports.
Given the trust issues around ARC, I think only acceptance events should be
reported to the ARC domain.
The message's domain owner can get a status of "accepted by local policy," with
a code for ARC as the supporting reason. This is equivalent to "redeemed" but
less disruptive to installed base. I see no reason to give him anything more.
A bank, say, can be interested in knowing who forwards its messages and whether
they are trusted as forwarders. It is the very same kind of business that
allows the bank to have feedback about affiliated forwarders —those whose
public key is published in the bank's zone.
DMARC looks up records based on the domain in an email address, not on a
signature's d=. BTW, the d= and authserv-id domains of an ARC set can well be
three distinct domains.
Let's consider a message from someone@A, munged as someone@B, forwarded by C.
The message contains various signatures and a long ARC chain. A report
generator prepares a row where this message is aggregated according to the
authentication status of the evaluated tokens. If we extend DMARC linearly,
besides the address at _dmarc.B —the munged From: domain— we can include the
same row in the report sent to the address found at _dmarc.C where C is the
domain in Sender:, notwithstanding Appendix A3.
By the same token, we could consider _dmarc.A if there was an Author: domain
pointing there. We can say that while From: defines message ownership,
Author:, Sender, and possibly Resent-From: claim some interest in the message
and the aligned authenticator(s). Or do we look up DMARC records at the d=
domains?
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
