Set type and boundary in multipart/alternative example #254
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:Note the
Content-Type: application/octet-stream
- this should beContent-Type: multipart/alternative
.The correct output should be something like:
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.