blank email using thunderbird

Hi guys,
I’ve a server with virtualmin installed, but I’ve a strange configuration problem that I’m not able to solve.
I’ve a lot of sites using an old version of zencart (1.2.7), using sendmail with -f option; mails sent with this method looks empty in thunderbird, but these emails are not empty, if I show source the body is in.
I suppose this is a configuration problem because the same site, the same email, installed on a fedora server works without problems.

Here below are my headers, can you help? Thank you so much

From - Tue Aug 13 09:25:17 2013 X-Account-Key: account31 X-UIDL: X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: (qmail 29201 invoked by uid 30297); 13 Aug 2013 07:22:21 -0000 Received: from unknown (HELO ([]) (envelope-sender ) by (qmail-1.03) with SMTP for ; 13 Aug 2013 07:22:21 -0000 X-IronPort-Anti-Spam-Result: AgoCAGzeCVLGZZqil2dsb2JhbABBGoJCeYJ6gluzJIdIFg4BAQEBAQgWBzyCUnoUEwsWHRohCYd+Aw8MMpY2jyuILQyIX48FhF92A4dGg2yIW4NWgS2EUU6DaoF4gXqGRTyBLgcX Received: from unknown (HELO xxx.xx) ([]) by with SMTP; 13 Aug 2013 00:22:09 -0700 Received: by (Postfix, from userid 506) id 96AC2421B0; Tue, 13 Aug 2013 07:22:07 +0000 (UTC) To: xxx.xx Subject: [BESTELLUNG] Order Confirmation No: 2781 X-PHP-Originating-Script: 506:email.php From: "xxxxxxxxxxxxx" MIME-Version: 1.0 X-Mailer: Zen Cart Mailer Content-Type: multipart/alternative; boundary="=_99daaff9552e4f3d6cde843a41398d7b" Message-Id: <20130813072207.96AC2421B0@xxx.xx> Date: Tue, 13 Aug 2013 07:22:07 +0000 (UTC) X-Nonspam: None


Content-Type: text/plain; charset=“iso-8859-1”

Content-Transfer-Encoding: 7bit

Could you post a message that’s okay (from Fedora) and one that’s incorrect, for a comparison, with more lines in the body? You cut off this one in the middle of the header.

One thing that strikes me is the empty line between the Content-Type and Content-Transfer-Encoding lines. If there’s really an empty line there, that’s a problem. An empty line denotes the end of the header section, and anything below belongs to the body and is not interpreted as header directives.

Hi locutus, thank you for your reply and sorry for the delay.
First of all I’d like to add more info: it seems that also is unable to read these emails and that the problem is due to how my server handles carriage returns. In fact this is an extract of what I see when I show email source:


Content-Type: text/html; charset=“iso-8859-1”

Content-Transfer-Encoding: quoted-printable

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=

=3Diso-8859-1" /><base href=3D"" /><style typ=

e=3D"text/css">body{background:#e3e3e3;color: #2a1f1f;margin: 20 0 30 0;fon=

As you can see there is an additional empty line between html rows.

But I made some step forward… it seems that the anomaly is created by a php row in the code, this one:

return @mail($to, $subject, preg_replace("#(?<!\r)\n#s", “\r\n”, $this->output), $headers_list);

if I remove the “\r” everything goes ok

return @mail($to, $subject, preg_replace("#(?<!\r)\n#s", “\n”, $this->output), $headers_list);

So the question is: which entity is handling wrong my carriage returns?

Thank you so much for your help

Can you elaborate the question “which entity”?

The extraneous CR between the header lines is definitely the cause for the email being incorrectly displayed, since as I said an empty line (while not problematic within HTML) denotes the end of the email’s header.

Since you found the place in your PHP code where the extraneous CR is introduced, and changing that line fixes the problem, what question remains exactly? :slight_smile:

Hi locutus,
In my previous fedora server the code with “\r\n” worked perfectly, now that I switched to centos with virtualmin that row cause some problem, so I think that is a problem due to wrong configuration of virtualmin+postfix

So, since I’ve a lot of sites to migrate to the new server I’d like to fix the configuration problem, instead of fix that row on 50 sites :slight_smile:



Yeah, as Locutus mentioned, emails should only contain a linefeed (\n) character at the end of each line… anything other than that can cause problems.

Virtualmin isn’t involved in the email sending process, so you aren’t looking at a Virtualmin issue there.

Doing some Googling, I do see an option in newer Postfix versions that is capable of correcting emails that are sent using the CRLF (\r\n) line endings – there is documentation on that here:

Perhaps that option was enabled on your Fedora system?

That option requires Postfix 2.9 or newer though.


Right, CRLF is evil. Whoever at Microsoft came up with the idea to end lines in text files with that when they made up their first DOS deserves evil things done to them. :wink:

On a Linux system, use Linux line endings. Will save you a lot of trouble.

Thank you for your help guys, I’ll try to update my postfix 2.3.3 to a newer version

Thanks a lot for your help

Right, CRLF is evil. Whoever at Microsoft came up with the idea to end lines in text files with that when they made up their first DOS deserves evil things done to them. :wink:

Maybe they did it because CR+LF is more logical?

Do you remember those old mechanical typewriters?

(No, I’m not a MS fan) :wink:

Yes, it is more logical if you were to directly translate CR and LF to real life (i.e. typewriter - yes, I had one of those too :wink: ). It also makes sense for terminals, where you might want to move the cursor to the start of the current line without advancing to the next line.

From a computer science viewpoint though it is illogical, or rather impractical, to use two characters as a terminator for lines in a text file, without a real reason. AFAIK no other current OS does that.