On Wed, Jul 5, 2017 at 10:42 PM, Murray S. Kucherawy <[email protected]> wrote:
> Are we talking about adding this to the DMARC reports or to A-R? Both > have been suggested in this thread. > > I believe you're specifically talking about DMARC reports, and I have less > of a concern with those. On the other hand, adding them to A-R makes less > sense because that's got users partly in mind, and I don't think a user > would care too much what selector is being used in a DKIM signature. > Explicitly discouraging development of reputation based on an s=/d= pairing > would be an added bonus. > I think the reputation conversation here is a red herring. Anyone making a reputation decision (i.e. receivers) would be in receipt of the actual message, with the DKIM-Signature blocks and all other headers, and can use whatever data they want, including far more than a d,s pairing, to make a reputation judgement. 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. It was floated a while back on the list of putting this information in only the AAR and not the A-R directly, but that was shot down because the consensus was the AAR should only transit information that had been stamped in an A-R, and not additional data. I'm happy to revisit this, I think selectors and source ip make more sense in the AAR than the A-R (and then we don't need new ptypes or additional headers for transmission), but I thought I'd already lost that battle ;-) Seth > -MSK >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
