SM wrote: > At 16:40 24-03-2009, J.D. Falk wrote: >> Pointing to an RFC rarely mitigates real-world concerns. > > I commented on why the problem occurs. I could argue that header > field should not be present in a RFC 5322 message at the signing > stage. RFC 4871 lists some header fields that should be signed. It > also contains a list of header fields that should not be signed. The > Return-Path header field is listed in there. > > If you believe this is a real-world concern that should be addressed, > you could specify that the Return-Path header field must not be > included in the signature.
I think this is the sort of "errata" material is worth the cause. From my experience, Return-Path should not be included in the signature. But then again, we started as a UUCP/UUCICO system where "From " was part of the model and was replaced with Return-Path only for the router for failure to delivery purposes. But the router does not resend it back out. For us, its "meta" data. But over the years, you can see the evolution of more and more systems adding it and keeping it there all the way to the MUA to see. So in my book, due to the history behind it, it is probably better to have a MUST NOT for this. SHOULD NOT is probably not strong enough for a mail integrity application. Signing return-path might cause issues as Mark Martinec highlighted with non DKIM-aware software But there are others in the SHOULD NOT list, for example, BCC, that really should be in a MUST NOT list simply because it is not expected to be there otherwise we are violating User Expectation for privacy. Legally speaking, in the USA, this would be US EPCA protected item. BCC definitely should never be signed and it should not be in the headers after the mail is submitted for processing. The distribution list should be expanded and the 8222 headers prepared properly for the non-blind and blind distribution. Definitely a process that should be done any DKIM SIGNING design consideration. -- Sincerely Hector Santos http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
