Are you using more (|) characters to separate signatures from emails so that they are not imported into the issue?
https://www.mantisbt.org/wiki/doku.php/mantisbt:emailreporting#mail_strip_signature_delim

If the above is not applicable then it seems that markdownify is failing at converting this email.

Based on the html this email is also quite complex. markdownify is only meant for simple html emails and can convert basic spreadsheet formatted tables. Newsletters and stuff like this are often quite complex because companies want them to look nice and use tables for the layout. markdownify can not deal with this properly

Just this alone at the end should tell you enough want kind of stuff is in this email:
</div>
</td>
</tr>
</tbody></table>
</td>
</tr>
</tbody></table>
</td>
</tr>
</tbody></table>
</td>
</tr>
</tbody></table>
</td>
</tr>
</tbody></table>
</div>

Do you have any good ideas on how we want EmailReporting to deal with this issue?

One idea

Setting https://github.com/mantisbt-plugins/EmailReporting/blob/master/core/Mail/Parser.php#L437
to TRUE

But i'm unsure on what the results will be on other htm content.

@sl-gundam The signature delimiter I used is --. The email I forwarded doesn't have a signature on the top. So I guess it may not be the issue.

I too believe that it's the limitation in markdownify and I also agree with you on the dirty formatting in Newsletters. One probable solution is to get the plain text (without formatting) whenever markdownify fails to get the content. However, I couldn't figure out how to check the failure since it always has some content. This is kind of a complicated case...

How about we check with a regex whether there exists a table within a table in the html code

If it exists the email is considered complex and will fallback to plaintext

I made changes to Markdownify. Nested tables are now ignored. Everything should work better with EmailReporting 0.12.0 and later versions