Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Incorrect rendering for multipart/related with RFC compliant headers #52

Open
leftshift opened this issue Oct 11, 2021 · 1 comment
Open

Incorrect rendering for multipart/related with RFC compliant headers #52

leftshift opened this issue Oct 11, 2021 · 1 comment

Comments

@leftshift
Copy link

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.
@ssanko
Copy link

ssanko commented Jan 19, 2022

Is it possible to somehow push this issue???

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@leftshift @ssanko