mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 16:56:00 +03:00
[GH-ISSUE #468] Substitution of \n to spaces in Snippet webhook field makes some preformatted emails look ugly. #305
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#305
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 @baiomys on GitHub (Mar 16, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/468
Hi.
Especially forwarded messages previews look bad.
It should be like this:
Maybe you could use some UTF-8 character (\u00A0 NBSP for example) that looks like space instead of \n, to make backwards conversion possible?
@axllent commented on GitHub (Mar 17, 2025):
Hi.
Simply put, this is not possible. The snippet is intentionally written as a single line of text for two main reasons:
<div>From: sender user@proton.me</div><div>To: user@google.com</div>does not contain new lines at all, or HTML could contain new lines which are not visible in a browser).What you are asking for would require that the snippet generator replicate the browser logic in order to understand how the HTML data is visually structured (at least in terms of new lines), which is extremely difficult and falls completely outside of the purpose of a snippet.
To give you a better example, here's the exact HTML from Gmail in a forwarded message (all on one line):
Here's the syntax from a forwarded message from Thunderbird:
I hope you see my point as to why it would not work? Even if you were to separately query the message API to get the full HTML to try display it yourself (which is the only way), you would have a very difficult task trying to show only a part of that as a multi-line snippet due to the very mixed structure of so many emails.
@baiomys commented on GitHub (Mar 17, 2025):
Thanks for detailed answer.
To be honest, TXT parts exist in emails more often than HTML, maybe you should try to generate snippet from TXT first and then from HTML? Or at least make priority user definable?
As "side effect" using TXT for snippets will be dramatically faster, as you need to do only one regex for \n -> nbsp,
without stripping HTML tags, which is slow an inefficient.
@axllent commented on GitHub (Mar 17, 2025):
I don't think anything you said there is particularly accurate.
I'm not actually sure if populated HTML occurs less than populated text content - it is heavily dependent on the type of emails. From experience however, the HTML content (if used) is always the "accurate one". In newsletters the plain text is regularly used just to say "you need a HTML viewer to read this message", or "click here to view the newsletter online. In addition to this, many text emails are really badly formatted too as it's often auto-generated.
Snippets are created and stored only once during ingestion which takes approximately 0.0004s per email on Github Actions (benchmarking) - they are not generated "on the fly", so performance ("slow an inefficient") is not a valid argument here.
Lastly, I do not think that injecting hidden UTF8 characters is a good idea. I do understand what you are trying to achieve, but it will result in inconsistent and inaccurate output. I'll give it a bit more thought tonight though.
@baiomys commented on GitHub (Mar 17, 2025):
Thanks, sounds promising. =)
@axllent commented on GitHub (Mar 20, 2025):
After further review I can say this feature is out-of-scope.
To implement a truncated & formatted preview you will need to query the API (
/api/v1/message/<id>) which returns both the text & HTML parts, then you can decide yourself how you want to handle / parse & display that.As I mentioned earlier, your application should be designed to handle these types of features. Mailpit serves as an email and SMTP testing tool, offering an API for developers to access information through third-party tools. While your project approach is impressive, it doesn't align with Mailpit's intended use. Many of your feature requests seem to be trying to introduce your application logic into Mailpit, which is neither practical nor appropriate.
I would appreciate it if you could take a moment to carefully review points 3 and 4 regarding feature requests. The same is true for #469. My time is limited, but I will always do my best to address bugs and consider new features that genuinely benefit Mailpit. My goal is to avoid unnecessarily expanding the functionality for purposes that were not intended.