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