E-mails sent from shared hosting, blocked. Is there a way to avoid that?

Question

Hello,

in my website i've a PHP script that automatically mails to my customers a confirmation about the order. My website's domain is registered to a company that hosts my website too. I have a lot of problems to send e-mails using mail() function to some e-mails accounts ... a lot of my users contact me saying that they have never received my automatic e-mail! So this is a very big problem!

The accounts, that give me more problems, are comcast.net, uol.com, mchsi.com and others! I've contacted the support center of these e-mail service providers asking for removing my ip from the block list too.

The header of the e-mail looks like this:

$header = "Sender: $from_mail\n";
$header .= "From: Account <$from_mail>\n";
$header .= "Reply-To: Account <$from_mail >\n";
$header .= "Content-Type: multipart/mixed; boundary=$mixed_boundary\n";
$header .= "Mime-Version: 1.0\n";
$header .= "X-Mailer: PHP/".phpversion()."\n";

$body = "\n--$mixed_boundary\n";
.
.
.
.
$body .= "\n\n--$mixed_boundary--";

mail($to, $subject, $body, utf8_encode($header), "-f$from_mail");

There is something that I can try to avoid this problem? Someone knows where can I look to know what is the IP address of the server used to deliver e-mails thought the PHP mail() function?

Thanks in advance for your replies!!!

---

Hi,

still today some e-mail provider service such as Comcast, continue to block my IPs addresses saying that my mail server sends spams ... I requested the removing from the blocklist, but their system continue block them! I don't know what else can I do ... I've followed your suggestions and the code look like this:

$md5 = md5(date('r', time()));
$mixed_boundary = "PHP-Mixed-$md5";
$alt_boundary = "PHP-Alt-$md5";

$header = "Sender: $from_mail\r\n";
$header .= "Errors-To: $from_mail\r\n";
$header .= "From: account <$from_mail>\r\n";
$header .= "Reply-To: $from_mail\r\n";
$header .= "Content-Type: multipart/mixed; boundary=$mixed_boundary\r\n";
$header .= "Mime-Version: 1.0\r\n";
$header .= "X-Mailer: PHP/".phpversion()."\r\n";

$body = "\n--$mixed_boundary\n";
$body .= "Content-Type: multipart/alternative; boundary=$alt_boundary\n";
.
.
.
.
$body .= "--$mixed_boundary\n";
$body .= "Content-Disposition: attachment filename=\"...\"\n";
$body .= "Content-Type: application/octet-stream; x-unix-mode=0644; name=\"...\"\n";
$body .= "Content-Transfer-Encoding: base64\n";
.
.
.
.
$body .= "\n\n--$mixed_boundary--";


mail($to, $subject, $body, utf8_encode($header), "-f$from_mail");

Suggestions?

Thanks again!

Answer 1

You could send yourself an email and check the headers. That will give you an idea of the path an email might take, but there's really nothing preventing emails to those other domains from going through a different path.

In general those big ISP's have really heavy duty spam filters, so mailing to them from a shared host is going to be tough. If you can get your own IP address and send mail from there, it will probably help. Then you can set up SPF records. No guarantees, but that will definitely elevate you out of the pit of commercial spammers a bit.

You could also do some digging with link text and some of the other anti-spam services and see if you're doing anything else wrong.

Asking customers to add your from address to their spam whitelist probably wouldn't hurt either.

Answer 2

Your message headers are not valid according to RFC2822 Internet Message Format.

From 2.1 General Description:

Messages are divided into lines of characters. A line is a series of characters that is delimited with the two characters carriage-return and line-feed; that is, the carriage return (CR) character (ASCII value 13) followed immediately by the line feed (LF) character (ASCII value 10). (The carriage-return/line-feed pair is usually written in this document as "CRLF".)

As I pointed out in my comments, the reason why your email may work with most mail servers anyway is that they may be liberal in what they accept. There may be some mail servers, however, that will discard your messages since they don't comply with RFC2822.

EDIT: Although the use of "\r\n" is advocated in the PHP documentation for the mail() function, there is some debate about whether that's really the right thing to do.

The mail() function will communicate with the local sendmail(8) command (or whatever is configured in sendmail_path), and the line endings may be processed differently depending on what mail transfer agent implementation is used. From what I understand, sendmail(8) should be OK with "\r\n", but qmail(7) for example will replace "\r\n" with "\r\r\n", which will probably break the message.

This all happens before the email is delivered to its final destination, so it may be easily tested whether the line endings are processed properly by sending one's self an email message constructed with "\r\n" and by verifying that all headers are present.

See also: RFC2822, PHP mail() function, sendmail(8), qmail(7)

Answer 3

I've found that setting Return-Path, Sender, and Errors-To headers help in some cases.

Answer 4

I've noticed that with my Linux hosting server, I have to replace all occurrences of CRLF with LF in both the extra headers and the mixed/alternative headers. About that the PHP documentation says:

"If messages are not received, try using a LF (\n) only. Some poor quality Unix mail transfer agents replace LF by CRLF automatically (which leads to doubling CR if CRLF is used). This should be a last resort, as it does not comply with » RFC 2822."

I've tried to send a mail (only with "\n") to my personal account and I've looked for "\r" and "\n" in the raw message ... each line is ended by a CR and started with a "\n"!

QUESTION: As the PHP mail() documentation says, I use the function wordwrap() to cut the line length to 70 characters. There is a workaround to let the mail client to display the message with its original formatting and not as a column where each line isn't longer than 70 chars?

ANSWER [SOLUTION]: I have solved setting up quoted-printable as Content-Transfer-Encoding:

$body .= "Content-Transfer-Encoding: quoted-printable\n";
$body .= "Content-Type: text/plain;\n\tcharset=utf-8;\n\tformat=flowed;\n\tdelsp=yes\n";

$body .= "\n" . quoted_printable_encode($message);

The quoted_printable_encode() function is available only with PHP 5.3, the implementation is suitable in the documentation page.

Answer 5

Use PHPMailer (http://phpmailer.worxware.com/) for building the email-messages. Maybe it's not the IP, but something else. There are a lot of things, where spamfilters react allergic (like missing Message-ID etc.). Plus with PHPMailer you have the opportunity to send your mails via mail() or if it dont't work due to shared-hosting-problems via SMTP over an other host (like Gmail).

Answer 6

Let me explain the battle you are facing. Forget about the technical details for a minute. There are hundreds of email providers out there. The big ones are Yahoo, Gmail, AOL, Hotmail, etc. If you are blocked on anyone of these services your business could be severely affected.

These email providers are extremely concerned about spam and in order to combat spam have gone to the extreme of blocking any messages that might be spam. You might never get spam complaints but if another business, on your shared hosting plan, gets spam complaints you will be effected. It doesn’t matter how you configure your application if you are on a suspected spam IP address your messages will be sent to the spam folder.

Even if you have your own server you will still have issues. Over time if you send emails some of the recipients will hit the spam button. This is a fact of life and there is nothing that you can do to prevent it.

The only solution is to outsource you email delivery. Companies like Aweber or iContact deal with email delivery issues for you. They have relationships with all major email providers and work hard to ensure that your messages get into the recipients inbox. You no longer have to worry about contacting Yahoo or Gmail because someone hit the spam button. You can focus on more important things.