Set type and boundary in multipart/alternative example

[kynx]

Q	A
Documentation	yes
Bugfix	no
BC Break	no
New Feature	no
RFC	no
QA	no

Description

The current example for creating multipart/alternative emails with attachments does not set the type on the multipart/alternative part correctly and - I think but do not know for sure - set the boundary properly.

The $message->toString() from current example:

Date: Fri, 17 Nov 2023 01:28:55 +0000
MIME-Version: 1.0
Content-Type: multipart/related;
 boundary="=_9d9f789a56aeae641849c009c02fa723"

This is a message in Mime Format.  If you see this, your mail reader does not support this format.

--=_9d9f789a56aeae641849c009c02fa723
Content-Type: application/octet-stream
Content-Transfer-Encoding: 8bit

This is a message in Mime Format.  If you see this, your mail reader does not support this format.

--=_4d411f45abeb9e7a0f3f37bb3d9e31a4
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

foo
--=_4d411f45abeb9e7a0f3f37bb3d9e31a4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<h1>foo</h1>
--=_4d411f45abeb9e7a0f3f37bb3d9e31a4--
--=_9d9f789a56aeae641849c009c02fa723
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="image-file-name.jpg"

Zm9v
--=_9d9f789a56aeae641849c009c02fa723--

Note the Content-Type: application/octet-stream - this should be Content-Type: multipart/alternative.

The correct output should be something like:

Date: Fri, 17 Nov 2023 01:47:10 +0000
MIME-Version: 1.0
Content-Type: multipart/related;
 boundary="=_d571c7f5c9c8e28e0a473154b2b8f5b7"

This is a message in Mime Format.  If you see this, your mail reader does not support this format.

--=_d571c7f5c9c8e28e0a473154b2b8f5b7
Content-Type: multipart/alternative;
 boundary="=_fcf2fe73fcee5fe8fdf249c81779d2c7"
Content-Transfer-Encoding: 8bit

This is a message in Mime Format.  If you see this, your mail reader does not support this format.

--=_fcf2fe73fcee5fe8fdf249c81779d2c7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

foo
--=_fcf2fe73fcee5fe8fdf249c81779d2c7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<h1>foo</h1>
--=_fcf2fe73fcee5fe8fdf249c81779d2c7--
--=_d571c7f5c9c8e28e0a473154b2b8f5b7
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="image-file-name.jpg"

Zm9v
--=_d571c7f5c9c8e28e0a473154b2b8f5b7--

I happened on this while investigating Webador/SlmMail#157. The application I'm migrating to slm/mail sets the type and boundary as in this PR, and has been sending emails over SMTP successfully for yonks.

I'm not 100% sure setting the boundary is necessary. I'm not a MIME expert, but it looks suspicious to me that the first example above has the same boundary for the message as the multipart/alternative part. Someone made the effort in the application I'm working on to explicitly set it - I suspect it was for a reason 😁 Hopefully someone here will know for sure.

[Slamdunk]

You are right indeed. Please remove the typo line and we can release this 💪

[Slamdunk]

A typo I guess, removal needed

[kynx]

Gah. Was working late 😉