mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 08:45:54 +03:00
[GH-ISSUE #348] Email decoding issue #232
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#232
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 @D3strukt0r on GitHub (Aug 15, 2024).
Original GitHub issue: https://github.com/axllent/mailpit/issues/348
Hello, we have been trying to figure out for hours now if an email we are sending from our backend is sending the email faulty or if it's mailpit display that's broken, and after rigorous testing we figured something is off with mailpit
Here are a working case (any length shorter or equal to this will work)
example-works.eml.txt
And an example where anything longer or equal to this length (not sure if this is actually true) will break
example-broken.eml.txt
when being sent to any other mailcatcher software or opening in MS Outlook, it is displayed correctly
I hope this can help you identify the issue :)
PS: I tested with Mailpit v1.20.1
@axllent commented on GitHub (Aug 15, 2024):
@D3strukt0r I can confirm the decoding issue using your sample messages, and I can also confirm that this is originating "upstream" in the jhillyerd/enmime module (which Mailpit uses to decode messages). I was able to replicate it with a simple test to rule out that it is related in any way to Mailpit (see below).
What I can't confirm is whether it has anything to do with your message encoding / structure (I cannot see any obvious issue). It is very strange how just a slight change causes the issue, so it appears to be a possible issue with
jhillyerd/enmime.main.go
Working example:
Broken example:
My suggestion would be for you to report the issue to jhillyerd/enmime and hopefully someone there can either confirm (and potentially fix) the issue, or explain why your message is causing this. It may be useful to reference this issue to save them time.
@axllent commented on GitHub (Aug 21, 2024):
I can confirm that I get the correct decoding using the default Go library, so I am almost 100% certain it's an upstream (enmime) issue. I will continue to investigate and see if I can find a workaround as I'm not entirely sure a fix will come any time soon.
@axllent commented on GitHub (Aug 27, 2024):
I've found the reason why this happens (commented on in the issue you reported) - will wait for a response to try understand why before I look at a solution (assuming it's not a bug).
@axllent commented on GitHub (Sep 1, 2024):
@D3strukt0r I have just released v1.20.3 which should provide a solution for your issue. Please confirm it is working correctly for you now? Thanks.
@D3strukt0r commented on GitHub (Sep 2, 2024):
@axllent yes seems to be working fine for me now :)
thank you a lot <3
@axllent commented on GitHub (Sep 2, 2024):
That's fantastic, thank you for the feedback.