http://pear.php.net/bugs/12429 [Open] Attachments with long files names are causing difficulty en-us pear-webmaster@lists.php.net pear-webmaster@lists.php.net hourly 1 2000-01-01T12:00+00:00 http://pear.php.net/bugs/12429 Mail_Mime Bug Reported by erdqwjw 2007-11-12T13:33:58-00:00 PHP: 5.2.2 OS: Apple OSX 10.4.10 Package Version: 1.5.2 Description: ------------ Hi,    Attachments with long files names are causing difficulty with a wide range of receiving MUAs.   // $fname = $caseDir . "/" . $shortfname; // $dotpos = strrpos($realname, "."); // $ext = strtolower(substr($realname,$dotpos+1));   // $mime->addAttachment($fname,$mime_types[$ext],$realname);   It seems that because I am using base64 encoding mail_mime is deciding to limit the whole of the mime part's data to 64 chars per line, incuding the mime part's header. Header attributes are also separated by lines.   This causes problems with some MUAs which loose track of the attachment's file extension, and (even though it has a mime- type) decide they don't know what to do with it and default to text.   Here is a Mail_Mime 1.5.2 excerpt:   --=_ca502c3561ab4710bb5472d957a3e454 Content-Transfer-Encoding: base64 Content-Type: application/pdf; name*0="UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 11 2007." name*1="pdf"; Content-Disposition: attachment; filename*0="UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 11 2" filename*1="007.pdf";   JVBERi0xLjIKNCAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8     The Apple mail client does something similar:   --Apple-Mail-1--340428939 Content-Transfer-Encoding: base64 Content-Type: application/pdf; x-unix-mode=0644; name=UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 11 2007.pdf Content-Disposition: inline; filename*0="UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 11 2007."; filename*1=pdf   JVBERi0xLjIKNCAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8   However, Eudora on Windows XP does this:   --=====================_-1519325078==_ Content-Type: application/octet-stream; name="UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 11 2007.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 11 2007.pdf"   JVBERi0xLjIKNCAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8   In this case the mime part's header lines are not broken at 64 chars. All the header attributes appear on one line. The filename appears unbroken, and there don't appear to be any problems with the receiving MUAs.   Examples in RFC2046 - whilst not dealing with long filenames - seem to adopt this way of doing things. Whilst RFC2047 talks about a 75 char limit on 'encoded-words' in headers I am not sure these are encoded words.   Not sure if this is a bug, but it seems MUAs have difficulty dealing with multiline headers and/or split attribute values.   Are their any plans to address this issue? ------------------------------------------------   Bill Worthington   Dr. W J Worthington STRI - the Science and Technology Research Institute University of Hertfordshire PO Box 109, College Lane  Hatfield Hertfordshire AL10 9AB T: +44 (0)1707 286077 F: +44 (0)1707 286079 E: mailto:W.J.Worthington@herts.ac.uk W: www.i10.org.uk/bill_worthington]]> Mail_Mime Bug Reported by erdqwjw 2007-11-12T13:33:58-00:00 PHP: 5.2.2 OS: Apple OSX 10.4.10 Package Version: 1.5.2 Description: ------------ Hi,    Attachments with long files names are causing difficulty with a wide range of receiving MUAs.   // $fname = $caseDir . "/" . $shortfname; // $dotpos = strrpos($realname, "."); // $ext = strtolower(substr($realname,$dotpos+1));   // $mime->addAttachment($fname,$mime_types[$ext],$realname);   It seems that because I am using base64 encoding mail_mime is deciding to limit the whole of the mime part's data to 64 chars per line, incuding the mime part's header. Header attributes are also separated by lines.   This causes problems with some MUAs which loose track of the attachment's file extension, and (even though it has a mime- type) decide they don't know what to do with it and default to text.   Here is a Mail_Mime 1.5.2 excerpt:   --=_ca502c3561ab4710bb5472d957a3e454 Content-Transfer-Encoding: base64 Content-Type: application/pdf; name*0="UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 11 2007." name*1="pdf"; Content-Disposition: attachment; filename*0="UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 11 2" filename*1="007.pdf";   JVBERi0xLjIKNCAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8     The Apple mail client does something similar:   --Apple-Mail-1--340428939 Content-Transfer-Encoding: base64 Content-Type: application/pdf; x-unix-mode=0644; name=UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 11 2007.pdf Content-Disposition: inline; filename*0="UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 11 2007."; filename*1=pdf   JVBERi0xLjIKNCAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8   However, Eudora on Windows XP does this:   --=====================_-1519325078==_ Content-Type: application/octet-stream; name="UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 11 2007.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 11 2007.pdf"   JVBERi0xLjIKNCAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8   In this case the mime part's header lines are not broken at 64 chars. All the header attributes appear on one line. The filename appears unbroken, and there don't appear to be any problems with the receiving MUAs.   Examples in RFC2046 - whilst not dealing with long filenames - seem to adopt this way of doing things. Whilst RFC2047 talks about a 75 char limit on 'encoded-words' in headers I am not sure these are encoded words.   Not sure if this is a bug, but it seems MUAs have difficulty dealing with multiline headers and/or split attribute values.   Are their any plans to address this issue? ------------------------------------------------   Bill Worthington   Dr. W J Worthington STRI - the Science and Technology Research Institute University of Hertfordshire PO Box 109, College Lane  Hatfield Hertfordshire AL10 9AB T: +44 (0)1707 286077 F: +44 (0)1707 286079 E: mailto:W.J.Worthington@herts.ac.uk W: www.i10.org.uk/bill_worthington]]> 2007-11-12T13:33:58-00:00 http://pear.php.net/bugs/12429#1195469099 Thanks for the patch. I will apply it and see how I get on. Bill Worthington]]> Thanks for the patch. I will apply it and see how I get on. Bill Worthington]]> 2007-11-19T10:44:59-00:00 http://pear.php.net/bugs/12429#1195413967 > BTW: The initial patch from Request #12411 does > not work for you. I have rewritten this patch. Now this should also work for you. Regards, Carsten]]> > BTW: The initial patch from Request #12411 does > not work for you. I have rewritten this patch. Now this should also work for you. Regards, Carsten]]> 2007-11-18T19:26:07-00:00 http://pear.php.net/bugs/12429#1195287055 > Attachments with long files names are causing > difficulty with a wide range of receiving MUAs. For example Outlook and Outlook Express. > Not sure if this is a bug, but it seems MUAs have > difficulty dealing with multiline headers and/or > split attribute values. IMHO it's more a feature request and it's similar to Request #12411: Disabling the extensions from RFC 2231. BTW: The initial patch from Request #12411 does not work for you. Regards, Carsten]]> > Attachments with long files names are causing > difficulty with a wide range of receiving MUAs. For example Outlook and Outlook Express. > Not sure if this is a bug, but it seems MUAs have > difficulty dealing with multiline headers and/or > split attribute values. IMHO it's more a feature request and it's similar to Request #12411: Disabling the extensions from RFC 2231. BTW: The initial patch from Request #12411 does not work for you. Regards, Carsten]]> 2007-11-17T08:10:55-00:00