[SOLVED] Sendmail Not Working Properly (PLEASE HELP)

[axiom82]

My dedicated server is a $29/mo lease (yeah, it's self-managed and the tech support guys are terrible).  I have a major problem sending multi-part emails via PHP's mail() function which include text/plain and text/html mime types.

 

Simply put, I cannot send HTML emails (using the PHP mail() function) which is core to my website working.  I have narrowed down the problem: it seems that the mail headers are getting cut off.  This would explain why the mail program (e.g. Microsoft Outlook) is not interpreting the emails as HTML and also why I see HTML source code written in plain text.

 

I have attached two screenshots.  You will see two versions of the same exact email message coming from different servers - one version comes from my faulty server, the other from a working server owned by a friend.  Because my friend's server has no problem sending HTML emails via my PHP mailer script, the issue must be on my server and not in the PHP script.

 

My guess is that my sendmail.cf file has a misconfiguration???

Here are my specs:

 

Linux Fedora Core 5

sendmail.i386          8.13.8-1.fc5

sendmail-cf.i386      8.13.8-1.fc5

 

 

Please help.  I really need this to work desperately.

 

Axiom82

 

 

[attachment deleted by admin]

[PFMaBiSmAd]

How do you know your php code for the headers is actually working? Perhaps it is doing something that is php configuration specific? Have you echoed the information being put into the headers so that you know what it actually is?

[axiom82]

I have been working on this issue for days now.  I feel very stupid finding the answer now LOL.  Apparently my server's php.ini does not recognize "X-Sender:bla@email.com/r/n"; for carriage return new lines.  I fixed the issue with an ugly hack: "X-Sender:bla@email.com

";

[PFMaBiSmAd]

Probably has something to do with this -

 

additional_headers (optional)

....

Note: 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.