Empty HTML body, content is considered as attachment

[digiwirtual]

Wrong parsing parts of email, result is empty body and one attachment with wrong parsed html content.

Used config

Problematic email
0-email.zip

1. Initially, in Structure::parsePart, everything is processed correctly. One part is detected from the email, which is valid – see the output of $parts.
2. However, at line 118, the condition is skipped, and the valid variable $parts is discarded. The code continues at line 123, where the body is re-parsed using the class Part. The result is an invalid $part.
3. The final result is that the Message object does not contain $bodies, but it does contain an attachment where $part is invalid.
4. The solution lies at line 118 – if the valid result ($parts) were not discarded, the issue would be resolved.

The actual bug seems to be here, but you'll need to determine that yourself, as I don't have perfect knowledge of the email structure. Maybe other parts of the email should not be considered as empty so condition will work...

[mrhewitt]

Also related to #582

Looking at your example it has same structure as #580 , a single part inside a multipart structure, PR for issue #455 altered the line you highlight, the original code was:

return $this->detectParts($boundary, $body, $part_number);

Reverting back to this (i.e revert commit fad09ad) results in your body being returned correctly.

Unfortunately #455 did not contain any example Mime content so I am not sure what structure he had to require skipping parts if only one is detected inside a mulitpart block, but it seems to be causing some ripples of issues

FYI, I mention I am working on a PR but it was fix for attachments, I didnt realize how extensive issue was and wont help here .

I am not unconvinced perhaps content in issue #455 is exception rather than the rule.

[radek-hill]

Idea: it can be implemented as feature flag, which will be enabled only for testing purpose or peaple having issue like me. In this case it wount affect any working implementation and after some time, when we will have enought experience with enabled feature, can be removed and fixed permanently.

[mrhewitt]

@radek-hill , not quite sure its clear what issue you are having (the one mentioned in this issue or one in #455) but I submitted a PR which I hope will allow both to co-exist.

I also used the idea of a feature flag in a way, I added a new option "allow_single_parts" that be default is enabled and returns from parsePart even if only one part is detected, so library returns to functioning as it did before.

However users like @michalkortas who for some reason need to throw away parsed single blocks in a multipart structure and fall through to returning entire content as a single part can still achieve this by setting this option to false, so lets see if that maybe can be an acceptable idea to a middle ground here