Description: ------------ The Mail_mimePart::encodeHeader() function does not apply differents encoding rules for Quoted Printed encoding, based on the type of the header. The function encode all the headers value with the function Mail_mimePart::encodeQP(), this will let illegals chars such as '@' or '"' and others to be mantained in the encoded-word of a 'Structured header', that is not RFC2047 compliant. The header returned by the function will also fail an RFC822 validation, such as the one of the Mail Package, preventing the email to be sent. Here is the RFC2047 part that list the permited chars in a 'Structured header': As a replacement for a 'word' entity within a 'phrase', for example, one that precedes an address in a From, To, or Cc header. The ABNF definition for 'phrase' from RFC 822 thus becomes: phrase = 1*( encoded-word / word ) In this case the set of characters that may be used in a "Q"-encoded 'encoded-word' is restricted to: <upper and lower case ASCII letters, decimal digits, "!", "*", "+", "-", "/", "=", and "_" (underscore, ASCII 95.)> Test script: --------------- <? require_once 'Mail/mimePart.php'; $head_name = 'From'; $head_value = 'test@nàme <user@domain.com>'; $encoded_header = Mail_mimePart::encodeHeader($head_name, $head_value); var_dump($encoded_header); ?> Expected result: ---------------- The script should return: string(51) "=?ISO-8859-1?Q?test=40n=C3=A0me?= <user@domain.com>" Actual result: -------------- The script return: string(49) "=?ISO-8859-1?Q?test@n=C3=A0me?= <user@domain.com>"

Added patch rfc2047_compliant_qp_encoding.

I've added a patch that encode all the forbidden chars according to RFC2047. This apply also to headers that doesn't strictly need it, such as the 'Subject' header, cause differenciating between type of headers would increase the complexity of the code without adding any plus. It's the first time I write a patch for Pear, sorry if I made any mistake.

Looks good to me (cursory review) Pier, thanks for the patch!

Alec, added the test to SVN for you.

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.