Multipart - missing extra EOL

[lubosdz]

Problem description

I believe there is missing one extra EOL in:
https://github.com/PHPMailer/PHPMailer/blob/master/src/PHPMailer.php#L2609
$mimepre = 'This is a multi-part message in MIME format.' . static::$LE;

The line should read properly:
$mimepre = 'This is a multi-part message in MIME format.' . static::$LE. static::$LE;

Missing extra LE causes, that when downloaded email like EML file, MS Outlook (tested at least 2010) will not recognize properly first boundary. So it will show up in plaintext. Once added extra line, it shows up properly HTML formatted.

Currently rendered raw output is:

...
Content-Transfer-Encoding: 8bit
This is a multi-part message in MIME format.
--b1_7ZBRdlbIDcTVJNKZ2n35zPu19aYncKrNKjrpFKy6yM
Content-Type: text/plain; charset=utf-8
...

correctly should be (not extra line before first boundary):

...
Content-Transfer-Encoding: 8bit
This is a multi-part message in MIME format.

--b1_7ZBRdlbIDcTVJNKZ2n35zPu19aYncKrNKjrpFKy6yM
Content-Type: text/plain; charset=utf-8
...

The line "This is a multi-part message in MIME format." has been added about 3 yrs ago (~2016) according to git-blame and before that there had been there also 2 EOLs which worked fine. I found this issue after upgrading from 5.2.9 to newest version 6.1.4.

[Synchro]

Neither of those examples are correct because there should always be a blank line between headers and body. RFC2046 says that the boundary string must be preceded by a line break. The RFC has this to say about the preamble (the bit you're talking about):

There appears to be room for additional information prior to the
first boundary delimiter line and following the final boundary
delimiter line. These areas should generally be left blank, and
implementations must ignore anything that appears before the first
boundary delimiter line or after the last one.
NOTE: These "preamble" and "epilogue" areas are generally not used
because of the lack of proper typing of these parts and the lack of
clear semantics for handling these areas at gateways, particularly
X.400 gateways. However, rather than leaving the preamble area
blank, many MIME implementations have found this to be a convenient
place to insert an explanatory note for recipients who read the
message with pre-MIME software, since such notes will be ignored by
MIME-compliant software.

and that's exactly what we are doing here. There is another applicable note (emphasis mine):

NOTE: The CRLF preceding the boundary delimiter line is conceptually
attached to the boundary so that it is possible to have a part that
does not end with a CRLF (line break). Body parts that must be
considered to end with line breaks, therefore, must have two CRLFs
preceding the boundary delimiter line, the first of which is part of
the preceding body part, and the second of which is part of the
encapsulation boundary.

So we are indeed using a single CRLF before the boundary, and we're not bothered about the preamble ending with a line break, so this all checks out. I looked at some other clients - Apple Mail uses a blank line for the preamble:

Content-Type: multipart/alternative;
	boundary="Apple-Mail=_88308353-D2DC-44CE-9064-3635F6A10E95"


--Apple-Mail=_88308353-D2DC-44CE-9064-3635F6A10E95

Gmail doesn't use anything at all:

Content-Type: multipart/related; boundary="0000000000002ecc9605a05f9a62"

--0000000000002ecc9605a05f9a62

nor does Yahoo:

Content-Type: multipart/mixed; 
	boundary="----=_Part_9769341_1037085981.1583707729646"

------=_Part_9769341_1037085981.1583707729646

A boundary may be followed by a blank line, but this indicates that the MIME part has no headers at all.

In short, if this is really the case, this is a bug in Outlook, however, adding an extra break in the preamble is harmless. Care to make a PR?

[lubosdz]

PR #2009.
Thank you very much for your fast response and great analyse.