mailpit icon indicating copy to clipboard operation
mailpit copied to clipboard

RFE: show Show sender machine in web gui

Open macau23 opened this issue 3 years ago • 2 comments

(Stolen from https://github.com/mailhog/MailHog/issues/207)

Nice to see an active similar project! Can I make a feature request?

It'd be a huge time saver to show which machine the web interface were accepted from. A filter using that would help a lot too. Thanks.

macau23 avatar Oct 17 '22 12:10 macau23

An example of when this feature would be useful: you have lots of servers talking to one MailPit instance, and you want to quickly filter the e-mails to show those from a certain server.

macau23 avatar Oct 17 '22 12:10 macau23

I am considering this, however you want this header to show, another user may want other headers etc. - I can't/won't show them all. I think this could potentially be a runtime flag (to specify which), but I have to give it now thought before I consider implementing this as it also affects the API output.

As for filtering, that is a bit more complicated as the searchable database only indexes certain fields (eg: 95% of the headers are useless and only pollute the search index). Again, I have to give this more thought.

axllent avatar Oct 20 '22 11:10 axllent

@macau23 I'm still looking into this feature. You said you wanted to see the "sender", however which email header field would provide you with the information you require? The only standard one I can see is the Received header, however there are often (depending how the mail is routed) multiple of these in the headers. This means that displaying them can end up taking up multiple lines in the mail view. In an example I'm viewing I have 16x Received headers in the email:

Screenshot 2022-11-02 at 17-12-25 Mailpit

Can you please explain to me how you think this should/would work? I could simply take the very latest of each header (if set) and use that (though that may not suit everyone), or show them all (which also may not suit everyone). I'm interested in your feedback please.

axllent avatar Nov 02 '22 04:11 axllent

@axllent I have been thinking about this too. I think there are two choices: either show the most recent hop, or provide a way to tag e-mails outside of the gui along with a filter for tags inside the gui. I need to think some more.

macau23 avatar Nov 04 '22 16:11 macau23

Nice, I think tagging is a fantastic idea! I would need to carefully consider the implementation as it would add overhead to the in ingestion process (SMTP), but it would likely solve several things. I'd be interested to hear your thoughts on configuration, as it would probably need to be configured via the cli - or if that becomes too impractical in the UI itself.

axllent avatar Nov 04 '22 18:11 axllent

None of this is committed yet into code - I am simply playing around to see what can and can't be done at this stage. So far I have come up with a system that:

  1. Stores individual tags with emails.
  2. "Filters" can be added on the commandline in the format of mailpit --tag '<tag1>="<string-to-match>" <tag2>="<string-to-match>"' and are applied when messages are received. These are string matches (not regular expressions) matching any string in the entire email including headers and body, so cannot be limited to particular headers. If you added --tag "[email protected]" every new email containing [email protected] anywhere in the raw message would be tagged with "User". This could of course be a hostname in the headers (eg: host1="from blaa2345.example.com")
  3. Message list displays their tags (similar to Gmail) in the subject line.
  4. Messages can be manually filtered (searched) by tags using tag:<tag> in the search (including multiple, or excluding).
  5. All unique tags (in use) are displayed in the side nav for easy filtering.

What can't be done:

  1. An message/unread count for each tag - this is just too complicated and would require too many heavy database queries.
  2. Tag filtering is limited to 200 messages (it is just a search filter).
  3. Live streaming (websocket) is not possible when filtering by a tag (just like a search), so if filtering by a tag, new messages matching that tag don't appear until you return to the inbox view.

Please let me know what you think of this solution and whether that could work for your requirements?

axllent avatar Nov 05 '22 11:11 axllent

I think this could work! I wonder if it would be safer or less error-prone to split header and body tags though. Normally the end user has a lot of control over the body, and less over the header.

macau23 avatar Nov 11 '22 07:11 macau23

I'm just sharing my thoughts while I work on this... To be honest I can't see a functional and efficient manner in order to achieve this (header/body). Given that all CLI flags also need to be set via an environment variable, the syntax already looks something like:

mailpit -t 'host1=host1.domain.com host2=host2.domain.com "Another tag"="www.example.com"'`

So "<tag name>"="<string to match>" - it's not pretty, but I can't see any other way of doing this without relying on an external configuration file which I prefer not want to do. The matches are currently done by simply matching the string anywhere within the email which does not add much overhead to the parsing speed. If, however, I have to split the email into a header and footer, expand the taging syntax to allow one or the other or both, I believe it will over-complicate things, both the coding as well as the tagging syntax. This will also likely have a very negative performance & memory impact when ingesting new emails.

axllent avatar Nov 11 '22 11:11 axllent

I have just released the tagging feature in v1.2.8. Assuming each machine (that you are wanting to tag) is identified by a unique name, you should be able to add tag filters using these. I have also documented the tagging syntax in the wiki.

axllent avatar Nov 13 '22 04:11 axllent

Thanks a lot! I will give it a go!

macau23 avatar Nov 14 '22 07:11 macau23

This issue is stale because it has been open for 30 days with no activity.

github-actions[bot] avatar Dec 24 '22 02:12 github-actions[bot]

This issue was closed because it has been inactive for 7 days since being marked as stale.

github-actions[bot] avatar Dec 31 '22 02:12 github-actions[bot]