On Thu, Jul 6, 2017 at 6:05 PM, Murray S. Kucherawy <superu...@gmail.com> wrote: > > I think this presupposes that there's some connective tissue between, but > distinct from, the DMARC report generator and the ARC implementation. Do > we have to presume that, or is it enough to make space for it in the DMARC > report, and then not specify how that information goes from one component > to the next? Then an operator can decide how to move that information > between those two components however it sees fit, and there's no need to > rub up against A-R's intended use (which I would argue doesn't include > relaying selectors downstream). >
So this is a very fair comment. But I think it's deeply problematic. In the case of a direct mail flow, the receiver has all the needed information from the SMTP connection and A-R payload to create a report. None of this information is present once a message arrives at a receiver in an indirect manner. I would strenuously argue the charter's call for "eliminating the DMARC's effects on indirect mail flows" requires that reporting - which is the fundamental feedback mechanism for a sender - work properly under said fixes. This is impossible for a receiver to do without ARC passing the information along. And ARC has this transmission mechanism in its AAR, but we need to make sure the appropriate information is in it.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
