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. On Mon, Oct 24, 2022, 1:21 PM Brotman, Alex <Alex_Brotman= 40comcast....@dmarc.ietf.org> wrote: > There is a portion of the proposed aggregate document that affords one the > opportunity to use “extensions”, which could potentially be applied to ARC > (or any other reporting extension one would like to define). Mindful, this > still applies within the framework of DMARC. So how the report recipient > is identified is still tied to that same mechanism, though would allow Doug > to define/create an “ARC Report” that is somewhat independent. > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:* dmarc <dmarc-boun...@ietf.org> *On Behalf Of * Dotzero > *Sent:* Monday, October 24, 2022 12:36 PM > *To:* dmarc@ietf.org > *Subject:* Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result > > > > > > > > On Mon, Oct 24, 2022 at 5:47 AM Alessandro Vesely <ves...@tana.it> wrote: > > On Sun 23/Oct/2022 14:16:30 +0200 Dotzero wrote: > > On Sun, Oct 23, 2022 at 6:29 AM Alessandro Vesely <ves...@tana.it> > wrote: > >> On Sat 22/Oct/2022 18:25:55 +0200 Dotzero wrote: > >>> Unaligned signatures are orthogonal/irrelevant to DMARC. They may be > useful in > >>> other contexts. In the DKIM standard, signatures mean that the signer > is > >>> asserting some (unspecified) responsibility for the signed message. > That may be > >>> useful for some reputation systems. > >> > >> Somewhat skewed w.r.t. orthogonality, actually. Indirect flows are > >> explicitly mentioned in the I-D as a reason to override DMARC > dispositions: > > > > DMARC only gives a pass if either SPF or DKIM passes. Unaligned DKIM > > signatures will NEVER give a DMARC pass. > > > How about dmarc=redeemed? > > > >> There MAY be an element for reason, meant to include any notes the > >> reporter might want to include as to why the disposition policy does > >> not match the policy_published, such as a Local Policy override > >> (possible values listed in Appendix A). > > > > Local Policy is just that. When a Receiver invokes Local Policy it is > > saying "I don't care what DMARC says, I'm choosing to ignore DMARC > Policy > > and do something else". > > > It is a local decision to trust an ARC seal or an unaligned signature, > depending on the signing domains. Yet, the decision can be made by the > same > filter which looked up the From: domain policy. > > > > It may or may not be performed by the same filter which looked up the > From: domain policy. So what? That same filter may also consider reputation > while the SMTP session is held open. That doesn't make reputation part of > DMARC. > > > > >> ARC too is a kind of unaligned signature, albeit with a bunch of > >> additions. The extra information it carries, designed to bestow enough > >> trust in the chain of custody to outweigh the self-referential reliance > of > >> aligned From:, doesn't substantially change the semantic of DKIM > >> signatures. And we should say how to report it, sooner or later. > > > ARC != DMARC. It is a separate RFC that gives participants an > alternative > > means of evaluating mail flows when DKIM signatures are broken. Nothing > > more and nothing less. > > > > ARC is a different signature not an "unaligned signature". > > > > > > Conflicting protocols? ARC was devised by the DMARC WG, during the phase > of > "improving the identification of legitimate sources that do not currently > conform to DMARC requirements." So, yes, on the one hand, since unaligned > signatures don't conform to DMARC requirements, they're not DMARC. On the > other hand, as a fusion of deterministic authentication techniques and > domain > policies, DMARC is intrinsically extensible. For aggregate reporting in > particular, we explicitly provide for extensions. > > > > Splitting out reporting is a good thing. Perhaps it should be renamed so > that it is not DMARC centric. I would suggest the fact that something (ARC) > which is not DMARC is included in the reporting that was developed as an > integral part of DMARC is a matter of convenience more than anything else. > > > > >> I'm not proposing to mandate the evaluation of any evaluable item. > >> However, I'd neither discourage it. Perhaps technology will provide us > >> with ecological sources of energy. > > > > There is nothing wrong with using whatever data points you have > available. > > That doesn't necessarily mean that such evaluations and choices are > DMARC. > > > If ARC were a separate thing, it'd make no sense to include its data in > DMARC > aggregate reports. > > > > As I wrote above, it is more a matter of convenience than anything else. > Generating separate ARC reports is duplicative effort from both a report > generating perspective as well as consumption of those reports. > > > I think what we could do is to identify some criteria that a report > generator > may follow, such as doing everything, reporting up to X signatures, or > doing > SPF only. Such meta data could be useful to report consumers, along with > the > generator's software/version. > > > Best > Ale > -- > > > > Michael Hammer > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
