------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=638
Derrick <derrick.rice@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |derrick.rice@???
--- Comment #1 from Derrick <derrick.rice@???> 2008-10-22 04:02:41 ---
This is still an open issue, and I want to comment on some of the discussion
found in the email thread mentioned previously.
The thread seems to touch on a separate, but related issue: encoding and
decoding line endings. Specifically, encoding a LF and decoding a CR LF is
ambiguous. If we assume that a LF in the source is meant to be an end of line,
then it seems appropriate to encode it as CR LF, the end of line notation for
email. The reverse is true: an encoded CR LF is likely meant to be an end of
line, so it seems appropriate to decode it as a LF in unix.
This introduces problems when:
a) A LF in the source is /not/ meant to be an end of line, and it should be
written into the encoded string as a LF only.
b) a BR LF in an encoded string is /not/ meant to be an end of line, and it
should be decoded as BR LF, not as a LF.
Regardless, my point is that this issue is separate and unrelated to handling
line breaks BETWEEN encoded words. These line breaks are never encoded or
decoded, and any decision made regarding the above should not effect what is
done with the line breaks between words.
According to rfc2047, it seems the following is appropriate:
a) when encoding, 'LF space' should be placed between encoded words. These
will be translated to 'BR LF space' when transmitted, resulting in correctly
formated rfc2047 headers.
b) when decoding, 'LF space' between encoded words should be removed. These
are the result of 'BR LF space' between encoded words in a transmitted email
message.
What concerns are there that observing both (a) and (b) will have undesired
affects? I'd like to patch rfc2047.c to correctly handle whitespace between
encoded words.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
