A long time ago, John said something like, "It is not the sender's business whether I forward my mail or where I send it." Later, Laura expressed concern about malicious actors trying to obtain forwarding data to facilitate stalking. I have found these arguments persuasive, and its fits well with my current position that evaluators should not have to do extra work on every message to satisfy the vaguely-defined reporting whims of domain owners.
On the other hand, our specification must allow for extra identifiers to be documented, to ensure upward compatibility with RFC 7489. Some evaluators will be willing to provide that extra information indefinitely. Domain owner reporting is intended to help the domain owner verify that his senders are properly configured or to identify a confirmed malicious actor that needs law enforcement action. ARC reporting is intended to help a forwarder know whether From munging is needed or unmunging was provided. They are different data sets created for different purposes and send to different actors. As long as they are not mixed, I am OK with trying to develop a specification for ARC reporting, as part of an overall review of ARCs effectiveness. Doug On Tue, Oct 25, 2022 at 4:33 AM Alessandro Vesely <[email protected]> wrote: > 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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
