Description: ------------ RFC2047 says: + An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'. The Mail_mime breaks this. Mail_mime should support RFC2231. Test script: --------------- require_once('Mail/mime.php'); $mime=new Mail_mime(); $mime->addAttachment('emotion.gif','image/gif','ÎŠç.gif',true,'base64','attachment','UTF-8'); $message=$mime->getMessage("\r\n", array( 'head_encoding'=>'base64', 'html_encoding'=>'8bit', 'html_charset'=>'UTF-8', 'html_charset'=>'ISO-2022-JP', 'text_charset'=>'UTF-8', 'text_encoding'=>'8bit' ), array()); var_dump($message); Actual result: -------------- string(811) "MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_737a1f4e13a6fc271bfdd7b4f6bffaf1" --=_737a1f4e13a6fc271bfdd7b4f6bffaf1 Content-Transfer-Encoding: base64 Content-Type: image/gif; name="=?UTF-8?B?56yR6aGULmdpZg==?="; charset="UTF-8" Content-Disposition: attachment; filename="=?UTF-8?B?56yR6aGULmdpZg==?=" R0lGODlhFAAUAMQAACYKAsbGxpZ6DOrPEcq2at7SMr+qTu/v7vPwWdC9HlI9DbSYDPzwNmhUEsSr GfvmHvr6+uDYuv79cfryR8S8nbqeLtfX1tXDMf75N7mbHMKmMv77WvjaEnlgDqqKAgAAACH5BAEA AB8ALAAAAAAUABQAAAW84CeOZGmeaCoamedlhioSy4VIEnItRFo5iM2EwZhsEI7KyZCQTC4XInQi ScRKCyejoSByi5JFyVDYYDAKxTl93hSuogxicu406nfMBJEhZc8YDA8PHAMDHIgbYiN/goiPiIcT i3EIDAMekIgeAw8TfSNkDBwCHQmICR0CHAxvJBQOG4MdALUAHYMbDhRjCbIPDgICDrlWJxoJCIGD DBgICRopBg4FRkIFDnAoFAYaDg4aBrwyIgHmAeTpIyEAOw== --=_737a1f4e13a6fc271bfdd7b4f6bffaf1-- "

I must honoustly admit I'm not 100% knowledgable about UTF8/ foreign attachments. Could you send a test email with UTF8 encoded name to php@cipri.net, that contains the CORRECT headers?

I'm sorry I forgot pasting the expected result. ---------------------------- string(811) "MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_98547452517bcf705e9ffc30faa8e84f" --=_98547452517bcf705e9ffc30faa8e84f Content-Transfer-Encoding: base64 Content-Type: image/gif; filename="UTF-8'en'%E7%AC%91%E9%A1%94.gif" Content-Disposition: attachment; filename="UTF-8'en'%E7%AC%91%E9%A1%94.gif" R0lGODlhFAAUAMQAACYKAsbGxpZ6DOrPEcq2at7SMr+qTu/v7vPwWdC9HlI9DbSYDPzwNmhUEsSr GfvmHvr6+uDYuv79cfryR8S8nbqeLtfX1tXDMf75N7mbHMKmMv77WvjaEnlgDqqKAgAAACH5BAEA AB8ALAAAAAAUABQAAAW84CeOZGmeaCoamedlhioSy4VIEnItRFo5iM2EwZhsEI7KyZCQTC4XInQi ScRKCyejoSByi5JFyVDYYDAKxTl93hSuogxicu406nfMBJEhZc8YDA8PHAMDHIgbYiN/goiPiIcT i3EIDAMekIgeAw8TfSNkDBwCHQmICR0CHAxvJBQOG4MdALUAHYMbDhRjCbIPDgICDrlWJxoJCIGD DBgICRopBg4FRkIFDnAoFAYaDg4aBrwyIgHmAeTpIyEAOw== --=_98547452517bcf705e9ffc30faa8e84f-- "

Please see also the patch I submitted before. http://pear.php.net/bugs/bug.php?id=3513

Okay, I see the problem, and I'll fix it before 1.4.0. I can see the problem would also happen with UTF-8 encoded filenames, so I should be able to test with that. I've read your patch, but as I said in the previous bug, I'm hesitant about adding a depedancy on mbstrings. As such, I'd rather make the charset and language setable, and encode the string according to that.

I asked someone else for example mails too, and I got the following headers in that email: -- Content-Type: application/zip; name="=?ISO-2022-JP?B?GyRCRnxLXDhsJE4lRiU5JUgbKEIuemlw?=" Content-Transfer-Encoding: base64 X-Attachment-Id: f_f0zb13gj Content-Disposition: attachment; filename="=?ISO-2022-JP?B?GyRCRnxLXDhsJE4lRiU5JUgbKEIuemlw?=" -- As such, I'm not exactly sure what the advantage is of RFC2231 support, except for the language part. Still, I'll see if I can create a way to allow people to set RFC2231 compatible headers.

This bug has been fixed in CVS. 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. I've added a $language and $charset variable to the addAttachment() call, that will encode the filename when needed.