On Thu, Jul 6, 2017 at 10:19 AM, Seth Blank <s...@sethblank.com> wrote:
> This thread is only about encapsulating information useful for a consumer > of DMARC reports, as that consumer will not have the message and its > headers. Selectors are critical here for tying things together. > > The DMARC report data is generated from the AAR, because the AAR > transports the relevant data (the receiver only has data on the last hop > without the AAR) in a signed manner that survives manipulations to the > chain. Data gets into the AAR by first being stamped in the A-R and then > getting encapsulated when the ARC Set is Sealed. > > So putting selectors in the A-R accomplishes transmitting selectors for > use in a DMARC report cleanly; only a ptype needs to be registered, and no > changes to the spec or AAR construction are needed. > I think this presupposes that there's some connective tissue between, but distinct from, the DMARC report generator and the ARC implementation. Do we have to presume that, or is it enough to make space for it in the DMARC report, and then not specify how that information goes from one component to the next? Then an operator can decide how to move that information between those two components however it sees fit, and there's no need to rub up against A-R's intended use (which I would argue doesn't include relaying selectors downstream). -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
