> I'd also support the idea that an SPF report can synthesize the > text/rfc822-headers for a message whose content has not actually arrived. > All you legally need is a From: field as I recall, and that can be > generated based on the rejected RFC5321.MailFrom.
I think that would cause far more confusion than enlightenment. The kind of analysis I do on ARFs looks for specific quirks of the headers that my software adds. If it doesn't find them, it'll discard the whole report as bogus. Better to send no headers than fake ones. Since it's fine for any other multipart/report to omit the copy of the message, seems to me a lot tidier just to fix 5965 to be consistent. Based on my prior experience with errata, it's OK to use the corrected version of the doc as a base for future work without recycling. In RFC 5518 we made a fairly bad mistake, saying that you use the i= rather than d= in a DKIM result. We fixed that with an erratum, seems to be OK. R's, John _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
