[GH-ISSUE #538] Problem visualizing multipart message #348

Closed
opened 2026-03-15 14:00:41 +03:00 by kerem · 7 comments
Owner

Originally created by @glueball on GitHub (Jul 17, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/538

I have an issue where multipart messages are not being displayed correctly. As seen here, the "boundary" string appears as if it were part of the body:

Image

It might be the case that we are not sending the email correctly, but it seems to work OK with mail clients in production. I don't know enough about the email format to debug this further.

This is the "raw" tab:

Image

Could you, please, point me in the right direction to solve this issue?

Originally created by @glueball on GitHub (Jul 17, 2025). Original GitHub issue: https://github.com/axllent/mailpit/issues/538 I have an issue where multipart messages are not being displayed correctly. As seen here, the "boundary" string appears as if it were part of the body: <img width="995" height="294" alt="Image" src="https://github.com/user-attachments/assets/ab8759d1-dc72-4ec2-b5fb-742afae47203" /> It might be the case that we are not sending the email correctly, but it seems to work OK with mail clients in production. I don't know enough about the email format to debug this further. This is the "raw" tab: <img width="663" height="492" alt="Image" src="https://github.com/user-attachments/assets/4c7c1767-cd19-403c-869c-18e2632f4c2c" /> Could you, please, point me in the right direction to solve this issue?
kerem closed this issue 2026-03-15 14:00:46 +03:00
Author
Owner

@axllent commented on GitHub (Jul 17, 2025):

I'm not sure to be honest, given the limited information that can be seen in the screenshots. Are you building these emails yourself or using a library of sorts, or are you doing it by hand? My assumption would be that it has something to do with the boundary itself, but without a full raw email to test I can't tell you more. I would start by comparing your email with any other multipart message (that works), and try to spot the difference.

<!-- gh-comment-id:3085299051 --> @axllent commented on GitHub (Jul 17, 2025): I'm not sure to be honest, given the limited information that can be seen in the screenshots. Are you building these emails yourself or using a library of sorts, or are you doing it by hand? My assumption would be that it has something to do with the boundary itself, but without a full raw email to test I can't tell you more. I would start by comparing your email with any other multipart message (that works), and try to spot the difference.
Author
Owner

@glueball commented on GitHub (Jul 17, 2025):

You are right, sorry for the extremely lacking report.

Find attached a raw file downloaded from Mailpit directly. I renamed the *.eml file to *.txt since github didn't allow me to attach an *.eml.

Note that double-clicking the *.eml file displays it correctly in my email client.

We compose the emails using a Rust library called lettree (https://crates.io/crates/lettre). I've noted that we use multipart even when we don't have attachments (guess to simplify the code); but I'd say (not sure) that a multipart message with just one part is still legal. Lettree seems to use a random string for the boundary; I can try to customize the boundary if that helps.

Can also provide more examples if needed.

8bUdkD9KCjGR8kT5a9sAgh.txt

Edit: For more info, I'm currently using the docker image (axllent/mailpit), with the default config.

<!-- gh-comment-id:3085826166 --> @glueball commented on GitHub (Jul 17, 2025): You are right, sorry for the extremely lacking report. Find attached a raw file downloaded from Mailpit directly. I renamed the *.eml file to *.txt since github didn't allow me to attach an *.eml. Note that double-clicking the *.eml file displays it correctly in my email client. We compose the emails using a Rust library called lettree (https://crates.io/crates/lettre). I've noted that we use multipart even when we don't have attachments (guess to simplify the code); but I'd say (not sure) that a multipart message with just one part is still legal. Lettree seems to use a random string for the boundary; I can try to customize the boundary if that helps. Can also provide more examples if needed. [8bUdkD9KCjGR8kT5a9sAgh.txt](https://github.com/user-attachments/files/21306249/8bUdkD9KCjGR8kT5a9sAgh.txt) Edit: For more info, I'm currently using the docker image (axllent/mailpit), with the default config.
Author
Owner

@axllent commented on GitHub (Jul 18, 2025):

I see the error - You're got Content-Type in your headers twice ;-)

<!-- gh-comment-id:3086778488 --> @axllent commented on GitHub (Jul 18, 2025): I see the error - You're got `Content-Type` in your headers twice ;-)
Author
Owner

@glueball commented on GitHub (Jul 18, 2025):

Oh! So it seems that mailpit obveys the first and everything else that we've tried before obveys the second one (and that could come back and bite us in the back any time...). I'll see if I can fix it in our app code or pass the report upstream to lettree. Many thanks!

And of course thanks for mailpit ;)

<!-- gh-comment-id:3088034425 --> @glueball commented on GitHub (Jul 18, 2025): Oh! So it seems that mailpit obveys the first and everything else that we've tried before obveys the second one (and that could come back and bite us in the back any time...). I'll see if I can fix it in our app code or pass the report upstream to lettree. Many thanks! And of course thanks for mailpit ;)
Author
Owner

@axllent commented on GitHub (Jul 18, 2025):

You're welcome. Yeah that would appear to be the case, however you'll probably find that different clients will do different things when the headers are invalid. Some may have a form of error tolerance (like web browsers do), but in the end, a duplicate header is going to cause issues. Best to get that issue fixed 🤞

<!-- gh-comment-id:3088276099 --> @axllent commented on GitHub (Jul 18, 2025): You're welcome. Yeah that would appear to be the case, however you'll probably find that different clients will do different things when the headers are invalid. Some may have a form of error tolerance (like web browsers do), but in the end, a duplicate header is going to cause issues. Best to get that issue fixed 🤞
Author
Owner

@glueball commented on GitHub (Jul 18, 2025):

Update: Found the bug in our application code. We were adding the HTML content type by hand after creating the multipart body (which I assume adds the correct content type). Probably a leftover from when we added support to attachments.

Many thanks again for the help! And for the application.

If you'd like a feature request, it'd be great if this kind of header error could be flagged. I'd even be tempted to try to contribute that, but I've not been introduced to go yet.

<!-- gh-comment-id:3088766694 --> @glueball commented on GitHub (Jul 18, 2025): Update: Found the bug in our application code. We were adding the HTML content type by hand after creating the multipart body (which I assume adds the correct content type). Probably a leftover from when we added support to attachments. Many thanks again for the help! And for the application. If you'd like a feature request, it'd be great if this kind of header error could be flagged. I'd even be tempted to try to contribute that, but I've not been introduced to go yet.
Author
Owner

@axllent commented on GitHub (Jul 18, 2025):

Thanks for the suggestion. I'm really not sure how feasible such a feature would be, not that it wouldn't be very convenient, but rather that there are a bazillion different things that mail programs do incorrectly. Trying to get a meaningful test suite that one could rely on would be quite a mission I think. I'll keep it in mind though!

<!-- gh-comment-id:3088827457 --> @axllent commented on GitHub (Jul 18, 2025): Thanks for the suggestion. I'm really not sure how feasible such a feature would be, not that it wouldn't be very convenient, but rather that there are a bazillion different things that mail programs do incorrectly. Trying to get a meaningful test suite that one could rely on would be quite a mission I think. I'll keep it in mind though!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/mailpit#348
No description provided.