[edent]

Whenever I get email from my Commentics install, it appears mangled.  It isn't displaying as a proper multipart message - instead I see the raw HTML. I'm using the PHP email method. Any idea what I've done wrong? Everything else with Commentics works perfectly. Thanks!

[Steven]

I don't think I've seen this issue before but I did some searching and a lot of people say that doing a hard reload, with Command+Shift+R, fixes it. Also try viewing the email in a different browser.

[Steven]

Did that work for you? I have an idea of what it could be if it didn't.

[davidi47]

I get this problem, too, using PHP for emails. All emails sent have a sender's address like "myusername@us1.providedns.com" (my account at the IP host!), not the "From" email specified in the Commentics config email setting. Furthermore the email body contains all the MIME boundaries in plain text:

--1c573cb97308944e3a65cd42ee0b0e36
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

This happens using both email clients Thunderbird and Hotmail on two different computers. I've completely re-installed the entire Commentics system from scratch (v4.5.1) and it still happens. It's running on a x86_64-redhat-linux system 4.18 with PHP 8.1.31.

Looking at the headers in the email source code, you can see the intent of the PHP send() command in lines 4-9 below, but the headers seem to have a space in front of them and then they are ignored and over-ruled by the system defaults (lines 10-12) and all the MIME boundaries now appear in the message body.

To: comments@mydomain.com
Subject: Setup Test
MIME-Version: 1.0
 Message-ID: <f04685ac0e3402f4b30e2bc3a067d0cf@ mydomain.com >
 From: Demo <comments@mydomain.com>
 Reply-To: Demo <no-reply@mydomain.com>
 Return-Path: comments@mydomain.com
 Date: Sun, 26 Jan 2025 21:29:28 +0800
 Content-Type: multipart/mixed; boundary="1c573cb97308944e3a65cd42ee0b0e36"
Message-Id: <E1tc2hc-00000006EmN-3BJ8@us1.providedns.com>
From: myusername@us1.providedns.com
Date: Sun, 26 Jan 2025 08:29:28 -0500

--1c573cb97308944e3a65cd42ee0b0e36
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hello admin,

This is a test email generated by the 'Settings -> Email -> Setup' page.
-----[cut]----

Needless to say, this would frighten any recipient - an email from a strange unexpected sender full of weird hexadecimal content. I'd definitely delete it. This is a deal killer for Commentics.

Looking at the code, I'd guess there is an error in generating and passing the headers parameter to the PHP mail() function. Perhaps using PHP_EOL as a line ending causes an error - strictly it should always be "\r\n", but will be "\n" on Linux. I'd try and modify the code to test it but there is a lot of abstraction and I've spent two days already trying to sort it, so I'll throw it back to you guys.

And, no, the reset WIndows+R solution suggested does not work.

This happens for both HTML and Text format for emails. With HTML format, it's worse with all the HTML tags showing in the second half of the email.

To manage your preferences, click the link below:

https://etc
--5663470137a1cb40e6141d6b392fa4d6_alt
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit

<table style="border-collapse:collapse" border="0" cellpadding="0" cellspacing="0">
<tr>
<td>Hello D,</td>
</tr>
</table>

-----[cut]----

[Steven]

Is it possible that your web host is intentionally modifying those headers? Maybe they have a strict policy regarding the usage of their server's PHP mail feature and so force the "from" email to belong to the one associated with your hosting account. If so, I'd speak to them about it because their modifications are breaking the structure of the emails. I've just tested now the PHP mail feature on Commentics 4.5.1, PHP 8.3 and the Yahoo mail client and it works fine.

[davidi47]

Hi Steven,

I extracted the code from `/system/library/email.php` and tested it separately on the (Linux-based) web server. Unchanged it gave the same problem described before. But a global change of PHP_EOL to "\r\n" made it work properly.

According to the PHP mail() manual (and RFC2822), this is the correct way <https://www.php.net/manual/en/function.mail.php>

    This is typically used to add extra headers (From, Cc, and Bcc). Multiple extra headers should be separated with a CRLF (\r\n).

According to various searches PHP8 is stricter about this and it is either a bug or a feature depending on who is commenting! It seems some (old?) mail systems require a single "\n" (i.e. PHP_EOL on Linux) or they'll replace any CRLF with a double one, but that is meant to be a last resort according to the manual.

Maybe perhaps a user option to choose.

[Steven]

Ah thanks, that's really useful. I'll change it to "\r\n" with an admin option to switch it to "\n" if the user needs to.