On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank <[email protected]> wrote:
> 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. > So evidently we've got a conflict between what A-R was intended to be used for, and an apparent need to create a channel between ARC and DMARC to relay stuff like selectors and source IP addresses. If consensus exists that the need is real and in scope for this WG, we either need to come to consensus on allowing feature creep of A-R, or come up with another way to meet that need. With respect to the source IP in particular, we had that battle all the way up to a formal appeal to the IESG and that too was resolved with a decision that such details weren't appropriate for A-R. This resulted in what is now Appendix C of RFC7601, and the client IP address was left out. Also, assuming you're referring to the ARC base draft, I don't agree that "with the least delta to the spec" is a legitimate constraint here. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
