[PHP-DOC] #37122 [Ana]: sendmail_from is Return-Path:, not From:
ID: 37122 User updated by: php-bugs at t43 dot mine dot nu Reported By: php-bugs at t43 dot mine dot nu Status: Analyzed Bug Type: Documentation problem Operating System: Windows PHP Version: 5.1.2 New Comment: First big thanks that you did something on my report. I'm not fluent in the php-manual editing or in english language, but it works yet a bit different: "sendmail_from": Which "Return-Path:" mail address should be used in mail sent from PHP under Windows. (If not set, and From: is given in $headers, From: gets duplicated as "Return-Path:" as well. If none is set, mail() does fail. Again, this is for Windows). Please note at least three points: - I don't know why Return-Path: seems required by SMTPs, but every single mail I looked at has it. According to RFC2822, Sender: would be more required, but it never occurred to me. - mail() on Windows is entirely different from mail() on Un*x. - mail() is mainly for beginners like me. Experienced people (like I'll be, soon) use PHPmailer, and later go for PEAR::mail. Nevertheless it makes sense to have mail(). Previous Comments: [2006-04-23 22:02:22] [EMAIL PROTECTED] I've managed to get my hands on windows machine to verify this. It is correct, for what ever reason the sendmail_from php.ini directive is used as "Return-Path" too and it can't be changed via the additional_headers parameter. If "From:" header isn't set as additional header the sendmail_from ini directive is used. How do you feel about the following patch? http://php.is/bugs/37122/win32.mail.ini.patch.txt [2006-04-23 14:12:32] php-bugs at t43 dot mine dot nu The comment from [EMAIL PROTECTED] does not match what I have observed, in Windows. I observe exactly the opposite, sentence by sentence. I looked at the mails produced on the receiver side, of course. Others have also observed, and reported, that sendmail_from makes the Return-Path: header. [2006-04-23 13:37:55] [EMAIL PROTECTED] AFAICT "Return-Path" isn't set by PHP at all unless you specificly put it in the headers yourself. The sendmail_from however seems to override (if specified) the "From" header which either needs to be documented or fixed. Possible fix: http://php.is/bugs/37122/win32.sendmail.patch.txt (Reclassified as php bug). -Hannes [2006-04-18 22:51:31] php-bugs at t43 dot mine dot nu similar bugs for mail() on Windows, but software-related, are 28038, 37073. Mine is documentation-related. [2006-04-18 17:36:53] php-bugs at t43 dot mine dot nu applies to version 5.1.2 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/37122 -- Edit this bug report at http://bugs.php.net/?id=37122&edit=1
[PHP-DOC] #37122 [Opn->Ana]: sendmail_from is Return-Path:, not From:
ID: 37122 Updated by: [EMAIL PROTECTED] Reported By: php-bugs at t43 dot mine dot nu -Status: Open +Status: Analyzed -Bug Type: *Mail Related +Bug Type: Documentation problem Operating System: Windows PHP Version: 5.1.2 New Comment: I've managed to get my hands on windows machine to verify this. It is correct, for what ever reason the sendmail_from php.ini directive is used as "Return-Path" too and it can't be changed via the additional_headers parameter. If "From:" header isn't set as additional header the sendmail_from ini directive is used. How do you feel about the following patch? http://php.is/bugs/37122/win32.mail.ini.patch.txt Previous Comments: [2006-04-23 14:12:32] php-bugs at t43 dot mine dot nu The comment from [EMAIL PROTECTED] does not match what I have observed, in Windows. I observe exactly the opposite, sentence by sentence. I looked at the mails produced on the receiver side, of course. Others have also observed, and reported, that sendmail_from makes the Return-Path: header. [2006-04-23 13:37:55] [EMAIL PROTECTED] AFAICT "Return-Path" isn't set by PHP at all unless you specificly put it in the headers yourself. The sendmail_from however seems to override (if specified) the "From" header which either needs to be documented or fixed. Possible fix: http://php.is/bugs/37122/win32.sendmail.patch.txt (Reclassified as php bug). -Hannes [2006-04-18 22:51:31] php-bugs at t43 dot mine dot nu similar bugs for mail() on Windows, but software-related, are 28038, 37073. Mine is documentation-related. [2006-04-18 17:36:53] php-bugs at t43 dot mine dot nu applies to version 5.1.2 [2006-04-18 17:35:28] php-bugs at t43 dot mine dot nu Description: The "sendmail_from" value from php.ini goes into the header Return-Path:, not into From: When it is not set, the From: header is required and duplicated into Return-Path:. Return-Path: cannot be set in the headers. sendmail_from has priority over From: für the Return-Path: A comment to Bug 14407 indeed says that sendmail_from is Return-Path: but this information is missing in the manual and opposite to what is written, namely that sendmail_from goes into From:. -- Edit this bug report at http://bugs.php.net/?id=37122&edit=1
[PHP-DOC] #37063 [Opn->Bgs]: Is md5 binary-safe?
ID: 37063
Updated by: [EMAIL PROTECTED]
Reported By: ceo at l-i-e dot com
-Status: Open
+Status: Bogus
Bug Type: Documentation problem
Operating System: Irrelevant
PHP Version: Irrelevant
New Comment:
Its kinda given that it is...
Previous Comments:
[2006-04-13 01:00:12] ceo at l-i-e dot com
Description:
Is md5 binary-safe?
I would think it would be, but it doesn't say it is...
Reproduce code:
---
$jpeg = file_get_contents('test.jpg');
$md5 = md5($jpeg);
//store $md5 in database to detect changes to test.jpg later
--
Edit this bug report at http://bugs.php.net/?id=37063&edit=1
[PHP-DOC] Notes Status, 14890 total
Following are the top 20 pages of the manual, sorted by the number of user notes contributed. These sections could use a polish, those notes represent 9.3% of the 14890 total user notes. Notes | Page ---+- 96 | http://php.net/manual/en/function.preg-replace.php 85 | http://php.net/manual/en/ref.session.php 84 | http://php.net/manual/en/ref.xml.php 78 | http://php.net/manual/en/ref.image.php 77 | http://php.net/manual/en/reserved.variables.php 77 | http://php.net/manual/en/function.mktime.php 71 | http://php.net/manual/en/function.date.php 70 | http://php.net/manual/en/function.strtotime.php 68 | http://php.net/manual/en/function.header.php 65 | http://php.net/manual/en/function.strpos.php 65 | http://php.net/manual/en/function.readdir.php 64 | http://php.net/manual/en/function.fsockopen.php 64 | http://php.net/manual/en/features.file-upload.php 63 | http://php.net/manual/en/ref.com.php 62 | http://php.net/manual/en/function.mssql-connect.php 60 | http://php.net/manual/en/function.in-array.php 60 | http://php.net/manual/en/ref.mail.php 60 | http://php.net/manual/en/function.array-search.php 59 | http://php.net/manual/en/function.preg-match.php 57 | http://php.net/manual/en/function.substr.php
[PHP-DOC] #37172 [Opn]: Wrong constants names for SPL
ID: 37172 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: * PHP Version: Irrelevant New Comment: Patch: http://php.is/bugs/phpdoc/phpdoc.spl.constants.patch.txt Previous Comments: [2006-04-23 10:00:02] [EMAIL PROTECTED] Description: The SPL constants changed between 5.0 and 5.1 from global constants to class constants. (Noticed via note from dominicsATgmail.com). -- Edit this bug report at http://bugs.php.net/?id=37172&edit=1
[PHP-DOC] #37172 [NEW]: Wrong constants names for SPL
From: [EMAIL PROTECTED] Operating system: * PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: Wrong constants names for SPL Description: The SPL constants changed between 5.0 and 5.1 from global constants to class constants. (Noticed via note from dominicsATgmail.com). -- Edit bug report at http://bugs.php.net/?id=37172&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37172&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37172&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37172&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37172&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37172&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37172&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37172&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37172&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37172&r=support Expected behavior:http://bugs.php.net/fix.php?id=37172&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37172&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37172&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37172&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37172&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37172&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37172&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37172&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37172&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37172&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37172&r=mysqlcfg
