mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 08:45:54 +03:00
[GH-ISSUE #538] Problem visualizing multipart message #348
Labels
No labels
awaiting feedback
bug
docker
documentation
enhancement
github_actions
invalid
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mailpit#348
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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:
Could you, please, point me in the right direction to solve this issue?
@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.
@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.
@axllent commented on GitHub (Jul 18, 2025):
I see the error - You're got
Content-Typein your headers twice ;-)@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 ;)
@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 🤞
@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.
@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!