On Mon, Jul 10, 2017 at 12:48 PM, Brandon Long <bl...@google.com> wrote: > > > On Mon, Jul 10, 2017 at 12:27 AM, Murray S. Kucherawy <superu...@gmail.com > > wrote: > >> On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank <s...@sethblank.com> wrote: >> >>> 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. >>> >> >> How do receivers include the source IP address in DMARC records today, >> when A-R doesn't give it to them? >> > > I think this highlights the challenge we're having with this conversation. > > Today, DMARC reports only contain information about the current hop where > the report is being generated. > > Obviously, at the current hop, any information available to that hop, such > as IP and selectors, can be logged directly for generating the report. > > We're talking about how, with ARC, we want to include information in the > DMARC report from the previous hops. The best way to pass information from > previous hops is through the AAR. > > It might be possible to parse the Received headers for IPs, or extract the > selectors by walking the header.b information that is in the AAR headers, > but obviously being more direct is preferred. >
On Sat, Jul 8, 2017 at 9:25 PM, Murray S. Kucherawy <superu...@gmail.com> wrote: > > 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. > As I see it, there are two possible approaches to address this dilemma: 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 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'm somewhat opposed to creating a fourth member for an ARCset because I think that increases the fragility of the chain, 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). --Kurt
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
