Feature Request: support impersonation to access multiple mailboxes from the same user account

[acran]

Description

Accessing different mailboxes - especially via the webmailer - is currently a bit cumbersome since it requires completely logging out of mailu and logging back in again with another user account.

Instead there should be a simple way, e.g., an additional button in the user list - as a global admin or domain manager - to "open mailbox" of another user directly in the webmailer.

Motivation

Mailu being a perfectly suited tool for self-hosting your e-mails it is likely also used much for hosting personal e-mails and domains. Given the ease of creating new e-mail addresses it is also likely that one user has several different e-mail addresses. Using aliases these can then all be delivered to the same mailbox.
But in some cases it may make sense - or be preferred by the user - to also use separate mailboxes for the addresses. But accessing those mailboxes then also requires separate logins.

Further Motivation

Using an external authentication (exclusively) in such a case adds additional hurdles to this, because it then requires to also create and grant access to new user accounts in the external identity provider just to be able to login to mailu - although it is still only the same "user" accessing those mailboxes.

Possible solutions

This can be addressed in multiple stages - while all of the below should also only apply to users who could accessing the target mailboxes anyway by, e.g., resetting the account's password, i.e., global administrators or domain managers:

1. allow admins to manage auth-tokens of their users
   In the case of using an external authentication this would at least allow the admin to create a new auth-token in order to access the mailbox using any mail client (other than the webmailer).
   The complexity of implementing this should be quite low and mostly only require adapting the admin view.

2. allow admins to log into the webmailer as another user
   This would give an easy and convenient direct access to the mailbox. Implementing this should also be possible with few less invasive changes which should mostly be limited to verify_temp_token:

Mailu/core/admin/mailu/utils.py

Lines 502 to 511 in df5b48a

	# this is used by the webmail to authenticate IMAP/SMTP
	def verify_temp_token(email, token):
	try:
	if token.startswith('token-'):
	if sessid := app.session_store.get(token):
	session = MailuSession(sessid, app)
	if session.get('_user_id', '') == email:
	return True
	except:
	pass

3. implement a full impersonation feature
   This would allow the admin to access the whole mailu backend as the target user. If already having implemented 1. & 2. and given the existing access of admins this would the be a bit redundant probably. Also implementing this may require some more major refactoring? On the other hand it would make implementing 1./2. obsolete.

I could maybe have a try on implementing the chosen solution myself and submitting a PR given a green light by the mailu maintainers.

Possible future expansions and related issues

Thinking further I'd like to also throw in the following ideas - but purely for discussion and way out of scope for this feature request:

1. fine grained mailbox access and delegation
   Adding a finer grained access model to grant access to a user's mailbox to other users - without them being domain admins. This would enable to have a mailbox used as a kind of "shared mailbox" between multiple (non-admin) users. Also it would allow users to delegate access to their mailboxes, e.g., for a holiday substitution. Ideally for that users could manage the access to their mailbox themselves.

2. splitting the concepts of "users" and "mailboxes"
   Currently each user corresponds to a mailbox and vice versa. Splitting these to concepts would allow to create mailboxes without having to create a user with its own login credentials. On the other hand a user could be assigned multiple separate mailboxes - or even no mailboxes at all for users that should be send-only, see Add a checkbox to make rejecting all emails for a specific user easy #2846