Skip to content

02 Operate the Mail Server

Thilo Fromm edited this page May 4, 2023 · 7 revisions

User management: Add or delete users, create aliases

The container ships a few comfort scripts for adding and removing users. These scripts reside in the repo's main directory and call implementations inside the container. The counterparts inside the container reside in th repo's scripts/ directory and are added to the container at build time (see Dockerfile).

Add a new user

$ ./user.sh add [email protected]
Created user '[email protected]', generated password is:'0sw;eZxqh(M6mmjlnqu;'.

NOTE Password is within the single quotes ('). The single quotes are not part of the password.

Create users for any of the DOMAIN or ADDITIONAL_DOMAINS you've defined in the server settings. For the user's IMAP and SMTP access you can either supply a password or have the script auto-generate one. In the latter case the password is printed after the user has been generated.

To add user "meier" with password "12345" to domain "entropiesenke.de", run

$ ./user.sh add [email protected] 12345
Created user '[email protected]' with password provided.

Change a user's password

$ ./user.sh passwd [email protected] 23456
Updated password for user '[email protected]'.

List all users

$ ./user.sh list

Displays a list of all users and their inbox sizes.

Delete a user

$ ./user.sh del [email protected]
Deleted '[email protected]'.

This removes a user and prevents them from accessing the server. Optionally, the email inbox (all of the user's emails) can also be deleted. If the inbox is not deleted, the user can later be re-created (see add_user.sh) to re-enable access.

$ ./user.sh del --purge-inbox [email protected]
Deleted '[email protected]' and purged mail/inboxes/wombathub.de/[email protected].

Manage aliases

User aliases are maintained in _server_workspace_/etc/postfix/valias and can be edited directly.

The aliases file's structure is very simple. Each line defines one alias:

[alias-source-email] [alias-target-user]

While alias sources are complete email addresses - user@domain and all domains can be used, alias destinations are limited to user accounts on the mail server's main DOMAIN. Assuming DOMAIN=wombathub.de and ADDITIONAL_DOMAINS=entropiesenke.de, this example

sets up account [email protected] to also receive email for [email protected] and [email protected]. The account [email protected] must of course exist for this to work.

Update the aliases after changing _server_workspace_/etc/postfix/valias by running

$ ./user.sh update-aliases

Renew certificates

Letsencrypt will send an email notification to the postmaster address configured in settings.env, ADMIN@DOMAIN, prior to certificates expiring. To renew certificates, restart the mail server - renewals are performed automatically at each start.

Backup and restore

All state including configuration, mail user accounts, mailbox contents, and logfiles, resides in _server_workspace_.

  • For backup, simply create an archive of _server_workspace_.
    • _server_workspace_/etc has all service configuration, mail users, and passwords. It also contains DKIM keys.
    • _server_workspace_/mail has all mailboxes and sieve scripts.
    • If you use monitoring:
      • _server_workspace_/prometheus-data and _server_workspace_/prometheus-pushgateway hold all metrics collected by Prometheus.
      • _server_workspace_/var/lib/grafana/ has Grafana state.
  • For restore
    • create a fresh git clone of the mailserver repo, change into the mailserver repo's directory
    • unpack your archived backup to _server_workspace_
    • start the mailserver (either via systemd or via start_mailserver.sh).

Migrate existing mailboxes

If users have an existing mailbox in Maildir format, the mailbox contents can be migrated to an account on Mailserver. The steps below discuss migration to a new user; similar steps can be taken to merge a Maildir backup into the mailbox of an existing user.

  1. Create a new Mailserver user which we'll use as destination for the mailbox backup. The user does not need to have the same email address as for the mailbox we're restoring. <domain> can be any domain served by the Mailserver (either DOMAIN or one of ADDITIONAL_DOMAINS from settings.env).
    ./user.sh add <user>@<domain>
  2. In the mailbox backup delete all dovecot* files from Maildir/. This will cause Mailserver's dovecot to re-index after we've put the raw email files into the user'
  3. Create the user mailbox directory at _server_workspace_/mail/inboxes/<domain>/<user>@<domain>/. This directory won't exist if the user never logged in via IMAP.
  4. Copy the backup Maildir/ to _server_workspace_/mail/inboxes/<domain>/<user>@<domain>/. The destination _server_workspace_/mail/inboxes/<domain>/<user>@<domain>/Maildir/ should now contain standard maildir directories and files like cur/, new/, Sent/ etc. as well as all backed up emails.
  5. Change ownership of the mailbox directory _server_workspace_/mail/inboxes/<domain>/<user>@<domain>/ and all subdirectories recursively to 2001:root. This is the user ID of the in-container mailbox user and will allow dovecot to write to this directory.
  6. Log in with the new user account via IMAP to trigger dovecot to re-create the Maildir index files.

Migrate Sieve script

The easiest way to migrate a user's sieve script is to use a mail client which supports managesieve, connect to the mail server, create a new sieve filter in the mail client, and paste the user's sieve script there.

On the server, Mailserver sieve scripts are located at _server_workspace_/mail/inboxes/<domain>/<user>@<domain>/sieve. sieve can either be a file or a directory. There's a symlink _server_workspace_/mail/inboxes/<domain>/<user>@<domain>/.dovecot.sieve which determines which (or if any) sieve script is active - only one script can be active at a time. If sieve is a file, .dovecot.sieve usually just points to sieve. If sieve is a directory, .dovecot.sieve points to the active sieve script file in the directory.

For a server-side migration of an user's sieve scripts

  1. Create a directory _server_workspace_/mail/inboxes/<domain>/<user>@<domain>/sieve/ if it sies not exist.
  2. Create a file in sieve/, e.g. sieve/restored-filter, and put the user's sieve script into this file.
  3. Cerate a symbolic link .dovecot.sieve -> sieve/restored-filter
  4. Ensure all sieve files and directories are owned by user Id 2001