Requesting Help With Email Issue

As described in the other thread it is definetly the \r\n not correctly handled by some providers. Why I don't know but all can handle a single \n

RFC 5322

2.2.3. Long Header Fields

   Each header field is logically a single line of characters comprising
   the field name, the colon, and the field body.  For convenience
   however, and to deal with the 998/78 character limitations per line,
   the field body portion of a header field can be split into a
   multiple-line representation; this is called "folding".  The general
   rule is that wherever this specification allows for folding white
   space (not simply WSP characters), a CRLF may be inserted before any
   WSP.

http://tools.ietf.org/html/rfc5322#section-2.2.3

\r = CR (Carriage Return)

\n = LF (Line Feed)

\r\n = CR + LF

Yes, different systems may handle these differently, which is why both are used.

I don't see how removing a carriage return would affect the encoding but I will be more than happy to try and report back.  I thought maybe that having them together with the Mime type was confusing php in the parsing but separating them had no effect on the outcome.  I will remove the carriage return and see what happens.

Well smack me silly; dately's suggestion corrected the issue.  However, I really don't understand why removing the carriage return was the answer.  I have read a lot of articles today on php mail functions and they all included "\r\n".  I was checking emails through two different mail servers and both were having issues with the mail headers.

I would like more detail information on it because I just don't follow why the issue is the carriage return.  If the carriage return is an issue, why do all the mail functions I came across contain "\r\n"?

Its not that the \r\n is wrong, it seems some mail servers just don't like it or there is something going on with this WSP stuff mentioned. I only saw one provider yet having this problem but with just a \n they all work. Even the RFC tells to use \r\n

If you really want to know ask the provider why the not follow the RFC above. I also would like to know.

What are you currently using for a mail server?

Documentation on the PHP website for the mail function states that some mail transport agents such as qmail replace LF with CRLF automatically which results in double CR. It does not follow the RFC, so some mail transport agents are the cause.

I am using Postfix for the mail server.  I originally asked for help from someone that knew Postfix as I thought I had not set up the Postfix configuration properly.  However, searching for postfix answers in the search engines did not really turn up any answers and I did not get anyone that knew Postfix to reply to that earlier topic.  Dately was telling me the \r\n thing so I spent a lot of time looking for that answer in the search engines.

So GG how do you do what you found out here in this thread? 

I did remove the \r but since I run my own mail server, I would like to know if I need to configure Postfix differently.

Removing the \r carriage return did clear up the issue.  The file to edit is /inc/utils.inc.php.  Not sure what version you are running; in the 7.1.4 copy of the file you will find the function;

function sendMail

on line 427.  The function handles sending emails from Dolphin. The lines with \r\n are found on:

458: $sMailHeader = "MIME-Version: 1.0\r\n" . $sMailHeader;

465: $sMailHeader = "Content-type: text/html; charset=UTF-8\r\n" . $sMailHeader;

468: $sMailHeader = "Content-type: text/plain; charset=UTF-8\r\n" . $sMailHeader;

Using \n is the correct way. Here you can read everything about it.

https://bugs.php.net/bug.php?id=15841#c123771
http://stackoverflow.com/questions/2233336/postfix-screwing-up-email-headers

 Dately, thanks for the additional information; that first post was dated way back.  In your opinion, what should Boonex be doing?