php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #73934 Envelope Sender (-f) no longer working?
Submitted: 2017-01-14 12:44 UTC Modified: 2017-01-17 00:45 UTC
From: pqis at i dot ryanb dot com Assigned: yohgaki (profile)
Status: Closed Package: Mail related
PHP Version: 7.1.0 OS: x86_64-redhat-linux-gnu
Private report: No CVE-ID: None
View Developer Edit
 [2017-01-14 12:44 UTC] pqis at i dot ryanb dot com 
Description:
------------
I notice in PHP 7.0 when using mail() it is able to set the envelope-from (i believe this is also known as: Return-Path?) when i make use of the $additional_parameters field using "-f".  But in PHP7.1 this no longer works.




Test script:
---------------
$to      = "to@email.com";
$from    = "from@email.com";
$subject = "my subject";
$message = "my body";
$headers = "From: $from" . "\r\n" . "Reply-To: $from" . "\r\n" . "Return-Path: $from" . "\r\n" . "X-Mailer: PHP/" . phpversion();
$params  = "-f$from";

mail($to, $subject, $message, $headers, $params);

Expected result:
----------------
the envelope-from (and return-path) doesnt match the "From" field in php7.1.  It shows the servers own outgoing address not the one i gave for the from field.  

But when using the same test script in php7.0 it does match the from field and everything is correct.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-01-14 15:44 UTC] requinix@php.net
-Status: Open +Status: Feedback
 [2017-01-14 15:44 UTC] requinix@php.net 
There have not been any changes to mail() in PHP 7.1 so far. Are you sure that your MTA is honoring the -f parameter? What if you try using sendmail and -f from the command line?
 [2017-01-14 18:16 UTC] cmb@php.net 
Also consider to use something like `sendmail_path=echo` for
debugging.
 [2017-01-15 16:40 UTC] yohgaki@php.net 
I guess you have

mail.force_extra_parameters = 'something'

or something like this in your INI. Comment the ini setting out like

;mail.force_extra_parameters = 

to disable this INI.

If you don't have access to INI settings, e.g. php_admin_value, check the INI setting value by phpinfo() or ini_get_all().
 [2017-01-15 16:50 UTC] yohgaki@php.net 
Oops, I forgot mail.force_extra_parameters is INI_SYSTEM|INI_PERDIR. I'm not sure whether first or last one is outstanding. Comment it out all of them if any, then it should work.

If not, check your UMA (sendmail command) manual how -f option works. There are sendmail command variants. Your UMA may not support -f.

BTW, what is your OS?
 [2017-01-16 03:37 UTC] core905 at gmail dot com
-Status: Feedback +Status: Open -Operating System: +Operating System: x86_64-redhat-linux-gnu
 [2017-01-16 03:37 UTC] core905 at gmail dot com 
Much appreciated all for the replies.

@requinix: Thanks for the info.  That helps narrow things down at least.

@cmb: Although i am using a shared hoster i am not able to modify the sendmail_path via php code.  So no go for the "echo". For the record the sendmail_path is set (for both local+master) as: /usr/sbin/sendmail -t -i

@yohgaki: The mail.force_extra_parameters is set to "no value" for local and master.  Everything works fine for PHP7.0 but as soon as i switch to PHP7.1 its as if the "-f" is being ignored when using the mail() function.  Very strange.  The OS (on this shared hoster) is: x86_64-redhat-linux-gnu (Linux 2.6.32-673.26.1.lve1.4.20.el6.x86_64).  As for the sendmail variant... if it helps, when i type "sendmail --version" at the prompt i get back: "Exim version 4.87 #1 built 21-Dec-2016 15:44:28"

I've opened up a ticket with the hoster and hopefully they can narrow things down. No reply in 2 days though (they are usually very fast on other tickets so this long delay might be an indication they dont know or are still sniffing around).

Yea i figure its not an issue with PHP but instead is a configuration issue with the server when using PHP7.1.  However, i hope its ok to still leave this ticket open in hopes that you and others can continue to comment here so it can give me new ideas to try or pass on to the hoster.  If it's not ok then let me know and i will happily close this ticket.

Thanks again all.
 [2017-01-16 15:05 UTC] pqis at i dot ryanb dot com
-: core905 at gmail dot com +: pqis at i dot ryanb dot com -Status: Open +Status: Closed
 [2017-01-16 15:05 UTC] pqis at i dot ryanb dot com 
UPDATE:

yohgaki@php.net - you were right.  It was the mail.force_extra_parameters in php.ini.  The admin commented it out and everythign started working correctly now.

Thank you so much for the help to you and the others.
 [2017-01-16 15:21 UTC] cmb@php.net
-Assigned To: +Assigned To: cmb
 [2017-01-16 15:27 UTC] cmb@php.net
-Status: Closed +Status: Re-Opened -Assigned To: cmb +Assigned To: yohgaki
 [2017-01-16 15:27 UTC] cmb@php.net 
> The admin commented it out and everythign started working
> correctly now.

So it is not possible to disable mail.force_extra_parameters
explicitly? IOW, an empty string isn't the same as NULL, here[1]?
Is that behavior intentional?

[1] <http://lxr.php.net/xref/PHP-5.6/ext/standard/mail.c#167>
 [2017-01-17 00:45 UTC] yohgaki@php.net
-Status: Re-Opened +Status: Closed
 [2017-01-17 00:45 UTC] yohgaki@php.net 
@cmb
I'm not the one implemented this feature, but I think this is intentional so that admins disallow users to specify extra parameters of their own.

I closed this bug, but this behavior is debatable. If anyone think this should be changed, please re-open.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Dec 26 13:01:30 2024 UTC