On Fri, Jul 7, 2017 at 11:29 PM, Murray S. Kucherawy <[email protected]> wrote:
> On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank <[email protected]> wrote: > >> Or maybe, put a different way, the question is: what's the simplest way, >> with the least delta to the spec, that allows for transmission of selectors >> and source ip? This would enable DMARC reports for messages delivered due >> to ARC to have the same report payload as messages delivered directly. >> > > I would suggest not specifying it at all, and letting implementations > figure out some private way to do it that works for them. > > To give a real example, OpenARC could put it in A-R or A-A-R if it wants > to, to be consumed downstream by OpenDMARC. But the ARC RFC doesn't have > to say that this is "the" way to do it. This is fine since RFC7601 says > anything else that ever sees an unknown ptype.property pairing ("header.s", > for example) is not supposed to use it. > I think it needs to be specified. Receivers construct DMARC reports in a known manner, they shouldn't need to guess how to get the appropriate information out of ARC headers in an intermediary-implementation-specific manner. The spec should make it unambiguous how information can be transmitted to the receivers in a consistent and interoperable manner. > -MSK >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
