Skip to content

Fix bug when multipart message getHTMLBody() method returns null #455

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 11, 2024

Conversation

michalkortas
Copy link
Contributor

This bug occurs when the recursively detected parts are fewer than 2. After making this change, the HTML body is properly loaded by this method.

@Webklex
Copy link
Owner

Webklex commented Apr 11, 2024

Hi @michalkortas ,
many thanks for your suggested improvements and your pull request!

Best regards & happy coding,

@Webklex Webklex merged commit fad09ad into Webklex:master Apr 11, 2024
@mariuszkrzaczkowski
Copy link

when will the change be published?

@mrhewitt
Copy link

Hi @michalkortas ,

Is there any chance you could provide a sample email or additional context for why you wanted this change?

Your commit causes cases where there is only a single part inside a multipart block to fall out of recursive parsing and treat entire multipart block as a single part, causing attachments to come out not decoded and bodies to disappear, as indicated in a number of issues raised recently.

I don't know any where near enough about mime formats to know if it is valid for a multipart block to have only a single block inside it, but either way it seems many mail clients generate both bodies and attachments this way so it is necessary to properly process single parts here as the original code did.

@lm-cmxkonzepte
Copy link
Contributor

lm-cmxkonzepte commented Jun 5, 2025

Same here, I came across an e-mail which has a single plaintext body inside of a multipart/alternative, which is inside of a multipart/related, which finally is inside of a multipart/mixed part. While this may seem like an extreme example, it is a real e-mail. It seems like the sending software always has all those parts and just fills them when needed.

I changed the line

if(count($parts) > 1) {

to

if(count($parts) >= 1) {

in order to return the part, even if it’s just a single one. For my use case, this worked, it returned my plaintext body properly decoded.

I also tested this with a well-formatted e-mail from Thunderbird, which had a multipart/signed, multipart/mixed, multipart/alternative and multipart/related parts nested within each other, the behavior was (expectedly) unchanged, since Thunderbird only generates multipart-parts when there are actually multiple parts in it.

Edit: only now saw PR #582 by @mrhewitt, I didn’t test it, but it’s functionally the same thing, so this fix works for my case as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants