9 Replies - 3463 Views - Last Post: 08 June 2011 - 08:10 AM Rate Topic: -----

#1 RealityMasque  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 5
  • Joined: 03-June 11

is there a bug in the php mail() function?

Posted 03 June 2011 - 06:20 AM

Heya,

I hoping someone will be able to help me, as I'm at a loss as to what is causing the problem.
Our website has a contact us form, with fields for name, email, kid name, kid ID, & message.
When the form submits, the server side php code validates the form fields, & if all is good, uses the built in php mail() function to send 2 emails.
Email 1 goes to an inbox on a hosted exchange server containing the values in the form fields.
Email 2 goes to the person submitting the form saying thanks - we'll get back to you shortly.
For email 1, the From, Reply-To, & Return-Path headers are set to the email entered in the form, & the To param in the mail() function is the email address of the inbox of the hosted exchange server.
For email 2, the From, Reply-To, & Return-Path headers are set to the email address of the inbox on the hosted exchange server, & the To param in the mail() function is the email address entered in the form.
The website's host has the MX, PTR, SPF, & TXT records set up properly to allow emails to be sent to & from the email address of the inbox of the hosted exchange server.
The website's host uses QMail as the SMTP service that actually sends the emails, & in all tests, QMail is receiving a success when sending both email 1 & 2. There is no error issued by the mail() function.

Local tests were done with IE8, Chrome, & FF3.6.17. The code was not changed between tests showing this problem.
In all test cases, email 2 (back to the person submitting the form) is sent just fine.
Email 1, on the other hand, is only intermittently working. The general pattern is that the 1st time the contact form is used with each distinct email address in the form, the email is sent fine, & the headers & to are correct.
The 2nd time the contact form is used with a previously used email address in the form, the To param is set to the email address in the form, the headers are all blank, & in spite of the To email address being incorrect, the email is not received.
The website's host's support staff may have found another potential symptom, which is that after clearing cookies, all the email 2's got through ok. However, the page does not use any cookies in relation to the form.
Lastly, I tried again a while (30 mins?) after email 2's weren't getting through, then another try worked, after which the email 2's screwed up as described above again.

Is there a known bug with php's mail() function along these lines? Is there a maximum frequency at which mail() can be used?
I'm at a loss as to why the code sometimes works, & sometimes doesn't. The website's host's staff are at a loss, as well.
Trying to google this issue seems to turn up forums of people saying to use different modules (Swift Mailer, PHPMailer, Pear Mail, etc.), but as the website is live, I'm wary that rebuilding the automated emailing code will introduce errors beyond the one described above.

- O8

Is This A Good Question/Topic? 0
  • +

Replies To: is there a bug in the php mail() function?

#2 Dormilich  Icon User is offline

  • 痛覚残留
  • member icon

Reputation: 3541
  • View blog
  • Posts: 10,236
  • Joined: 08-June 10

Re: is there a bug in the php mail() function?

Posted 03 June 2011 - 06:48 AM

View PostRealityMasque, on 03 June 2011 - 03:20 PM, said:

Trying to google this issue seems to turn up forums of people saying to use different modules (Swift Mailer, PHPMailer, Pear Mail, etc.), but as the website is live, I'm wary that rebuilding the automated emailing code will introduce errors beyond the one described above.

those mentioned libraries usually use HTTP socket connections (i.e. a real mailserver), not the sendmail binary. If you want to get away from mail() you would have to develop that accordingly (and if your website has a sensible framework/cms/system, switching the mail library should not be a problem)
Was This Post Helpful? 0
  • +
  • -

#3 JackOfAllTrades  Icon User is offline

  • Saucy!
  • member icon

Reputation: 6063
  • View blog
  • Posts: 23,516
  • Joined: 23-August 08

Re: is there a bug in the php mail() function?

Posted 03 June 2011 - 07:39 AM

Quote

hosted exchange server


One suspect is that there is something that the host here is using to pre-process incoming email which is being flagged somehow as being bad.
Was This Post Helpful? 0
  • +
  • -

#4 RealityMasque  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 5
  • Joined: 03-June 11

Re: is there a bug in the php mail() function?

Posted 03 June 2011 - 10:10 AM

View PostDormilich, on 03 June 2011 - 06:48 AM, said:

View PostRealityMasque, on 03 June 2011 - 03:20 PM, said:

Trying to google this issue seems to turn up forums of people saying to use different modules (Swift Mailer, PHPMailer, Pear Mail, etc.), but as the website is live, I'm wary that rebuilding the automated emailing code will introduce errors beyond the one described above.

those mentioned libraries usually use HTTP socket connections (i.e. a real mailserver), not the sendmail binary. If you want to get away from mail() you would have to develop that accordingly (and if your website has a sensible framework/cms/system, switching the mail library should not be a problem)


Since Rackspace hosts this site, they have control over the means by which PHP actually sends the email. They informed me that the ?QMail? service on the Linux box the website is served from is what actually does the sending. It's the ?QMail? logs they research to find out that the emails headers & To address were getting screwed up, but they were at a loss as to why. They suggested the code, but I suggested back that if the code can do it once correctly, then why would the same code do it incorrectly, for a particular email address put into the form, on an instance of a browser? They agreed to the logic of that, which leaves me speculating at whether the implementation of PHP's mail() function is the point of failure in this case...

- O8

View PostJackOfAllTrades, on 03 June 2011 - 07:39 AM, said:

Quote

hosted exchange server


One suspect is that there is something that the host here is using to pre-process incoming email which is being flagged somehow as being bad.


Excellent point! I asked Rackspace's email support about this, but they couldn't see anything indicating that any emails were even reaching the hosted exhcange server after the 1st one which worked. It's almost like the QMail sending the email is getting a false success on the send, or the messed up headers & To address (on the 2nd attempt with the same email from the same browser) is somehow logging as a success, but not actually sending...

- O8
Was This Post Helpful? 0
  • +
  • -

#5 JackOfAllTrades  Icon User is offline

  • Saucy!
  • member icon

Reputation: 6063
  • View blog
  • Posts: 23,516
  • Joined: 23-August 08

Re: is there a bug in the php mail() function?

Posted 03 June 2011 - 03:08 PM

Here you go. They have three levels of protection, so there's a good chance you're getting blocked in one of those three layers.
Was This Post Helpful? 0
  • +
  • -

#6 RealityMasque  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 5
  • Joined: 03-June 11

Re: is there a bug in the php mail() function?

Posted 04 June 2011 - 02:55 AM

View PostJackOfAllTrades, on 03 June 2011 - 03:08 PM, said:

Here you go. They have three levels of protection, so there's a good chance you're getting blocked in one of those three layers.


Heya JackOfAllTrades,

I worked with Rackspace to set up everything to work with the 3 levels of email validation that receiving email servers might perform, & according to them, the PTR, TXT, MX, & SPF records are the best we can do that the automatic emails sent out by the website will be received & not recognized as spam. Additionally, when I spoke with their email support staff, the log records on the receiving email inbox's hosted exchange server indicate that the emails aren't even being received from the website - i.e., they don't even seem to reach the server.

The problem seems to be when the code is creating the headers & To address right before the php mail() function is called. I suppose I'll have to test outputting to the page the values being put into the headers & To address for both the email to the person submitting the form & the email sending to the hosted exchange server. As long as that output appears correct, & supposing that the hosted exchange server is correct in not receiving the email, that leaves 2 points of failure that I can think of (& have no control over), i.e., PHP (thus the question), & QMail.

- O8
Was This Post Helpful? 0
  • +
  • -

#7 JackOfAllTrades  Icon User is offline

  • Saucy!
  • member icon

Reputation: 6063
  • View blog
  • Posts: 23,516
  • Joined: 23-August 08

Re: is there a bug in the php mail() function?

Posted 04 June 2011 - 04:44 AM

Quote

the log records on the receiving email inbox's hosted exchange server indicate that the emails aren't even being received from the website - i.e., they don't even seem to reach the server


Right, because if they're being stopped in the layers prior to reaching the Exchange server...they won't show up on the Exchange server. If the email staff at Rackspace is only looking on Exchange, then that would explain it. Have they checked the logs at the outer-most layer of protection?

Quote

The problem seems to be when the code is creating the headers & To address right before the php mail() function is called. I suppose I'll have to test outputting to the page the values being put into the headers & To address for both the email to the person submitting the form & the email sending to the hosted exchange server


Could well be, but we can't help with code we can't see ;)
Was This Post Helpful? 0
  • +
  • -

#8 RealityMasque  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 5
  • Joined: 03-June 11

Re: is there a bug in the php mail() function?

Posted 06 June 2011 - 01:37 AM

View PostJackOfAllTrades, on 04 June 2011 - 04:44 AM, said:

Quote

the log records on the receiving email inbox's hosted exchange server indicate that the emails aren't even being received from the website - i.e., they don't even seem to reach the server


Right, because if they're being stopped in the layers prior to reaching the Exchange server...they won't show up on the Exchange server. If the email staff at Rackspace is only looking on Exchange, then that would explain it. Have they checked the logs at the outer-most layer of protection?

Quote

The problem seems to be when the code is creating the headers & To address right before the php mail() function is called. I suppose I'll have to test outputting to the page the values being put into the headers & To address for both the email to the person submitting the form & the email sending to the hosted exchange server


Could well be, but we can't help with code we can't see ;)



Excellent point... Here's the most pertinent code:
	function UserToSiteEmail( $name, $fromEmail, $message, $kidID, $kidName )
	{
		$subject = "Face of Kinder - contact us";
		$headers = GetEmailHeaders($fromEmail);
		$imageFilename = constant("URL_ROOT")."/kidimages/".$kid->ImageFilename;
		$profileUrl = constant("URL_ROOT")."/profile.php?k=".$kid->KidID;
		$body = file_get_contents("EmailTemplates/ContactUs.html");
		$body = str_replace("#FromName#",$name,$body);
		$body = str_replace("#FromEmail#",$fromEmail,$body);
		$body = str_replace("#KidName#",$kidName,$body);
		$body = str_replace("#KidID#",$kidID,$body);
		$body = str_replace("#Message#",$message,$body);
		$body = str_replace("#SiteRoot#",constant("URL_ROOT"),$body);
		return mail(constant("FROM_EMAIL"),$subject,$body,$headers);
	}

    function GetEmailHeaders( $fromEmail )
    {
	$headers = "From: Face of Kinder <" . $fromEmail . ">" . PHP_EOL;
	$headers .= "Reply-To: " . $fromEmail . PHP_EOL;
	$headers .= "Return-Path: " . $fromEmail . PHP_EOL;
	$headers .= 'MIME-Version: 1.0' . PHP_EOL;
	$headers .= 'Content-type: text/html; charset=iso-8859-1' . PHP_EOL;
	
	return $headers;
    }


The UserToSiteEmail() funct uses the data from the contact us form, where the $fromEmail param is the email entered in the form. From what Rackspace could find in the QMail logs was that when the 2nd use of the same email in the contact us form gets submitted, the email in the form ends up in the To field, not in the headers, & the email inbox's address didn't show anywhere (not even the headers - i.e., it didn't swap). This is even though the same code correctly put the form's email into the header, & the email inbox's address in the To field on the 1st submitting of the form (per browser).

I can add the HTML side of the form if needed, but in terms of its process, after the form is submitted back to itself, after validating & emailing, the php redirects to a thanks page. I'm not certain how GET & POST variables would persist after the thank you page, as the only way back to the page is to click the link for the contact form again. To see the current process (without the problem - as it only seems to crop up when using the email inbox's domain), here's a link to a page with the contact us link in the footer: http://www.faceofkinder.com/home.php.

- O8

oh yeah, & here's the QMail log indicating the problem...

Jun 3 10:13:48 342812-web2 qmail-queue-handlers[1147]: Handlers Filter before-queue for qmail started ...
Jun 3 10:13:48 342812-web2 qmail-queue-handlers[1147]: from=
Jun 3 10:13:48 342812-web2 qmail-queue-handlers[1147]: to=orionculver@b-street.co.uk
Jun 3 10:13:48 342812-web2 qmail-queue-handlers[1147]: hook_dir = '/var/qmail//handlers/before-queue'
Jun 3 10:13:48 342812-web2 qmail-queue-handlers[1147]: recipient[3] = 'orionculver@b-street.co.uk'
Jun 3 10:13:48 342812-web2 qmail-queue-handlers[1147]: handlers dir = '/var/qmail//handlers/before-queue/recipient/orionculver@b-street.co.uk'
Jun 3 10:13:48 342812-web2 qmail-queue-handlers[1147]: starter: submitter[1148] exited normally
Jun 3 10:13:48 342812-web2 qmail: 1307092428.798059 bounce msg 18353656 qp 1147
Jun 3 10:13:48 342812-web2 qmail: 1307092428.798116 end msg 18353656
Jun 3 10:13:48 342812-web2 qmail: 1307092428.798338 new msg 18353663
Jun 3 10:13:48 342812-web2 qmail: 1307092428.798366 info msg 18353663: bytes 4902 from <> qp 1148 uid 2522
Jun 3 10:13:48 342812-web2 qmail: 1307092428.800937 starting delivery 2481: msg 18353663 to remote orionculver@b-street.co.uk
Jun 3 10:13:48 342812-web2 qmail: 1307092428.801071 status: local 0/10 remote 2/20
Jun 3 10:13:48 342812-web2 qmail-remote-handlers[1149]: Handlers Filter before-remote for qmail started ...
Jun 3 10:13:48 342812-web2 qmail-remote-handlers[1149]: from=
Jun 3 10:13:48 342812-web2 qmail-remote-handlers[1149]: to=orionculver@b-street.co.uk
Jun 3 10:13:50 342812-web2 qmail: 1307092430.526801 delivery 2481: success: 98.129.184.131_accepted_message./Remote_host_said:_250_OK_BD/F0-16184-DC5A8ED4/
Jun 3 10:13:50 342812-web2 qmail: 1307092430.526909 status: local 0/10 remote 1/20
Jun 3 10:13:50 342812-web2 qmail: 1307092430.526938 end msg 18353663
Jun 3 10:13:50 342812-web2 qmail: 1307092430.576988 delivery 2480: success: 98.129.184.131_accepted_message./Remote_host_said:_250_2.0.0_Ok:_queued_as_6D/F0-16184-DC5A8ED4/

- O8
Was This Post Helpful? 0
  • +
  • -

#9 Atli  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 3719
  • View blog
  • Posts: 5,990
  • Joined: 08-June 10

Re: is there a bug in the php mail() function?

Posted 06 June 2011 - 03:10 AM

Is that the whole UserToSiteEmail function? I ask because on lines #5 and #6 you use an object, $kid, that doesn't seem to be defined anywhere in the function. That should trigger a few notices, and mess up the links you are defining there. - It also raises the question of whether the code is suppressing other warnings/notices that may help explain this situation.

Also, header lines should be separated by "\r\n" new-lines, but if you use PHP_EOL on a Unix or Mac host, you'll only get "\n". - Perhaps not a critical issue, and most decent mail servers will probably read it either way. But still, seeing as this may be some obscure bug in either the mail function or QMail, it's probably best being precise.

And I assume the use of a constant named FROM_EMAIL as the $to parameter is just an unfortunate choice of phrase? :)
Was This Post Helpful? 1
  • +
  • -

#10 RealityMasque  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 5
  • Joined: 03-June 11

Re: is there a bug in the php mail() function?

Posted 08 June 2011 - 08:10 AM

View PostAtli, on 06 June 2011 - 03:10 AM, said:

Is that the whole UserToSiteEmail function? I ask because on lines #5 and #6 you use an object, $kid, that doesn't seem to be defined anywhere in the function. That should trigger a few notices, and mess up the links you are defining there. - It also raises the question of whether the code is suppressing other warnings/notices that may help explain this situation.

Also, header lines should be separated by "\r\n" new-lines, but if you use PHP_EOL on a Unix or Mac host, you'll only get "\n". - Perhaps not a critical issue, and most decent mail servers will probably read it either way. But still, seeing as this may be some obscure bug in either the mail function or QMail, it's probably best being precise.

And I assume the use of a constant named FROM_EMAIL as the $to parameter is just an unfortunate choice of phrase? :)


Yep, that's the whole function. Those objects are basically DB record objects, which are defined in separate php files for those classes. Instances of the objects are passed in from the webpage code. Here's the php code in the page that uses the UserToSiteEmail() function:

$success = UserToSiteEmail( $name, $email, $message, $kidID, $kidName );
$user = new User();
$user->FirstName = $name;
$user->LastName = "";
$success = SiteToUserEmail( $email, "contactus", null, $user, null, null );
header( "location:popup-contactusthanks.php" );
$done = true;



I just ran a test, outputting the To address & headers that the UserToSiteEmail() function comes up with on the dev version of the site, & from what I can see, the output consistently has the email address in the webform in the From address, & the headers has the correct from, reply-to, & return-path (i.e., the email inbox on the hosted exchange server). This, of course, leads me back to thinking it's PHP, QMail, or the hosted exchange server.

In terms of suppressing error messages, you're right, the code does not output error messages from php's mail function (if any). Then again, the QMail logs show a 250 - OK (even though the headers & To are off). In terms of the PHP_EOL, I followed the a practice as described on the PHP manual web page for the php mail() function, & the website is actually on a Linux box, so I'm not sure how that would be a problem. In terms of constant( 'FROM_EMAIL' ), you're right, it should really be something like constant( 'WEBSITE_EMAIL' ). Basically, that constant is the email address that the website uses when sending email from itself to users (e.g., reset password, complete registration, etc.). Since, in the case of the contact us form, the email is "from" the email address in the form, & "to" the hosted inbox (which uses the email address in the constant), I just reused constant( 'FROM_EMAIL' ).

I've reopened the ticket w/ Rackspace pertaining to these issues that have been brought up, & asked them to try an independent test replicating the scenario. Hopefully they'll be able to get on that ASAP, but in the meanwhile, are there any other ideas about what might be going wrong? Or perhaps other forums anyone is aware of that is more specific to the various technologies involved?

- O8
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1