On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein <[email protected]> wrote:
> So as a consumer of these reports I'd definitely like to see a structured > value with as much information as possible. > > The ideal would be to get as much information as we'd get if the final > receiver had seen the original email directly at i=0. So that would mean: > > - SPF Result and SPF domain > - For each DKIM signature on the i=0 email, the result and the > domain. This should show all signatures from the original message, > regardless of status > > Aren't those in the DMARC report already? > > - > - DKIM Selectors - Unfortunately we probably can't get the DKIM > signature selectors (because they aren't generally recorded in the > Authentication-Results, and so won't be available to downstream hops), but > if we can get them, that would be very helpful. > > They could be added to A-R, in theory, but they're not really user-consumable which is why they were originally omitted. > The above will aid in classification and tracking down problems with > authentication. > > In addition, we probably want to record the # of hops (i.e. i=2) > That could be added as a message-level property. > The proposal above is a good start, but I don't think it handles the > multi-DKIM signature case well. Do you have thoughts on how you'd record > and propagate information on multiple signatures in the report? > Doesn't the XML schema for DMARC reports permit multiple signatures to be reported? -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
