Description: ------------ hi, i was recently forced to use PEAR's Mail_Mime and found this RFC2047 header encoding conflict in Mail/mime.php Mail_Mime::_encodeHeaders(). when the method actually encodes mail headers, it causes spaces to be ignored by the mail readers. Mail_Mime::_encodeHeaders() as of 1.3.0 and earlier confuses meaning of word (as in terms of regular expressions) and encoded-word (as described in RFC2045 and RFC822). it virtually splits the header value along whitespace and makes encoded-words from those parts, which contain non-ASCII characters which is wrong: it causes linear-white-space between encoded-words to be ignored, since it is considered a separator, not the value, causing mail clients stick the encoded words (hence the absent dash :) together. in my interpretation of these RFC's whole value of header can/should be encoded, and split into two or more encoded-words only if the length of the encoded-word would exceed 75 characters (as requested by RFC). spaces should be included in the encoded-words, represented by =20 sequence or '_' (underscore), when encoded as quoted-printable. somehow relevant (as well as confused :) to this matter is this bug report http://pear.php.net/bugs/bug.php?id=3578 this is relevant as well, http://pear.php.net/bugs/bug.php?id=30 minakov's _encodeHeaders() can be found in 1.3.0, but it does not solve anything. in order to demonstrate correct behaviour according to me, i attached a patch. hth jan winkler Reproduce code: --------------- Get the patch here http://www.pinerecords.com/prook/pear/mime.php.patch

Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PEAR. Duplicate of Bug #30