There's nothing technically wrong with changing the quoting prefix, however I'd venture a guess that a lot more software expect ">Return-Path:" then the number of broken software written by Microsoft (as hard as this may be to believe).
In short: more stuff is likely to break than would get fixed.
Is quoting extra "Return-paths" with ">" defined somewhere? (e.g. rfc?) I'd thought you decided to quote extra "return-path"s to make it unambiguous which one was the real return-path, to prevent looping, etc., as a boundary case.
I don't think it's really defined anywhere. It's one of those things that originated in the dark ages of ancient sendmail and mail.local
Quoting the extra headers seems reasonable; using '>' if it's outside of RFC spec doesn't. If there's precedence for using '>' in quoting headers (as opposed to "X-") and it's RFC defined, then I have something to go back to my client with and have them argue with GroupWise. If '>' escaping in headers isn't RFC-compliant, not only do we look bad, but Courier isn't compatible with Novell Groupwise and it should be fixed.
From RFC 2822:
A message consists of header fields (collectively called "the header of the message") followed, optionally, by a body. The header is a sequence of lines of characters with special syntax as defined in this standard. The body is simply a sequence of characters that follows the header and is separated from the header by an empty line (i.e., a line with nothing preceding the CRLF).
That's it. It's a simple as that. Headers, followed by a blank line, than the message body. Furthermore:
2.2. Header Fields
Header fields are lines composed of a field name, followed by a colon
(":"), followed by a field body, and terminated by CRLF. A field
name MUST be composed of printable US-ASCII characters (i.e.,
characters that have values between 33 and 126, inclusive), except
colon. A field body may be composed of any US-ASCII characters,
except for CR and LF. However, a field body may contain CRLF when
used in header "folding" and "unfolding" as described in section
2.2.3. All field bodies MUST conform to the syntax described in
sections 3 and 4 of this standard.So the ">" character is a perfectly valid character in the field name.
The only character not allowed in the header field name is a colon.
End of the story.
pgp00000.pgp
Description: PGP signature
