Menu
Community /Pin to ProfileBookmark
@NogDogSep 04.2014 — #These things can be a PITA to debug, sometimes, as the actual "problem" may not show up until after PHP is done and the local mail server has accepted the request. Then if something is failing during that actual transmission, you may have to find/analyze the mail server's error log. Then, if that's not the issue, you could run into problems on the receiving side, typically due to spam-blocking stuff (which could be triggered by any combination of content, header, and source domain/IP criteria).
As far as local mail server issues, I've had better success using PHPMailer, using its built-in SMTP class, which seems to make more debug info available than PHP's built-in mail() function does, in case you want to try that line of approach.
PS: The most common issue I see with mail() is that many hosts require that the "From:" header be an valid email address [I]on that host[/I] -- though I [i]think[/i] that usually results in a detectable error from the mail() call, though I may be misrembering. Therefore if you are putting a dynamic value into the From header, you may need to instead hard code a valid email address then put that dynamic value into a Reply-To header.@NogDogSep 04.2014 — #PPS: My reply was being written before your reply, so from that, I'm guessing the From/Reply-To header issues isn't the, uh, issue. ?@NogDogSep 04.2014 — #Is this being run via the CLI (e.g. a cron job, or shell script, etc.)? If so, it might be interesting to check the processes it generates, and see if there's something weird going on, such as the process not going away when the script runs "normally" (and doesn't send the email). I'm wondering if something odd is going on where the call to mail() is not really completing, and hangs around in a zombie process, whereas when something goes "wrong", the process is terminated and forces the call to the system mail function to be terminated as well?
Yeah, I'm grasping at straws here, but can't really think of anything else. ?@NogDogSep 05.2014 — #Hmm...wish I had a revelation to give you. If I were in your shoes -- pending someone wise in the ways of mail chiming in -- I'd probably go with my previous idea of using PHPMailer with its SMTP option, just to see if bypassing PHP's mail() function solves it. I hate work-arounds instead of fixes, but sometimes you just have to bite the bullet. ?
mail() problem
I have a problem with a new script that processes incoming emails. I’m using some std. code that works in several other scripts just fine. This new script is giving me problems with the mail call though.
I have done extensive debugging to ensure that mail is the culprit. It has come down to my script issuing a call to error_log to post an entry prior to the mail() call and then one following the mail() call with the result of the call. The error log shows that the mail was sent successfully (if returns true) YET the email never arrives.
What conclusion would you make from this? That perhaps the headers were wrong? Well, I copy and pasted the headers from a script that worked just fine a minute ago and tried the problem script again and the email still does not show up. (The source for the headers did in fact send an email that I received)
So, the headers work in one place – they should work in the other, no? That means only that my post office (at my host) is rejecting the email?
Any ideas?
Sign in
to post a comment8 Comments(s) ↴
0
@NogDogSep 04.2014 — #These things can be a PITA to debug, sometimes, as the actual "problem" may not show up until after PHP is done and the local mail server has accepted the request. Then if something is failing during that actual transmission, you may have to find/analyze the mail server's error log. Then, if that's not the issue, you could run into problems on the receiving side, typically due to spam-blocking stuff (which could be triggered by any combination of content, header, and source domain/IP criteria).As far as local mail server issues, I've had better success using PHPMailer, using its built-in SMTP class, which seems to make more debug info available than PHP's built-in mail() function does, in case you want to try that line of approach.
PS: The most common issue I see with mail() is that many hosts require that the "From:" header be an valid email address [I]on that host[/I] -- though I [i]think[/i] that usually results in a detectable error from the mail() call, though I may be misrembering. Therefore if you are putting a dynamic value into the From header, you may need to instead hard code a valid email address then put that dynamic value into a Reply-To header.
0
@NogDogSep 04.2014 — #PPS: My reply was being written before your reply, so from that, I'm guessing the From/Reply-To header issues isn't the, uh, issue. ?0
@NogDogSep 04.2014 — #Is this being run via the CLI (e.g. a cron job, or shell script, etc.)? If so, it might be interesting to check the processes it generates, and see if there's something weird going on, such as the process not going away when the script runs "normally" (and doesn't send the email). I'm wondering if something odd is going on where the call to mail() is not really completing, and hangs around in a zombie process, whereas when something goes "wrong", the process is terminated and forces the call to the system mail function to be terminated as well?Yeah, I'm grasping at straws here, but can't really think of anything else. ?
0
@NogDogSep 05.2014 — #Hmm...wish I had a revelation to give you. If I were in your shoes -- pending someone wise in the ways of mail chiming in -- I'd probably go with my previous idea of using PHPMailer with its SMTP option, just to see if bypassing PHP's mail() function solves it. I hate work-arounds instead of fixes, but sometimes you just have to bite the bullet. ?