2

Is it possible that email sent via mail() won't be sent based on the originating page?

I have two pages, both are sending exactly the same content, in that for $result=mail($to, $subject, $message, $headers);, the result and parameters are byte-for-byte equal, with the same crc32() hash.

Even though mail() is returning true in all cases, we're getting emails for only one of the pages. Checked all the folders, including Spam and Trash. Tech support at the server side says they are seeing them in the sendmail log, so apparently they are going out.

We're setting From with a confirmed working email address. Nothing bounces back. Also tried setting Return-Path just to see, nothing.

Have also tested sending just regular emails, i.e. not identical, and still the same results. Emails from one page are consistently not received, while those from the other are.

I have never seen anything like this before. Can anyone shed some light on the issue?

Latest developments:

  • the code is now identical on both pages; still receiving emails from only one!

  • support just shrugged and said "must be the filename, try a different one"

That's not a great fix for us because it would mean canceling an approved binary at the app distribution site, resubmitting a revised one, then waiting for the approval process. Can take weeks.

Instead, what we're doing is dispatching using curl from the page with a "bad name" to a page with a "good name"! FYI, the bad name is apparently ws.php!

Yimin Rong
  • 1,890
  • 4
  • 31
  • 48
  • 1
    maybe they are in spam, or getting bounced. Just a tip always follow `DRY` concept , make a wrapper class around mail if that needs to be invoked from multiple pages that way if it works for one, it works for all :) – georoot Aug 23 '16 at 19:09
  • If the messages are identical, not just equal, it's possible a MUA is removing them to prevent duplicate accumulation. Change a few bytes in one email and you might receive it. – bishop Aug 23 '16 at 19:14
  • @bishop - The problem first occurred with "regular" messages, so yes have checked much different, different, slightly different, and finally identical emails from both pages. – Yimin Rong Aug 23 '16 at 19:20
  • If the log shows the messages leaving, and the disappearance happens for non-identical email, then spam or bounce is the best theory. Set the `Return-Path` header and/or set the `From` header to a monitored inbox. – bishop Aug 23 '16 at 19:26
  • @bishop - yes, have set `From` from the beginning, tried `Return-Path` just now - nothing bounced back. – Yimin Rong Aug 23 '16 at 20:51
  • It seems to me to be more like a server-problem than a code problem. Nevertheless, can we take a look at the code? – JohannesB Aug 24 '16 at 01:04
  • Have you tried sending to different recipients? Like sending to gmail? Mails sent through PHP usually have a header like this: X-PHP-Originating-Script: 0:ws.php so spam filters at the receiver side might filter based on this header? Maybe try mail.add_x_header = Off in your php.ini to turn off this header. – Christopher K. Aug 24 '16 at 09:02
  • Just for fun, have you tried using a 3rd file name? Also, what happens when you do `require_once('ws.php'); exit;` at the top of the "working php" and also what happens when you reverse that to `require_once('working.php'); exit;` at the top of `ws.php`. – Tigger Aug 24 '16 at 09:10
  • [So You'd Like to Send Some Email (Through Code)](https://blog.codinghorror.com/so-youd-like-to-send-some-email-through-code/) – deceze Aug 24 '16 at 09:16
  • This is simply not a code-level problem, it's a problem somewhere deep in the bowels of the global email delivery infrastructure. Once PHP hands over the mail to the local mail spooler, it's out of its hands. You will need to debug how and why the specific server sends mail. Perhaps your IP has landed on a spam blacklist, or you're missing DKIM setups for the domain or such. This is too broad to diagnose here, we can only point you in the general direction that is [email hell](http://stackoverflow.com/a/3905805/476). – deceze Aug 24 '16 at 09:18
  • 1
    @deceze: IP-based blacklists cannot be the cause as the OP says sending from the same server from another PHP script works. Same for DKIM, if the FROM and the sending server is the same, as claimed by the OP, DKIM will be the same. – Christopher K. Aug 24 '16 at 09:29
  • 1
    I think that this question is NOT a duplicate of linked question. I took a close look at the accepted answer of the "duplicate question" and almost all points mentioned there do not make any sense, if sending from the same server with exactly the same code works. The only thing of that answer that I consider useful is "Send to multiple accounts", as I commented before. It might help to check more logging as described there, but none of the points in the accepted answer explains why the filename could make a difference. – Christopher K. Aug 24 '16 at 09:47
  • @Christopher I'm not necessarily disagreeing, but again, it's not a *code level* problem and thereby somewhat outside the domain of Stack Overflow. If the emails handed over to sendmail are *identical* in all respects, that's it as far as SO is concerned. The next step would be to ask the hardcore server ops over at http://serverfault.com. – deceze Aug 24 '16 at 09:54
  • 1
    @deceze: In my opinion, it is a PHP issue if mail.add_x_header = Off would solve the problem. The OP does not say its *handed to sendmail* identical in all aspects, he says his *PHP code* is the same. PHP injects the X-PHP-Originating-Script header before the mail is passed to sendmail, and if the file names are different, it will hand different stuff over to sendmail. – Christopher K. Aug 24 '16 at 10:04
  • @Christopher Then the question is still why that makes a difference to sendmail, or anything else further down the chain… – deceze Aug 24 '16 at 10:06
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/121710/discussion-between-christopher-k-and-deceze). – Christopher K. Aug 24 '16 at 10:06
  • @ChristopherK. - I agree it's not a duplicate, but I have never, ever seen a question flagged as duplicate unflagged, regardless of what edits or arguments are made. – Yimin Rong Aug 25 '16 at 03:41
  • "Tech support at the server side says they are seeing them in the sendmail log, so apparently they are going out." That makes this *not* a question for SO. Your code works, end of story. – miken32 Aug 25 '16 at 18:59
  • Great that the duplicate marker has been removed in the end. A little sad though that the reputation went to someone else who gave more or less the same answer as me already in the comments (when answers were not possible due to duplication marker). – Christopher K. Aug 29 '16 at 13:44

1 Answers1

0

We're seeing this happen, too. We traced the cause to an admin adding mail.add_x_header = On to php.ini. We found this actually injects several headers containing the file name into emails:

  • X-PHP-Originating-Script
  • X-EN-Info
  • X-EN-CGIPath

With today's neural-network self-teaching autonomous filters, common file names like ws.php can be associated with spam. It doesn't care why, just plays the odds. The filter sees something in the list mentioned a lot of times, and suddenly your emails will trip the spam filters.

We had the option to change the file name, but I like your approach of using curl to redirect to a safe page!