[GH-ISSUE #237] Feature request: grouping messages by various criteria (sender, originating server, etc)

kerem commented

2026-03-15 12:53:42 +03:00

Owner

Originally created by @wesyah234 on GitHub (Jan 16, 2024).
Original GitHub issue: https://github.com/axllent/mailpit/issues/237

The use case is this: our development team shares a single instance of mailpit, but we each test different apps that are sending messages in, and when one developer goes in to view their messages, they'd rather not see messages from the other developer's testing efforts. Sometimes, if only one developer is needing to test at a given time, they can check with the others and then delete all the older messages, giving themselves a clean slate, but if 2 people are testing at the same time this is not possible.

The idea would be to have a filter on the left side, that would dynamically group messages by different criteria, like sender email address, originating server, subject substring or other things that might be available in the headers of each mail, which would allow dev teams to partition their view of the inbox. This would also be part of the url so one could bookmark their unique view to remove the other developer's messages.

Thanks!

Originally created by @wesyah234 on GitHub (Jan 16, 2024). Original GitHub issue: https://github.com/axllent/mailpit/issues/237 The use case is this: our development team shares a single instance of mailpit, but we each test different apps that are sending messages in, and when one developer goes in to view their messages, they'd rather not see messages from the other developer's testing efforts. Sometimes, if only one developer is needing to test at a given time, they can check with the others and then delete all the older messages, giving themselves a clean slate, but if 2 people are testing at the same time this is not possible. The idea would be to have a filter on the left side, that would dynamically group messages by different criteria, like sender email address, originating server, subject substring or other things that might be available in the headers of each mail, which would allow dev teams to partition their view of the inbox. This would also be part of the url so one could bookmark their unique view to remove the other developer's messages. Thanks!

kerem

2026-03-15 12:53:42 +03:00

closed this issue
added the
stale
label

kerem commented

2026-03-15 12:53:58 +03:00

Author

Owner

@axllent commented on GitHub (Jan 16, 2024):

Hi @wesyah234 . This sounds to me like something that can already be handled by existing tagging. You would either need to provide an X-Tags email header to auto-tag, or alternatively start your Mailpit instance with word/phrase matches defined.

Alternatively, you could just search for something specific (ie: the hostname) and bookmark the search URL.

Does this do what you need?

@axllent commented on GitHub (Jan 16, 2024): Hi @wesyah234 . This sounds to me like something that can already be handled by existing [tagging](https://mailpit.axllent.org/docs/usage/tagging/). You would either need to provide an `X-Tags` email header to auto-tag, or alternatively start your Mailpit instance with [word/phrase matches](https://mailpit.axllent.org/docs/usage/tagging/#wordphrase-matches) defined. Alternatively, you could just search for something specific (ie: the hostname) and bookmark the search URL. Does this do what you need?

kerem commented

2026-03-15 12:54:03 +03:00

Author

Owner

@wesyah234 commented on GitHub (Jan 16, 2024):

Wow, that's a cool feature, and I think it will definitely help us. I'll play with it a bit. I'll have to get my sysadmin to allow me to start and stop the instance to test things out with that --tag parameter but I think it might be useful for us.

Just trying out the basic search and then bookmark option. I had a few issues:

Can I do "OR" matching?
per this, Can I search ANY mail header? like (Received:) or just the ones listed (to,from,subject, etc)

Reason being: certain developers might have email coming from a certain server, identified by the Received: header, and this would be handy (along with OR capability) to be able to craft a search string specific for the messages that developer is interested in.

@wesyah234 commented on GitHub (Jan 16, 2024): Wow, that's a cool feature, and I think it will definitely help us. I'll play with it a bit. I'll have to get my sysadmin to allow me to start and stop the instance to test things out with that --tag parameter but I think it might be useful for us. Just trying out the basic search and then bookmark option. I had a few issues: 1. Can I do "OR" matching? 2. per [this](https://mailpit.axllent.org/docs/usage/search-filters/), Can I search ANY mail header? like (Received:) or just the ones listed (to,from,subject, etc) Reason being: certain developers might have email coming from a certain server, identified by the Received: header, and this would be handy (along with OR capability) to be able to craft a search string specific for the messages that developer is interested in.

kerem commented

2026-03-15 12:54:08 +03:00

Author

Owner

@axllent commented on GitHub (Jan 17, 2024):

Mailpit uses SQLite for storage, and whilst SQLite is perfect for this use (small, embedded and relatively fast), it's not advanced like some Gmail/Google database backend, so there are some limits.

There is no OR functionality (that becomes very complicated to parse and database-heavy to search) - there is only include ("search this") and exclude (!"exclude this" or -"exclude this"). You can however specify tags multiple times in the Mailpit startup flags (--tag 'host1="1.2.3.4" host1="2.3.4.5"') to handle your "OR" situation as you would then just filter by that tag (this is the solution you are probably after).
The search does not include all mail headers (there are just too many which would clutter the database and pollute search results) ~ those prefixes you see there are the only ones stored & indexed. The fulltext search (ie: not prefixed by to: etc) also includes Reply-To and Return-Path, but not hostnames etc

The "word/phrase matches" used in --tag is a 1:1 match on the entire message including headers, so provided you know the hostname then you can tag it as it arrives, and I believe this is the solution you are after.

There is one "catch" you should be aware of though - whilst Mailpit does live load new messages (websockets) as they arrive, this does not apply to filtered views, only the inbox itself. Searches are (in comparison to the inbox) very heavy and slow, so if the server and the browser had to calculate whether each arriving message matches a current search it would cause all sorts of issues. The search needs to be re-run to load new matching messages, or the tag clicked again (tags are effectively just searches, but are much faster to look up than a regular search). I may at some point add live loading to tag views, however I can foresee all kinds of complications and performance issues, so I don't think this will happen any time soon, it at all.

I hope this helps....

@axllent commented on GitHub (Jan 17, 2024): Mailpit uses SQLite for storage, and whilst SQLite is perfect for this use (small, embedded and relatively fast), it's not advanced like some Gmail/Google database backend, so there are some limits. 1. There is no OR functionality (that becomes very complicated to parse and database-heavy to search) - there is only include (`"search this"`) and exclude (`!"exclude this"` or `-"exclude this"`). You can however specify tags multiple times in the Mailpit startup flags (`--tag 'host1="1.2.3.4" host1="2.3.4.5"'`) to handle your "OR" situation as you would then just filter by that tag (this is the solution you are probably after). 2. The search does not include all mail headers (there are just too many which would clutter the database and pollute search results) ~ those prefixes you see there are the only ones stored & indexed. The fulltext search (ie: not prefixed by `to:` etc) also includes Reply-To and Return-Path, but not hostnames etc The "word/phrase matches" used in `--tag` is a 1:1 match on the entire message including headers, so provided you know the hostname then you can tag it as it arrives, and I believe this is the solution you are after. There is one "catch" you should be aware of though - whilst Mailpit does live load new messages (websockets) as they arrive, this does not apply to filtered views, only the inbox itself. Searches are (in comparison to the inbox) very heavy and slow, so if the server and the browser had to calculate whether each arriving message matches a current search it would cause all sorts of issues. The search needs to be re-run to load new matching messages, or the tag clicked again (tags are effectively just searches, but are much faster to look up than a regular search). I _may_ at some point add live loading to tag views, however I can foresee all kinds of complications and performance issues, so I don't think this will happen any time soon, it at all. I hope this helps....

kerem commented

2026-03-15 12:54:13 +03:00

Author

Owner

@wesyah234 commented on GitHub (Jan 17, 2024):

Thank you very much for the detailed explanation of how this all works!

The live loading of filtered views would be really nice but we can deal with hitting refresh on the browser.

Being able to search on any header would be nice as well but we can look at using --tag for this.

OR searching would also be nice in the UI but we can also look at using --tag for this.

Thanks again for the help.

@wesyah234 commented on GitHub (Jan 17, 2024): Thank you very much for the detailed explanation of how this all works! The live loading of filtered views would be really nice but we can deal with hitting refresh on the browser. Being able to search on any header would be nice as well but we can look at using --tag for this. OR searching would also be nice in the UI but we can also look at using --tag for this. Thanks again for the help.

kerem commented

2026-03-15 12:54:18 +03:00

Author

Owner

@wesyah234 commented on GitHub (Jan 17, 2024):

One more idea, maybe when you perform a search, it shows up on the left side like the tags do when you apply a tag. This would avoid the need to bookmark a search and be more consistent with the tag behavior.

@wesyah234 commented on GitHub (Jan 17, 2024): One more idea, maybe when you perform a search, it shows up on the left side like the tags do when you apply a tag. This would avoid the need to bookmark a search and be more consistent with the tag behavior.

kerem commented

2026-03-15 12:54:24 +03:00

Author

Owner

@axllent commented on GitHub (Jan 17, 2024):

I appreciate the ideas, but I believe this would be counterintuitive and not logical to the end user. Filtering by a tag is actually just the same as searching, except the tag is highlighted (active) in the side nav. So if I was to search for a tag and a particular word at the same time, with your logic both a tag would be highlighted as well as something else (eg "search results") which would only appear when searching.

I chose to follow the same UI logic as Gmail, and try to keep the UI as simple as possible.

To achieve what you are after (effectively a refresh of a search), you can just submit the search again as it is already filled in with what you are searching for.

@axllent commented on GitHub (Jan 17, 2024): I appreciate the ideas, but I believe this would be counterintuitive and not logical to the end user. Filtering by a tag is actually just the same as searching, except the tag is highlighted (active) in the side nav. So if I was to search for a tag and a particular word at the same time, with your logic both a tag would be highlighted as well as something else (eg "search results") which would only appear when searching. I chose to follow the same UI logic as Gmail, and try to keep the UI as simple as possible. To achieve what you are after (effectively a refresh of a search), you can just submit the search again as it is already filled in with what you are searching for.

kerem commented

2026-03-15 12:54:29 +03:00

Author

Owner

@wesyah234 commented on GitHub (Jan 18, 2024):

I'm just thinking of something like below. Just like every tag you add becomes a clickable quick action on the left, it would be helpful for every search you perform (maybe not "tag" based searches) also becomes a clickable quick action on the left.

@wesyah234 commented on GitHub (Jan 18, 2024): I'm just thinking of something like below. Just like every tag you add becomes a clickable quick action on the left, it would be helpful for every search you perform (maybe not "tag" based searches) also becomes a clickable quick action on the left. <img width="273" alt="image" src="https://github.com/axllent/mailpit/assets/66566/3596f04a-7ee1-45b3-aacb-0e9ccb6d7062">

kerem commented

2026-03-15 12:54:34 +03:00

Author

Owner

@axllent commented on GitHub (Jan 20, 2024):

Thank for the suggestion, but I do not think this is a feasible/good idea. The moment you start doing custom searches the search values can get very long, and there will be potentially a lot of them. This, together with the fact that one ultimately does a lot of searching without realising it, sometimes in combination with tags, I think it will clutter the UI for very little benefit.

What problem exactly are you trying to solve with your suggestion?

@axllent commented on GitHub (Jan 20, 2024): Thank for the suggestion, but I do not think this is a feasible/good idea. The moment you start doing custom searches the search values can get very long, and there will be potentially a lot of them. This, together with the fact that one ultimately does a lot of searching without realising it, sometimes in combination with tags, I think it will clutter the UI for very little benefit. What problem exactly are you trying to solve with your suggestion?

kerem commented

2026-03-15 12:54:39 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Feb 4, 2024):

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

@github-actions[bot] commented on GitHub (Feb 4, 2024): This issue is stale because it has been open for 14 days with no activity.

Rows
Columns

[GH-ISSUE #237] Feature request: grouping messages by various criteria (sender, originating server, etc) #154