On Wed, May 31, 2017 at 9:20 PM, Murray S. Kucherawy <superu...@gmail.com> wrote:
> What we're seeking to do here is add it to A-R as a way to get that > information through to a place where DMARC can get it to include in > reports. If we want to redefine what A-R is to meet that requirement, then > that's something consensus could certainly do, but if not, I'd prefer not > to use it as a substrate against its stated purpose. > Absolutely understood, and agreed. > We could also, however, standardize "X-Source-IP" (without the "X-", of > course) and use that, as it already has numerous consumers and other > applications well beyond ARC and DMARC. > > Okay. My original point for smtp.client-id was simply to transfer the source_ip for a DMARC report, because it is valuable for a final report consumer. I suggested the AR because it seemed like the cleanest way without needing to modify the spec. Clearly transmission via the AR/AAR is the wrong way to do this based on the purpose of the AR. So I guess returning to the original thread, there are two matters: 1) Should we stamp header.b in the A-R? (consensus seems to be yes) 2) How should we transmit the source_ip for the DMARC report? Murray, does your suggestion mean a separate doc regarding a signed Source-IP header that would then be referenced in ARC and covered by... what, the AS? Or is there a cleaner way? Thanks for the context and suggestion! Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols s...@valimail.com +1-415-894-2724 <415-894-2724>
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
