Add support for separate mailboxes

[sajanlamsal]

Summary

Adds separate mailboxes: when SMTP authentication is enabled, each authenticated
username can be viewed as its own switchable mailbox in the web UI. Mailpit already
records the authenticated username on every message — this surfaces it as a first-class,
filterable view, with no database schema change.

Motivation

Several services can already share one Mailpit instance by authenticating with different
SMTP usernames, but there was no way to view mail grouped by service — everything landed
in one combined inbox. This lets you switch between per-service mailboxes.

What's included

Web UI

• A Mailbox dropdown in the sidebar listing each authenticated username, plus All mail.
• A dedicated /mailbox/<username> route/view with a clean URL and an empty search bar.
• The selected mailbox acts as a persistent scope: tags
  and searches apply within the current mailbox; opening a message and returning keeps
  the mailbox; live updates are filtered to the mailbox.

API / backend

• New username:<name> search filter (exact match; supports -username: exclusion),
  composable with existing filters (tag:, subject:, …).
• usernames array added to the /api/v1/messages and /api/v1/search responses
  (additive, mirrors tags); swagger.json updated.
• GET /mailbox/{username} serves the SPA so direct loads / reloads work.

No breaking changes

• Purely additive — the mailbox UI only appears once authenticated mail has been received.
• No schema change: reads the Username already stored in message metadata.
• Independent of --tags-username (username auto-tagging); the two can be used together.

Testing

• New Go tests: TestUsernameSearch and TestGetAllUsernames (run across all tenant modes).
• gofmt -s, go vet, the Go test suite, and npm run lint (eslint + prettier) all pass.
• Manually verified end-to-end: multiple SMTP users, switching mailboxes, tag/search
  composition within a mailbox, live updates, and message back-navigation.

Docs

Companion documentation PR: axllent/mailpit-website#26

[D-i-t-gh]

-1

Let's not overcomplicate things. One could just use multiple Mailpit instances.

[sajanlamsal]

-1

Let's not overcomplicate things. One could just use multiple Mailpit instances.

@D-i-t-gh
Thank your for your feedback,
I agree multiple instances absolutely work, and for a couple of static services that's probably the simpler setup.

The cases I had in mind where a single instance helps:

• One SMTP endpoint / config. Apps just vary the auth username; adding a
  service is a credential line rather than another port, container, and config
  to manage. That adds up in docker-compose or CI setups.
• Unified view. "All mail" plus per-service switching and cross-service
  search in one UI, instead of N separate instances/tabs.
• Many or ephemeral services. Microservice setups where standing up an
  instance per service is a lot of overhead.

That said, it's entirely your call whether that's worth the extra surface area.
It's designed to be fully opt-in (nothing changes unless SMTP auth is
configured), but I completely understand if it's more than you want to carry —
happy close it if it doesn't fit Mailpit's direction.

[axllent]

@sajanlamsal Thanks for your contribution. Given the size of this PR, and the fact that it appears to be completely AI-generated (please confirm), I will need some time to assess it and decide whether it aligns with Mailpit's goals and existing functionality. I briefly glanced through the code and found some untested & theoretical holes in the logic, but I don't want to speculate until I can actually review it properly - for while I need dedicated time given the about of code and the potential impact of any structural change.

[sajanlamsal]

@axllent

Thank you for taking the time for the comment and quick walk through.
I understand the amount of review effort necessary on this change.

To answer your question directly:
yes, This was built with significant help from Claude Code.
I managed the design and direction and tested it thoroughly at each stage instead of generating it in one go.

However, most of the code (Frontend Part), tests, and documentation were written by AI.
I should have pointed that out in the PR earlier.
My apologies. 🙏

Also regarding your concern for the gaps, I would very much appreciate your specfiics whenever you have the chance.
I'm happy to address any issues you find, and follow Mailpit's direction.

Thank you for engaging with it thoughtfully.