> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Scott > Kitterman > Sent: Monday, February 13, 2012 11:27 AM > To: [email protected] > Subject: Re: [marf] Message bodies in ARF reports > > > > ARF is a version of multipart/report as defined in RFC 3462. In > > > that document, the message/rfc822 or message/headers is optional. > > > In RFC 5965, we made it mandatory in section 2.d. We did that > > > because the usage scenario we were thinking of was spam button > > > reports where you always have a message in hand, not for any deeper > > > reason. > > > > > > You are of course correct that SPF failures sometimes don't accept > > > the message. I'd be willing to file an erratum that 2.d. should > > > have said that the report MUST include the message if the reporting > > > entity has received it. > > > > I'd support that. > > That's great. Is MUST include if you have ... or SHOULD include > (unless you do not have ...) a better construction? I thought the > trend in IETF documents was away from MUSTs if they weren't essential.
I'd prefer "MUST ... unless" for this one. I'm not sure I can explain why though. This one's for Barry: Can a Standards Track document contradict another one on the basis of an accepted erratum? Or should we do a quick update to RFC5965 (not a "bis", just a standards-track correction)? > > 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. > > If by 'synthesize' you mean 'assume the RFC5321.MailFrom and the > FRC5322.From are the same', then yes, it could do that. That's not the > same as saying I think it's a good idea. In cases where this heuristic > is wrong (I've seen numbers between 5% and 20% of mail), it will > probably be deeply confusing to receivers of such reports. I don't > think we should. Yeah, I realize it's not guaranteed to be right. It's a question of what fits within the rules. We could certainly say in the SPF reporting document that the synthesized third part is based on the envelope only and thus could be a misrepresentation of what was really in the (rejected) message. Of course if the message failed SPF but was still delivered, the content is available anyway. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
