Has anyone else been having issues with mail()? It was working fine on the multitude of clients we have hosted with HMS up until about a month or two ago.

The function doesn't fail, but the mail is never delivered.

Anyone else having this issue?

It is often problematic to send emails from your Web server. This is especially true with PHP's scripts, as they use 'Sendmail' to deliver messages directly to your recipients mail server.

Since the messages originate from the web server spam checks, as well as reverse DNS lookups may fail. The primary cause of delivery failure from a web server is the fact that we do not have RDNS setup on all of the IPs from which the web server could be sending mail.

As a work around to the problems inherit with 'sendmail' you can use your shared email server to relay your messages for you. Since we already maintain the health of these servers, and ensure that they are not on any blocklists, you will have a much better chance that the recipients mail server will accept the messages.

PHP has no built in functionality to send messages through a remote server, however there is a utility programmed in PHP which will assist you, http://phpmailer.sourceforge.net/. PHPMailer is a very handy utility that will allow you to specify the remote mail server in your script.

Please try to send mail using the shared mail server, and if you continue to have difficulties please let us know.

Maybe that should be stated on the support site? Here's a few other things you can add to your support section for PHP:

- Actually, first you'll need to create a support section for PHP

- Some servers are unable to be upgraded to PHP5 for some reason and such servers should avoid using PHPMailer because it is broken in PHP4.

- If you're trying to send mail, don't read this article: http://www.hostmysite.com/support/linux/programming/phpmail/

- No PEAR installation on any HMS shared server is up-to-date and can't be updated because typing "sudo pear upgrade-all" is too much for our know-nothing techs to handle

- Our PHP environment is set up in such a way that makes creating a local PEAR installation not impossible, but exceedingly difficult.

- We run PHP version 5.1.6 because...well, I don't know. It's almost 3 years old.

- We give you your own copy of php.ini with your account, but don't let you modify it. After all, you pay for it, but we need to justify our huge support staff and give them things to do.

- If you ever run in to problems again and again with our service, we'll be sure to blame you for it and write back in a condescending manner.

- Need an extension installed? No problem. No!

I look forward to not doing business with this company in the future.

Msdi,

Our PHP installation is a bit dated due to Red Hat's Long Term Support cycle. You can read more about this here:

http://www.redhat.com/security/updates/errata/

We follow their guidelines to ensure that your servers are fully functional, and should something go wrong, we always have Red Hat support resources available to us. If we custom compile PHP on all our shared servers this support goes away.

This is also why we don't recommend you use the default installation of Pear, rather you should start fresh, this guide should get you going:

http://pear.php.net/manual/en/installation.shared.php

Any problems and a call or email to support should have you straightened out.

I have made this point, in regards to PHP, to our Higher Ups, and even have suggested partnering with the guys over at Zend, who provide an up to date PHP stack fully supported on Red Hat and CentOS distributions.

http://www.zend.com/en/products/server/

I'll be sure to make your voice heard again though, as I believe some points in your post have validity.

The reason you are unable to edit your PHP.ini file is because a simple change to something like the output_buffer size in PHP could consume the entire available RAM on the server bringing your site and all other shared sites on that server down. Thus you would have a much less stable environment, and likely much poorer performance. If you would like to manage the resources of your PHP applications you most certainly can upgrade to one of our VPS packages where you have complete control over these settings; in a shared environment however you can see how that might be problematic.

We've always attempted to install any necessary extensions for our customers; however we make a point to mention that if you move to a different server those extensions may not be available as we obviously have a standardized deployment process, which can't be updated to account for every customer's application requirements.

Also in regards to your problems with PHP 4; if you check your customer control panel you should have a button to switch your site to PHP 5 on our older servers.

http://www.hostmysite.com/support/linux/programming/phpversion/

I apologize your experience has been negative so far. Hopefully now you have a better understanding of why it is the way it is.

I should note, that we do have customers sending out mail from our shared Linux servers without issue. I personally subscribe to several newletters which are delivered from our shared Linux servers. Typically you just need to ensure that you are specifying the additional_headers parameter of the PHP mail script properly, and that you're not sending out unsolicited emails.

If you find that any of our shared servers are on a blacklist we will certainly make sure to address the issue and work with any customer who is abusing our email services as per our Acceptable Use Policy:

http://www.hostmysite.com/aup/

If you are experiencing problems with delivery, whether it be due to blacklists, or your own domain's reputation, you should have bounce back emails detailing the problem at the address specified as the From address in your script (Default: root@example.com). More information on reading bounce back messages can be found here:

http://tools.ietf.org/html/rfc5321#page-48

New Support Article, PHP Mailer