Comment notifications mails are shown unreadable in mail clients when encoded as Base-64.
This is due to missing headers, especially "Content-Transfer-Encoding". Those headers are present in theory, but are appended as continuation lines (lines starting with whitespace) to another header.
So all headers from the array - starting with "From" - are converted to a string, separeted with "\n" (LF). But mail headers should end with "\r\n" (CRLF). See RFC 5322:
2.2. Header Fields
Header fields are lines beginning with a field name, followed by a
colon (":"), followed by a field body, and terminated by CRLF
So current versions of PHP - or Exim, my MTA - see "LF" as folding white space, but not as the end of a header line.
This is new to me. I had no problems with s9y 2.3.x on PHP 7.3.x. As the relevant code hasn't changed since 2.3.x, AFAIS, that's probably due to changed behaviour in PHP (or my mail server).
Problem description
s9y 2.5.0 on PHP 8.2.20
Comment notifications mails are shown unreadable in mail clients when encoded as Base-64.
This is due to missing headers, especially "Content-Transfer-Encoding". Those headers are present in theory, but are appended as continuation lines (lines starting with whitespace) to another header.
Real-life example (slightly anonymised):
All headers from "Reply-To" up to "Content-Transfer-Encoding" have leading whitespace, so they are concatenaed to form this very long header:
I have reproduced that behaviour by commenting on old entries on my blog that are moderated.
Probable cause
Those mails are sent via
serendipity_sendMail()
infunctions.php
.All those headers with leading whitespace are added to the
$maildata['headers']
array, and then PHP'smail()
function is called:So all headers from the array - starting with "From" - are converted to a string, separeted with "\n" (LF). But mail headers should end with "\r\n" (CRLF). See RFC 5322:
So current versions of PHP - or Exim, my MTA - see "LF" as folding white space, but not as the end of a header line.
This is new to me. I had no problems with s9y 2.3.x on PHP 7.3.x. As the relevant code hasn't changed since 2.3.x, AFAIS, that's probably due to changed behaviour in PHP (or my mail server).
Fix
Change the relevant line to
I can confirm that this change fixes the problem.
As the change makes s9y standard compliant, there should be no side effects.