------- 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 <[EMAIL PROTECTED]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] --- Comment #1 from Derrick <[EMAIL PROTECTED]> 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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
