http://pear.php.net/bugs/search.php?cmd=display&package_name%5B0%5D=Mail_mimeDecode Search Results en-us pear-webmaster@lists.php.net pear-webmaster@lists.php.net hourly 1 2000-01-01T12:00+00:00 http://pear.php.net/gifs/pearsmall.gif http://pear.php.net/bugs http://pear.php.net/bugs/27009 Mail_mimeDecode Bug Reported by dlopez 2021-01-27T03:05:49+00:00 PHP: 7.3.19 OS: Debian Linux Package Version: SVN Description: ------------ I came across an email in the wild composed on Apple Mail (2.3608.120.23.2.4) whose Content-Type is multipart/signed and then within that is multipart/alternative with text/plain and multipart/mixed subparts (and the mixed part contains text/html and inline attachments). Headers with simplified boundaries (for easier reading) are at bottom. When I use mimeDecode->decode() the returned msg_body is the entire raw part within it; that is, there's no recursion on all the subparts. This appears to be reported in bug#21215 as well, but it appears unresolved. Looking at line 324 of mimeDecode.php, I see that multipart/signed is handled separately from the other multipart cases below it, such that subparts are not decoded. If I comment out that block it then gets caught by line 335 and thus handled like other multipart emails as expected. Since I'm unfamiliar with signed email standards, I'm unsure why the block starting at line 324 is needed at all. If sig_hdr and sig_body are special values to help signature verification against a raw msg_body, then maybe those should just be special return values added just for multipart/signed without affecting the rest of the expected multipart processing. In that case there would be an if(strtolower($content_type['value'])=='multipart/signed'){} around line 349 to add the sig_hdr and sig_body parameters. ----- Content-Type: multipart/signed; boundary="Apple-Mail=_111"; protocol="application/pkcs7-signature"; micalg=sha-256 ... X-Mailer: Apple Mail (2.3608.120.23.2.4) ... --Apple-Mail=_111 Content-Type: multipart/alternative; boundary="Apple-Mail=_D67DA570- BD52-4A36-BBAD-76FAC2A72FF5" --Apple-Mail=_222 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii ... --Apple-Mail=_222 Content-Type: multipart/mixed; boundary="Apple-Mail=_56032FB6-5676- 46B2-B9FB-34581A21F699" --Apple-Mail=_333 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii ... --Apple-Mail=_333 Content-Disposition: inline; filename=Example.pdf Content-Type: application/pdf; x-unix-mode=0644; name="Example.pdf" Content-Transfer-Encoding: base64 --Apple-Mail=_333 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii ... --Apple-Mail=_333-- --Apple-Mail=_222-- --Apple-Mail=_111 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64]]> Mail_mimeDecode Bug Reported by dlopez 2021-01-27T03:05:49+00:00 PHP: 7.3.19 OS: Debian Linux Package Version: SVN Description: ------------ I came across an email in the wild composed on Apple Mail (2.3608.120.23.2.4) whose Content-Type is multipart/signed and then within that is multipart/alternative with text/plain and multipart/mixed subparts (and the mixed part contains text/html and inline attachments). Headers with simplified boundaries (for easier reading) are at bottom. When I use mimeDecode->decode() the returned msg_body is the entire raw part within it; that is, there's no recursion on all the subparts. This appears to be reported in bug#21215 as well, but it appears unresolved. Looking at line 324 of mimeDecode.php, I see that multipart/signed is handled separately from the other multipart cases below it, such that subparts are not decoded. If I comment out that block it then gets caught by line 335 and thus handled like other multipart emails as expected. Since I'm unfamiliar with signed email standards, I'm unsure why the block starting at line 324 is needed at all. If sig_hdr and sig_body are special values to help signature verification against a raw msg_body, then maybe those should just be special return values added just for multipart/signed without affecting the rest of the expected multipart processing. In that case there would be an if(strtolower($content_type['value'])=='multipart/signed'){} around line 349 to add the sig_hdr and sig_body parameters. ----- Content-Type: multipart/signed; boundary="Apple-Mail=_111"; protocol="application/pkcs7-signature"; micalg=sha-256 ... X-Mailer: Apple Mail (2.3608.120.23.2.4) ... --Apple-Mail=_111 Content-Type: multipart/alternative; boundary="Apple-Mail=_D67DA570- BD52-4A36-BBAD-76FAC2A72FF5" --Apple-Mail=_222 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii ... --Apple-Mail=_222 Content-Type: multipart/mixed; boundary="Apple-Mail=_56032FB6-5676- 46B2-B9FB-34581A21F699" --Apple-Mail=_333 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii ... --Apple-Mail=_333 Content-Disposition: inline; filename=Example.pdf Content-Type: application/pdf; x-unix-mode=0644; name="Example.pdf" Content-Transfer-Encoding: base64 --Apple-Mail=_333 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii ... --Apple-Mail=_333-- --Apple-Mail=_222-- --Apple-Mail=_111 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64]]> 2021-01-27T03:05:49+00:00 pear &#x61;&#116; dlopez &#x64;&#111;&#x74; com Mail_mimeDecode Bug http://pear.php.net/bugs/21215 Mail_mimeDecode Bug Reported by sgironella 2017-05-31T13:11:31+00:00 PHP: 5.6.30 OS: FreeBSD 11 Package Version: 1.5.6 Description: ------------ On "multipart/signed" messages, "_decode()" method doesn't return a parts list but an associative array ("msg_body", "sig_hdr", "sig_body"); this lead "getMimeNumbers()" method to an infinite loop as it expects to iterate over a parts list and it doesn't manage those keys. See the case "case 'multipart/signed': // PGP" at line 324 Actual result: -------------- [31-May-2017 12:41:33 Europe/Rome] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 72 bytes) in /webroot/vendor/pear-pear.php.net/Mail_mimeDecode/Mail/mimeDecode.php on line 425 [31-May-2017 12:41:33 Europe/Rome] PHP Stack trace: [31-May-2017 12:41:33 Europe/Rome] PHP 1. {main}() /webroot/index.php:0 [31-May-2017 12:41:33 Europe/Rome] PHP 2. include_once() /webroot/index.php:291 [31-May-2017 12:41:33 Europe/Rome] PHP 3. rcube_message->__construct() /webroot/program/steps/mail/show.inc:49 [31-May-2017 12:41:33 Europe/Rome] PHP 4. rcube_dbmail->get_message() /webroot/program/lib/Roundcube/rcube_message.php:94 [31-May-2017 12:41:33 Europe/Rome] PHP 5. rcube_dbmail->retrieve_message() /webroot/program/lib/Roundcube/rcube_dbmail.php:1100 [31-May-2017 12:41:33 Europe/Rome] PHP 6. rcube_dbmail->decode_raw_message() /webroot/program/lib/Roundcube/rcube_dbmail.php:4316 [31-May-2017 12:41:33 Europe/Rome] PHP 7. Mail_mimeDecode->getMimeNumbers() /webroot/program/lib/Roundcube/rcube_dbmail.php:5425 [31-May-2017 12:41:33 Europe/Rome] PHP 8. Mail_mimeDecode->getMimeNumbers() /webroot/vendor/pear-pear.php.net/Mail_mimeDecode/Mail/mimeDecode.php:415]]> Mail_mimeDecode Bug Reported by sgironella 2017-05-31T13:11:31+00:00 PHP: 5.6.30 OS: FreeBSD 11 Package Version: 1.5.6 Description: ------------ On "multipart/signed" messages, "_decode()" method doesn't return a parts list but an associative array ("msg_body", "sig_hdr", "sig_body"); this lead "getMimeNumbers()" method to an infinite loop as it expects to iterate over a parts list and it doesn't manage those keys. See the case "case 'multipart/signed': // PGP" at line 324 Actual result: -------------- [31-May-2017 12:41:33 Europe/Rome] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 72 bytes) in /webroot/vendor/pear-pear.php.net/Mail_mimeDecode/Mail/mimeDecode.php on line 425 [31-May-2017 12:41:33 Europe/Rome] PHP Stack trace: [31-May-2017 12:41:33 Europe/Rome] PHP 1. {main}() /webroot/index.php:0 [31-May-2017 12:41:33 Europe/Rome] PHP 2. include_once() /webroot/index.php:291 [31-May-2017 12:41:33 Europe/Rome] PHP 3. rcube_message->__construct() /webroot/program/steps/mail/show.inc:49 [31-May-2017 12:41:33 Europe/Rome] PHP 4. rcube_dbmail->get_message() /webroot/program/lib/Roundcube/rcube_message.php:94 [31-May-2017 12:41:33 Europe/Rome] PHP 5. rcube_dbmail->retrieve_message() /webroot/program/lib/Roundcube/rcube_dbmail.php:1100 [31-May-2017 12:41:33 Europe/Rome] PHP 6. rcube_dbmail->decode_raw_message() /webroot/program/lib/Roundcube/rcube_dbmail.php:4316 [31-May-2017 12:41:33 Europe/Rome] PHP 7. Mail_mimeDecode->getMimeNumbers() /webroot/program/lib/Roundcube/rcube_dbmail.php:5425 [31-May-2017 12:41:33 Europe/Rome] PHP 8. Mail_mimeDecode->getMimeNumbers() /webroot/vendor/pear-pear.php.net/Mail_mimeDecode/Mail/mimeDecode.php:415]]> 2017-06-01T07:06:48+00:00 sgironella &#x61;&#116; schema31 &#x64;&#111;&#x74; it Mail_mimeDecode Bug http://pear.php.net/bugs/21210 Mail_mimeDecode Feature/Change Request Reported by glen 2017-05-11T18:55:33+00:00 PHP: Irrelevant OS: Package Version: 1.5.6 Description: ------------ please convert this repo to git (github) and setup packagist integration here's problem i'm suffering: https://github.com/eventum/eventum/pull/256#issuecomment- 300879398 and i think it's just easier to fix if the package is available in packagist]]> Mail_mimeDecode Feature/Change Request Reported by glen 2017-05-11T18:55:33+00:00 PHP: Irrelevant OS: Package Version: 1.5.6 Description: ------------ please convert this repo to git (github) and setup packagist integration here's problem i'm suffering: https://github.com/eventum/eventum/pull/256#issuecomment- 300879398 and i think it's just easier to fix if the package is available in packagist]]> 2017-05-12T03:25:26+00:00 glen &#x61;&#116; pld-linux &#x64;&#111;&#x74; org Mail_mimeDecode Feature/Change Request http://pear.php.net/bugs/20997 Mail_mimeDecode Bug Reported by postletariat 2015-12-13T17:56:35+00:00 PHP: 5.5.30 OS: Linux Package Version: 1.5.5 Description: ------------ It seems as though when I attempt to decode mail from GMail, the from header is not becoming properly parsed. Test script: --------------- $decoder = new Mail_mimeDecode(stream_get_contents(STDIN)); $structure = $decoder->decode($params); echo json_encode($structure); Expected result: ---------------- I would expect something such as the following (excerpt, presented in JSON): {"headers":{"from": "emailaddress@gmail.com sun dec 13 10:46:49 2015"}} Actual result: -------------- Instead, I get something like the following (excerpt, presented in JSON): {"headers":{"from emailaddress@gmail.com sun dec 13 10":"46:49 2015"}}]]> Mail_mimeDecode Bug Reported by postletariat 2015-12-13T17:56:35+00:00 PHP: 5.5.30 OS: Linux Package Version: 1.5.5 Description: ------------ It seems as though when I attempt to decode mail from GMail, the from header is not becoming properly parsed. Test script: --------------- $decoder = new Mail_mimeDecode(stream_get_contents(STDIN)); $structure = $decoder->decode($params); echo json_encode($structure); Expected result: ---------------- I would expect something such as the following (excerpt, presented in JSON): {"headers":{"from": "emailaddress@gmail.com sun dec 13 10:46:49 2015"}} Actual result: -------------- Instead, I get something like the following (excerpt, presented in JSON): {"headers":{"from emailaddress@gmail.com sun dec 13 10":"46:49 2015"}}]]> 2015-12-21T07:11:14+00:00 laudedfavor &#x61;&#116; gmail &#x64;&#111;&#x74; com Mail_mimeDecode Bug http://pear.php.net/bugs/19961 Mail_mimeDecode Feature/Change Request Reported by randalla 2013-05-29T00:33:18+00:00 PHP: 5.3.23 OS: Linux Package Version: 1.5.5 Description: ------------ This is related to #9616. I'm receiving e-mails from iCloud that contain long names, but they are in the format of: [file]name*1*=utf-8''%20%20%20%20; [file]name*2*=%20%20%20%20%20 Here's some relevant information: # print_r( $part->ctype_parameters ); Array ( [name*1*] => utf- 8%48%6F%75%73%65%20%49%6E%73%75%72%61 [name*2*] => %6E%63%65%2E%70%64%66 ) # print_r( $part->headers ); Array ( [content-id] => <35b9249a-1162-4ba3-ab6f- 1518661e1b61@icloud.com> [content-type] => application/pdf; name*1*=utf- 8''%48%6F%75%73%65%20%49%6E%73%75%72%61; name*2*=%6E%63%65%2E%70%64%66 [content-transfer-encoding] => base64 [content-disposition] => attachment; filename*1*=utf- 8''%48%6F%75%73%65%20%49%6E%73%75%72%61; filename*2*=%6E%63%65%2E%70%64%66 ) Not sure if it's necessary, but here's some sanitized headers: From somebody@me.com Sun May 26 08:41:34 2013 Return-Path: <nobody@me.com> X-Original-To: myaddress@here.com Delivered-To: myaddress@here.com Received: Received: X-Server-Uuid: Received: X-Proofpoint-Virus-Version: X-Proofpoint-Spam-Details: MIME-Version: 1.0 Received: To: myaddress@here.com From: "Somebody" <somebody@me.com> Subject: Their Subject Line #12345 Date: Sun, 26 May 2013 15:39:54 +0000 (GMT) X-Mailer: iCloud Mail (1Q) X-Originating-IP: Message-ID: <9978818f-2c21-4e00-8f0c- 094d6ec1c0e8@me.com> X-TMWD-Spam-Summary: X-MMS-Spam-Filter-ID: X-WSS-ID: Content-Type: multipart/alternative; boundary="Boundary_(ID_ZcR2Vul4mq27B0g0wvFLMg)" [snipped] --Boundary_(ID_AcW2oBwQSJ6m0TXXzf7xzw) Content-ID: <35b9249a-1162-4ba3-ab6f- 1518661e1b61@icloud.com> Content-Type: application/pdf; name*1*=utf- 8''%48%6F%75%73%65%20%49%6E%73%75%72%61; name*2*=%6E%63%65%2E%70%64%66 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*1*=utf- 8''%48%6F%75%73%65%20%49%6E%73%75%72%61; filename*2*=%6E%63%65%2E%70%64%66 I am running on Gentoo Linux. The PEAR versions are as follows: dev-php/PEAR-Mail 1.2.0 dev-php/PEAR-Mail_Mime 1.8.7 dev-php/PEAR-Mail_mimeDecode 1.5.5 Test script: --------------- <?php /* simple script to work around the issue */ $mime = "attachment; filename*1*=utf-8''%48%6F%75%73%65%20%49%6E%73%75%72%61; filename*2*=%6E%63%65%2E%70%64%66"; var_dump( preg_match_all( '/(?<=filename\*\d\*=)[^;]+(?=;|$)/', $mime, $matches ), urldecode( implode( '', $matches[0] ) ) ); ?> Expected result: ---------------- # print_r( $part->ctype_parameters ); Array ( [name] => House Insurance.pdf ) # print_r( $part->headers ); Array ( [content-id] => <35b9249a-1162-4ba3-ab6f- 1518661e1b61@icloud.com> [content-type] => application/pdf; name=House Insurance.pdf [content-transfer-encoding] => base64 [content-disposition] => attachment; filename=House Insurance.pdf ) Actual result: -------------- # print_r( $part->ctype_parameters ); Array ( [name*1*] => utf- 8%48%6F%75%73%65%20%49%6E%73%75%72%61 [name*2*] => %6E%63%65%2E%70%64%66 ) # print_r( $part->headers ); Array ( [content-id] => <35b9249a-1162-4ba3-ab6f- 1518661e1b61@icloud.com> [content-type] => application/pdf; name*1*=utf- 8''%48%6F%75%73%65%20%49%6E%73%75%72%61; name*2*=%6E%63%65%2E%70%64%66 [content-transfer-encoding] => base64 [content-disposition] => attachment; filename*1*=utf- 8''%48%6F%75%73%65%20%49%6E%73%75%72%61; filename*2*=%6E%63%65%2E%70%64%66 )]]> Mail_mimeDecode Feature/Change Request Reported by randalla 2013-05-29T00:33:18+00:00 PHP: 5.3.23 OS: Linux Package Version: 1.5.5 Description: ------------ This is related to #9616. I'm receiving e-mails from iCloud that contain long names, but they are in the format of: [file]name*1*=utf-8''%20%20%20%20; [file]name*2*=%20%20%20%20%20 Here's some relevant information: # print_r( $part->ctype_parameters ); Array ( [name*1*] => utf- 8%48%6F%75%73%65%20%49%6E%73%75%72%61 [name*2*] => %6E%63%65%2E%70%64%66 ) # print_r( $part->headers ); Array ( [content-id] => <35b9249a-1162-4ba3-ab6f- 1518661e1b61@icloud.com> [content-type] => application/pdf; name*1*=utf- 8''%48%6F%75%73%65%20%49%6E%73%75%72%61; name*2*=%6E%63%65%2E%70%64%66 [content-transfer-encoding] => base64 [content-disposition] => attachment; filename*1*=utf- 8''%48%6F%75%73%65%20%49%6E%73%75%72%61; filename*2*=%6E%63%65%2E%70%64%66 ) Not sure if it's necessary, but here's some sanitized headers: From somebody@me.com Sun May 26 08:41:34 2013 Return-Path: <nobody@me.com> X-Original-To: myaddress@here.com Delivered-To: myaddress@here.com Received: Received: X-Server-Uuid: Received: X-Proofpoint-Virus-Version: X-Proofpoint-Spam-Details: MIME-Version: 1.0 Received: To: myaddress@here.com From: "Somebody" <somebody@me.com> Subject: Their Subject Line #12345 Date: Sun, 26 May 2013 15:39:54 +0000 (GMT) X-Mailer: iCloud Mail (1Q) X-Originating-IP: Message-ID: <9978818f-2c21-4e00-8f0c- 094d6ec1c0e8@me.com> X-TMWD-Spam-Summary: X-MMS-Spam-Filter-ID: X-WSS-ID: Content-Type: multipart/alternative; boundary="Boundary_(ID_ZcR2Vul4mq27B0g0wvFLMg)" [snipped] --Boundary_(ID_AcW2oBwQSJ6m0TXXzf7xzw) Content-ID: <35b9249a-1162-4ba3-ab6f- 1518661e1b61@icloud.com> Content-Type: application/pdf; name*1*=utf- 8''%48%6F%75%73%65%20%49%6E%73%75%72%61; name*2*=%6E%63%65%2E%70%64%66 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*1*=utf- 8''%48%6F%75%73%65%20%49%6E%73%75%72%61; filename*2*=%6E%63%65%2E%70%64%66 I am running on Gentoo Linux. The PEAR versions are as follows: dev-php/PEAR-Mail 1.2.0 dev-php/PEAR-Mail_Mime 1.8.7 dev-php/PEAR-Mail_mimeDecode 1.5.5 Test script: --------------- <?php /* simple script to work around the issue */ $mime = "attachment; filename*1*=utf-8''%48%6F%75%73%65%20%49%6E%73%75%72%61; filename*2*=%6E%63%65%2E%70%64%66"; var_dump( preg_match_all( '/(?<=filename\*\d\*=)[^;]+(?=;|$)/', $mime, $matches ), urldecode( implode( '', $matches[0] ) ) ); ?> Expected result: ---------------- # print_r( $part->ctype_parameters ); Array ( [name] => House Insurance.pdf ) # print_r( $part->headers ); Array ( [content-id] => <35b9249a-1162-4ba3-ab6f- 1518661e1b61@icloud.com> [content-type] => application/pdf; name=House Insurance.pdf [content-transfer-encoding] => base64 [content-disposition] => attachment; filename=House Insurance.pdf ) Actual result: -------------- # print_r( $part->ctype_parameters ); Array ( [name*1*] => utf- 8%48%6F%75%73%65%20%49%6E%73%75%72%61 [name*2*] => %6E%63%65%2E%70%64%66 ) # print_r( $part->headers ); Array ( [content-id] => <35b9249a-1162-4ba3-ab6f- 1518661e1b61@icloud.com> [content-type] => application/pdf; name*1*=utf- 8''%48%6F%75%73%65%20%49%6E%73%75%72%61; name*2*=%6E%63%65%2E%70%64%66 [content-transfer-encoding] => base64 [content-disposition] => attachment; filename*1*=utf- 8''%48%6F%75%73%65%20%49%6E%73%75%72%61; filename*2*=%6E%63%65%2E%70%64%66 )]]> 2013-07-04T18:39:38+00:00 randalla &#x61;&#116; gmail &#x64;&#111;&#x74; com Mail_mimeDecode Feature/Change Request