Incorrect rendering for multipart/related with RFC compliant headers #52
Description
According to RFC2387, the Content-Type-header for multipart/related requires the type parameter. The RFC isn't super clear about what this means, but some looking around clarifies that this should be the content type of the 'root' part of the multipart.
For a multipart/related with html and images, this might look something like this:
[...]
Content-Type: multipart/related; type="text/html"; boundary="--boundry"
----boundry
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<!doctype html>
[...]
The 'root' HTML part that should be displayed is obviously the one after the boundry; however, the logic in getMessageHTML just picks the first Content-Type-Header that contains the substring text/html. This leads to everything from and including ----boundry to be incorrectly treated and displayed as html.
A possible fix would be to check whether the value of the header actually starts with 'text/html', rather than just checking for containment.
In general, it unfortunately is non-trivial and as far as I'm aware not really specified how to find the actual body to display in an email, so I think just displaying the first thing that looks like text/html a valid approach. Unfortunately, the current behavior breaks for emails strictly conforming to RFC2387.