• The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

html emails not working?

yabado

Regular Pleskian
I have a PHP mailer script that sends out a multi-part email. Since moving to plesk this email comes in as one big plain text email like so...

Code:
--rms-mix-xbda95cce7efa4e5491439a9f8109e513x
Content-Type: multipart/alternative; boundary=rms-alt-xe38d8d20baa42e9bb94d747749c07602x

--rms-alt-xe38d8d20baa42e9bb94d747749c07602x
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: Quoted-printable

Your Name: mike

Your Email: [email protected]

Subject: test

Message: test

File: 



--rms-alt-xe38d8d20baa42e9bb94d747749c07602x
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: Quoted-printable

<html>
<head>
<title>test</title>
</head>
<body>
<p>
<b>Your Name:</b> mike<br /><br />
<b>Your Email:</b> [email protected]<br /><br />
<b>Subject:</b> test<br /><br />
<b>Message:</b> test<br /><br />
<b>File:</b> <br /><br />
</p>
</body>
</html>

--rms-alt-xe38d8d20baa42e9bb94d747749c07602x--



--rms-mix-xbda95cce7efa4e5491439a9f8109e513x--

If I view the same email in round cube, it is rendered fine.

If i tell the same script to send to gmail, then the email renders as it should.

Something is happening with the mail on server to break things and I cannot figure it out.

Has anyone experienced this and figured out the cause ( or have a fix ) ?
 
In order to create a multipart/alternative message, you need to specify a boundary and separate each part by that boundary. A good boundary string would be something that is highly unlikely to occur in the message part itself, such as a random string generated by sha1(uniqid()). For example:
Code:
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=c4d5d00c4725d9ed0b3c8b

--c4d5d00c4725d9ed0b3c8b
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

part1

--c4d5d00c4725d9ed0b3c8b
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<b>part2</b>

--c4d5d00c4725d9ed0b3c8b--
[code]
This is specified in [URL='http://tools.ietf.org/html/rfc2046#section-5.1.4']RFC 2046, section 5.1.4[/URL]. http://tools.ietf.org/html/rfc2046#section-5.1.4
 
Thanks for the reply, but if you read my post you will see that it is not the format ( as it works in different email clients ).
Is there a server setting somewhere that could be effecting how the email message is delivered?
 
I remember once I had that issue and I resolved it by changing from the default value of
Code:
default_mimetype
in
Code:
/etc/php.ini
depending on the location of your php.INI file.
 
I have found that it is a line ending issue.

PHP_EOL and \n works!

\r\n does not work.

Did not have this issue on a previous linux server, what could the difference be?
 
On some - primarily Unix-systems, the \r\n characters aren't handled properly. If you have problems with them, use just \n instead
 
Looks like the problem is qmail?
This is from PHP docs page, and what is happening....
Note:

If messages are not received, try using a LF (\n) only. Some Unix mail transfer agents (most notably» qmail) 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.

Is there a setting to thwart this?
 
Actually I am using the Postfix MTA, but the extra line break is still being added and breaking the email.

Never did this on my other non-plesk server running sendmail.
 
Back
Top