On Tue, Jul 11, 2017 at 9:12 AM, Kurt Andersen (b) <[email protected]> wrote:
> > 1) Include the additional information in the AAR which is wanted > downstream for a DMARC report to be emitted from a receiver N hops away - > this requires additional fields to the basic RFC7601 A-R spec > This seems to be the least painful, since ARC "owns" AAR and is thus free to do what it wants here, but then there's no way to do what you want in non-ARC environments which I infer would be a helpful thing from Seth's comments. > 2) Create a fourth member of the ARC set of headers to convey this > additional information (this is partially was was proposed with the > Origin-IP header, but not fleshed out enough to be really useful in an > unlimited number of hops scenario). > I think that's even cleaner. I'm somewhat opposed to creating a fourth member for an ARCset because I > think that increases the fragility of the chain, > How is it any more fragile than already having to stack and hash ordered groups of three ordered things? > but, OTOH, it may be an easier delta for new implementers than creating a > basic A-R and an "enhanced" version to post as the AAR. I'm definitely > opposed to making these fields *required* because that would require ARC > validation to parse the AAR (or fourth header) to determine validity and > we've tried to stay away from that (leaving it to the report generating > code to have to worry about AAR contents). > You would just need to be clear in prose how its presence and/or absence is expected to affect interoperability (if at all). -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
