#40213 [Fbk->Opn]: easter_date() returns wrong timestamp if ...
ID: 40213 User updated by: oliver dot block at lycos dot de Reported By: oliver dot block at lycos dot de -Status: Feedback +Status: Open Bug Type: Calendar related Operating System: Linux PHP Version: 5.2.1RC3 New Comment: But it saves a lot of time and work. - I've feared that it may not convince you.:) Previous Comments: [2007-03-06 12:11:37] [EMAIL PROTECTED] Naaah, calling mktime() with call_user_function() is just a hack, not a solution. I've said we probably need to rewrite it from scratch and merge it into ext/date to use ext/date _internal_ functions directly, not through the user API. [2007-01-29 22:03:11] oliver dot block at lycos dot de I modified some of the testfiles from the former archives, because of wrong test results. It happens that easter date and DST shift occur on the same day. If so, date('Y-m-d H:i:s', easter_date($year)) will return a time portion of 01:00:00 and not 00:00:00 You find the archive here: http://www.block-online.eu/phptests/tests_easter_date.tar.gz [2007-01-25 21:04:02] oliver dot block at lycos dot de You will find the diff file here now: http://mitglied.lycos.de/oblock/php/easter.c.diff.gz [2007-01-25 20:20:22] [EMAIL PROTECTED] 404 not found.. [2007-01-25 20:16:28] oliver dot block at lycos dot de Let's start with the first function.:) You will find a diff file here: http://mitglied.lycos.de/oblock/easter.c.diff I also created more test files http://mitglied.lycos.de/oblock/easter_date_test.tar.gz Please check everthing and decide if you want to include it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/40213 -- Edit this bug report at http://bugs.php.net/?id=40213&edit=1
#40213 [Opn]: easter_date() returns wrong timestamp if ...
ID: 40213 User updated by: oliver dot block at lycos dot de Reported By: oliver dot block at lycos dot de Status: Open Bug Type: Calendar related Operating System: Linux PHP Version: 5.2.1RC3 New Comment: I modified some of the testfiles from the former archives, because of wrong test results. It happens that easter date and DST shift occur on the same day. If so, date('Y-m-d H:i:s', easter_date($year)) will return a time portion of 01:00:00 and not 00:00:00 You find the archive here: http://www.block-online.eu/phptests/tests_easter_date.tar.gz Previous Comments: [2007-01-25 21:04:02] oliver dot block at lycos dot de You will find the diff file here now: http://mitglied.lycos.de/oblock/php/easter.c.diff.gz [2007-01-25 20:20:22] [EMAIL PROTECTED] 404 not found.. [2007-01-25 20:16:28] oliver dot block at lycos dot de Let's start with the first function.:) You will find a diff file here: http://mitglied.lycos.de/oblock/easter.c.diff I also created more test files http://mitglied.lycos.de/oblock/easter_date_test.tar.gz Please check everthing and decide if you want to include it. [2007-01-24 13:54:13] [EMAIL PROTECTED] Basically we need to rewrite ext/calendar from scratch (to use ext/date types and utilities) and probably merge it into ext/date. Volunteers are welcome. [2007-01-23 19:29:22] oliver dot block at lycos dot de Description: If the timezone is set to another value than the system timezone, easter_date() will return a timestamp with respect to the systems local time, not with respect to the set timezone. That leads to wrong results of date/time function, e.g. date() which handle the (default) timestamp that is set my php (ini_set('date.timezone', 'UTC') or date_default_timezone_set() ). The problem occurs, if the timezone set by php is "east" of the system's timezone, if e.g. php timezone is 'UTC' and systems timezone is 'Europe/Berlin' Reproduce code: --- /ext/calendar/tests/easter_date.phpt Expected result: the test /ext/calendar/tests/easter_date.phpt should pass. Actual result: -- the test /ext/calendar/tests/easter_date.phpt will fail. -- Edit this bug report at http://bugs.php.net/?id=40213&edit=1
#40213 [Opn]: easter_date() returns wrong timestamp if ...
ID: 40213 User updated by: oliver dot block at lycos dot de Reported By: oliver dot block at lycos dot de Status: Open Bug Type: Calendar related Operating System: Linux PHP Version: 5.2.1RC3 New Comment: You will find the diff file here now: http://mitglied.lycos.de/oblock/php/easter.c.diff.gz Previous Comments: [2007-01-25 20:20:22] [EMAIL PROTECTED] 404 not found.. [2007-01-25 20:16:28] oliver dot block at lycos dot de Let's start with the first function.:) You will find a diff file here: http://mitglied.lycos.de/oblock/easter.c.diff I also created more test files http://mitglied.lycos.de/oblock/easter_date_test.tar.gz Please check everthing and decide if you want to include it. [2007-01-24 13:54:13] [EMAIL PROTECTED] Basically we need to rewrite ext/calendar from scratch (to use ext/date types and utilities) and probably merge it into ext/date. Volunteers are welcome. [2007-01-23 19:29:22] oliver dot block at lycos dot de Description: If the timezone is set to another value than the system timezone, easter_date() will return a timestamp with respect to the systems local time, not with respect to the set timezone. That leads to wrong results of date/time function, e.g. date() which handle the (default) timestamp that is set my php (ini_set('date.timezone', 'UTC') or date_default_timezone_set() ). The problem occurs, if the timezone set by php is "east" of the system's timezone, if e.g. php timezone is 'UTC' and systems timezone is 'Europe/Berlin' Reproduce code: --- /ext/calendar/tests/easter_date.phpt Expected result: the test /ext/calendar/tests/easter_date.phpt should pass. Actual result: -- the test /ext/calendar/tests/easter_date.phpt will fail. -- Edit this bug report at http://bugs.php.net/?id=40213&edit=1
#40213 [Opn]: easter_date() returns wrong timestamp if ...
ID: 40213 User updated by: oliver dot block at lycos dot de Reported By: oliver dot block at lycos dot de Status: Open Bug Type: Calendar related Operating System: Linux PHP Version: 5.2.1RC3 New Comment: Let's start with the first function.:) You will find a diff file here: http://mitglied.lycos.de/oblock/easter.c.diff I also created more test files http://mitglied.lycos.de/oblock/easter_date_test.tar.gz Please check everthing and decide if you want to include it. Previous Comments: [2007-01-24 13:54:13] [EMAIL PROTECTED] Basically we need to rewrite ext/calendar from scratch (to use ext/date types and utilities) and probably merge it into ext/date. Volunteers are welcome. [2007-01-23 19:29:22] oliver dot block at lycos dot de Description: If the timezone is set to another value than the system timezone, easter_date() will return a timestamp with respect to the systems local time, not with respect to the set timezone. That leads to wrong results of date/time function, e.g. date() which handle the (default) timestamp that is set my php (ini_set('date.timezone', 'UTC') or date_default_timezone_set() ). The problem occurs, if the timezone set by php is "east" of the system's timezone, if e.g. php timezone is 'UTC' and systems timezone is 'Europe/Berlin' Reproduce code: --- /ext/calendar/tests/easter_date.phpt Expected result: the test /ext/calendar/tests/easter_date.phpt should pass. Actual result: -- the test /ext/calendar/tests/easter_date.phpt will fail. -- Edit this bug report at http://bugs.php.net/?id=40213&edit=1
#40213 [NEW]: easter_date() returns wrong timestamp if ...
From: oliver dot block at lycos dot de Operating system: Linux PHP version: 5.2.1RC3 PHP Bug Type: Calendar related Bug description: easter_date() returns wrong timestamp if ... Description: If the timezone is set to another value than the system timezone, easter_date() will return a timestamp with respect to the systems local time, not with respect to the set timezone. That leads to wrong results of date/time function, e.g. date() which handle the (default) timestamp that is set my php (ini_set('date.timezone', 'UTC') or date_default_timezone_set() ). The problem occurs, if the timezone set by php is "east" of the system's timezone, if e.g. php timezone is 'UTC' and systems timezone is 'Europe/Berlin' Reproduce code: --- /ext/calendar/tests/easter_date.phpt Expected result: the test /ext/calendar/tests/easter_date.phpt should pass. Actual result: -- the test /ext/calendar/tests/easter_date.phpt will fail. -- Edit bug report at http://bugs.php.net/?id=40213&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40213&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40213&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40213&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40213&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40213&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40213&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40213&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40213&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40213&r=support Expected behavior:http://bugs.php.net/fix.php?id=40213&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40213&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40213&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40213&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40213&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40213&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40213&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40213&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40213&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40213&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40213&r=mysqlcfg
#37159 [Bgs->Csd]: imap_fetchstructure returns wrong encoding
ID: 37159 User updated by: oliver dot block at lycos dot de Reported By: oliver dot block at lycos dot de -Status: Bogus +Status: Closed Bug Type: IMAP related Operating System: Unix PHP Version: 5.1.2 New Comment: With strong support of Mark Crispin, author of the c-client library, it turned out, that the bug is neither in php nor in the c-client library. The cause of the behavior of the imap_fetchstructure function is a bug in the imap server of my ISP. It does not return imapr4 complaint data. Best Regards, Oliver Block Previous Comments: [2006-04-22 15:12:33] oliver dot block at lycos dot de workaround: check the header for existing Content-Transfer-Encoding: field if you receive an object returning encoding equal to 5. If there is none, a 7bit encoding should be assumed (according to RFC2045). Best Regards, Oliver [2006-04-22 13:19:49] oliver dot block at lycos dot de Thanks for your response. I'll do that. Yes, it is a bug. I am sure. [2006-04-22 08:11:54] [EMAIL PROTECTED] This is what IMAP c-client returns to PHP and we can't fix or change it in any way. If you consider it a bug - please report to c-client developers. Thanks. [2006-04-21 22:35:12] oliver dot block at lycos dot de Description: applying imap_fetchstructure to a message return wrong encoding value, if the message has NO Content-Encoding field. Reproduce code: --- $stream = imap_open($server, $username, $password); $msg_struct = imap_fetchstructure($stream, $uid, FT_UID); $encoding = $msg_struct->encoding; Expected result: If I apply this on a message with NO Content-Encoding field, $encoding should be equal to 0 -- according to RFC2045, Sect. 6.1. Actual result: -- If I apply this code on a message with NO Content-Encoding field, $encoding is equal to 5. -- Edit this bug report at http://bugs.php.net/?id=37159&edit=1
#37159 [Bgs]: imap_fetchstructure returns wrong encoding
ID: 37159 User updated by: oliver dot block at lycos dot de Reported By: oliver dot block at lycos dot de Status: Bogus Bug Type: IMAP related Operating System: Unix PHP Version: 5.1.2 New Comment: workaround: check the header for existing Content-Transfer-Encoding: field if you receive an object returning encoding equal to 5. If there is none, a 7bit encoding should be assumed (according to RFC2045). Best Regards, Oliver Previous Comments: [2006-04-22 13:19:49] oliver dot block at lycos dot de Thanks for your response. I'll do that. Yes, it is a bug. I am sure. [2006-04-22 08:11:54] [EMAIL PROTECTED] This is what IMAP c-client returns to PHP and we can't fix or change it in any way. If you consider it a bug - please report to c-client developers. Thanks. [2006-04-21 22:35:12] oliver dot block at lycos dot de Description: applying imap_fetchstructure to a message return wrong encoding value, if the message has NO Content-Encoding field. Reproduce code: --- $stream = imap_open($server, $username, $password); $msg_struct = imap_fetchstructure($stream, $uid, FT_UID); $encoding = $msg_struct->encoding; Expected result: If I apply this on a message with NO Content-Encoding field, $encoding should be equal to 0 -- according to RFC2045, Sect. 6.1. Actual result: -- If I apply this code on a message with NO Content-Encoding field, $encoding is equal to 5. -- Edit this bug report at http://bugs.php.net/?id=37159&edit=1
#37159 [Bgs]: imap_fetchstructure returns wrong encoding
ID: 37159 User updated by: oliver dot block at lycos dot de Reported By: oliver dot block at lycos dot de Status: Bogus Bug Type: IMAP related Operating System: Unix PHP Version: 5.1.2 New Comment: Thanks for your response. I'll do that. Yes, it is a bug. I am sure. Previous Comments: [2006-04-22 08:11:54] [EMAIL PROTECTED] This is what IMAP c-client returns to PHP and we can't fix or change it in any way. If you consider it a bug - please report to c-client developers. Thanks. [2006-04-21 22:35:12] oliver dot block at lycos dot de Description: applying imap_fetchstructure to a message return wrong encoding value, if the message has NO Content-Encoding field. Reproduce code: --- $stream = imap_open($server, $username, $password); $msg_struct = imap_fetchstructure($stream, $uid, FT_UID); $encoding = $msg_struct->encoding; Expected result: If I apply this on a message with NO Content-Encoding field, $encoding should be equal to 0 -- according to RFC2045, Sect. 6.1. Actual result: -- If I apply this code on a message with NO Content-Encoding field, $encoding is equal to 5. -- Edit this bug report at http://bugs.php.net/?id=37159&edit=1
#37159 [NEW]: imap_fetchstructure returns wrong encoding
From: oliver dot block at lycos dot de Operating system: Unix PHP version: 5.1.2 PHP Bug Type: IMAP related Bug description: imap_fetchstructure returns wrong encoding Description: applying imap_fetchstructure to a message return wrong encoding value, if the message has NO Content-Encoding field. Reproduce code: --- $stream = imap_open($server, $username, $password); $msg_struct = imap_fetchstructure($stream, $uid, FT_UID); $encoding = $msg_struct->encoding; Expected result: If I apply this on a message with NO Content-Encoding field, $encoding should be equal to 0 -- according to RFC2045, Sect. 6.1. Actual result: -- If I apply this code on a message with NO Content-Encoding field, $encoding is equal to 5. -- Edit bug report at http://bugs.php.net/?id=37159&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37159&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37159&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37159&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37159&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37159&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37159&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37159&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37159&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37159&r=support Expected behavior:http://bugs.php.net/fix.php?id=37159&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37159&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37159&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37159&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37159&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37159&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37159&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37159&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37159&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37159&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37159&r=mysqlcfg
#37109 [Bgs]: imap_header - malicious processing of multiple 'from'-headers
ID: 37109 User updated by: oliver dot block at lycos dot de Reported By: oliver dot block at lycos dot de Status: Bogus Bug Type: IMAP related Operating System: Unix PHP Version: 5.1.2 New Comment: I don't know, if I do understand you correctly. You mean the c-client library returns that (wrong) data? What about the data in imap_rcf822_parse_headers? Previous Comments: [2006-04-17 23:00:13] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. The function what the imap library returns, PHP has nothing with how the data is parsed internally. [2006-04-17 20:19:49] oliver dot block at lycos dot de imap_rfc822_parse_headers does deliver the correct _from_ field. [2006-04-17 17:43:19] oliver dot block at lycos dot de Description: When someone send mail with multiple from-header containing mulitple mailboxes, for example: From: name1 <[EMAIL PROTECTED]>, name2 <[EMAIL PROTECTED]>, name3 <[EMAIL PROTECTED]> the function imap_header() (maybe others too) should keep this edresses in the from-field. Unfortunately the imap_function does not keep this data in the from-field, but in the _sender_ field. The same is applicable to fromaddress and senderaddress fields! Reproduce code: --- "; print_r($header); print ""; imap_close($stream); ?> Expected result: [from] => Array [0] => stdClass Object ( [personal] => name1 [mailbox] => mbox1 [host] => hotmail.com ) [1] => stdClass Object ( [personal] => name2 [mailbox] => mbox2 [host] => yahoo.com ) [2] => stdClass Object ( [personal] => name3 [mailbox] => mbox3 [host] => web.de ) Actual result: -- [sender] => Array [0] => stdClass Object ( [personal] => name1 [mailbox] => mbox1 [host] => hotmail.com ) [1] => stdClass Object ( [personal] => name2 [mailbox] => mbox2 [host] => yahoo.com ) [2] => stdClass Object ( [personal] => name3 [mailbox] => mbox3 [host] => web.de ) -- Edit this bug report at http://bugs.php.net/?id=37109&edit=1
#37113 [Bgs]: Malicious Memory Management(?)
ID: 37113 User updated by: oliver dot block at lycos dot de Reported By: oliver dot block at lycos dot de Status: Bogus Bug Type: PCRE related Operating System: Unix PHP Version: 5.1.2 New Comment: But it does not return $match[7] which might contain GMT but _not_ (GMT). Previous Comments: [2006-04-17 22:59:43] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Your regex fetches the GMT, so where is the problem. [2006-04-17 21:08:55] oliver dot block at lycos dot de Description: preg_replace_callback returns content that should not be in memory! Reproduce code: --- input: 1. "Tue, 11 Apr 2006 17:09:22 GMT" 2. "Tue, 11 Apr 2006 20:26:57 + (GMT)" 3. "" function check_date($s) { $muster = "/(Mon, |Tue, |Wed, |Thu, |Fri, |Sat, |Sun, )?(\d\d?) (.{3}) (\d\d\d\d) (\d\d:\d\d(:\d\d)?) (([+-](\d\d(\d\d)))|GMT)/"; $result = ""; $result = preg_replace_callback($muster, create_function('$match', '$mon = array("Jan" => "01", "Feb" => "02", "Mar" => "03", "Apr" => "04", "May" => "05", "Jun" => "06", "Jul" => "07", "Aug" => "08", "Sep" => "09", "Okt" => "10", "Nov" => "11", "Dez" => "12"); $mm = $mon[$match[3]]; return "{$match[2]}.{$mm}.{$match[4]}"; '), $s); return $result; } Expected result: 1. "11.04.2006" 2. "11.04.2006" 3. "" Actual result: -- 1. "11.04.2006" 2. "11.04.2006 (GMT)" 3. "" -- Edit this bug report at http://bugs.php.net/?id=37113&edit=1
#37113 [NEW]: Malicious Memory Management(?)
From: oliver dot block at lycos dot de Operating system: Unix PHP version: 5.1.2 PHP Bug Type: PCRE related Bug description: Malicious Memory Management(?) Description: preg_replace_callback returns content that should not be in memory! Reproduce code: --- input: 1. "Tue, 11 Apr 2006 17:09:22 GMT" 2. "Tue, 11 Apr 2006 20:26:57 + (GMT)" 3. "" function check_date($s) { $muster = "/(Mon, |Tue, |Wed, |Thu, |Fri, |Sat, |Sun, )?(\d\d?) (.{3}) (\d\d\d\d) (\d\d:\d\d(:\d\d)?) (([+-](\d\d(\d\d)))|GMT)/"; $result = ""; $result = preg_replace_callback($muster, create_function('$match', '$mon = array("Jan" => "01", "Feb" => "02", "Mar" => "03", "Apr" => "04", "May" => "05", "Jun" => "06", "Jul" => "07", "Aug" => "08", "Sep" => "09", "Okt" => "10", "Nov" => "11", "Dez" => "12"); $mm = $mon[$match[3]]; return "{$match[2]}.{$mm}.{$match[4]}"; '), $s); return $result; } Expected result: 1. "11.04.2006" 2. "11.04.2006" 3. "" Actual result: -- 1. "11.04.2006" 2. "11.04.2006 (GMT)" 3. "" -- Edit bug report at http://bugs.php.net/?id=37113&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37113&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37113&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37113&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37113&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37113&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37113&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37113&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37113&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37113&r=support Expected behavior:http://bugs.php.net/fix.php?id=37113&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37113&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37113&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37113&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37113&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37113&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37113&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37113&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37113&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37113&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37113&r=mysqlcfg
#37109 [Opn]: imap_header - malicious processing of multiple 'from'-headers
ID: 37109 User updated by: oliver dot block at lycos dot de Reported By: oliver dot block at lycos dot de Status: Open Bug Type: IMAP related Operating System: Unix PHP Version: 5.1.2 New Comment: imap_rfc822_parse_headers does deliver the correct _from_ field. Previous Comments: [2006-04-17 17:43:19] oliver dot block at lycos dot de Description: When someone send mail with multiple from-header containing mulitple mailboxes, for example: From: name1 <[EMAIL PROTECTED]>, name2 <[EMAIL PROTECTED]>, name3 <[EMAIL PROTECTED]> the function imap_header() (maybe others too) should keep this edresses in the from-field. Unfortunately the imap_function does not keep this data in the from-field, but in the _sender_ field. The same is applicable to fromaddress and senderaddress fields! Reproduce code: --- "; print_r($header); print ""; imap_close($stream); ?> Expected result: [from] => Array [0] => stdClass Object ( [personal] => name1 [mailbox] => mbox1 [host] => hotmail.com ) [1] => stdClass Object ( [personal] => name2 [mailbox] => mbox2 [host] => yahoo.com ) [2] => stdClass Object ( [personal] => name3 [mailbox] => mbox3 [host] => web.de ) Actual result: -- [sender] => Array [0] => stdClass Object ( [personal] => name1 [mailbox] => mbox1 [host] => hotmail.com ) [1] => stdClass Object ( [personal] => name2 [mailbox] => mbox2 [host] => yahoo.com ) [2] => stdClass Object ( [personal] => name3 [mailbox] => mbox3 [host] => web.de ) -- Edit this bug report at http://bugs.php.net/?id=37109&edit=1
#37109 [NEW]: imap_header - malicious processing of multiple 'from'-headers
From: oliver dot block at lycos dot de Operating system: Unix PHP version: 5.1.2 PHP Bug Type: IMAP related Bug description: imap_header - malicious processing of multiple 'from'-headers Description: When someone send mail with multiple from-header containing mulitple mailboxes, for example: From: name1 <[EMAIL PROTECTED]>, name2 <[EMAIL PROTECTED]>, name3 <[EMAIL PROTECTED]> the function imap_header() (maybe others too) should keep this edresses in the from-field. Unfortunately the imap_function does not keep this data in the from-field, but in the _sender_ field. The same is applicable to fromaddress and senderaddress fields! Reproduce code: --- "; print_r($header); print ""; imap_close($stream); ?> Expected result: [from] => Array [0] => stdClass Object ( [personal] => name1 [mailbox] => mbox1 [host] => hotmail.com ) [1] => stdClass Object ( [personal] => name2 [mailbox] => mbox2 [host] => yahoo.com ) [2] => stdClass Object ( [personal] => name3 [mailbox] => mbox3 [host] => web.de ) Actual result: -- [sender] => Array [0] => stdClass Object ( [personal] => name1 [mailbox] => mbox1 [host] => hotmail.com ) [1] => stdClass Object ( [personal] => name2 [mailbox] => mbox2 [host] => yahoo.com ) [2] => stdClass Object ( [personal] => name3 [mailbox] => mbox3 [host] => web.de ) -- Edit bug report at http://bugs.php.net/?id=37109&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37109&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37109&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37109&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37109&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37109&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37109&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37109&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37109&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37109&r=support Expected behavior:http://bugs.php.net/fix.php?id=37109&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37109&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37109&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37109&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37109&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37109&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37109&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37109&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37109&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37109&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37109&r=mysqlcfg