This document is a draft specification of work that would be done for the FreedomBox Email Server sub-project as part of the GSoC2021.

FreedomBox email server specification

Version: 0.1 by ?StevenChamberlain

1. Introduction

This document shall describe good practices for configuring an email server using free software. This was intended for implementation on the FreedomBox but should also be useful for anyone who wants to set up their own email server using only free software.

1.1. Target audience

Most users of FreedomBox should not need to read or understand this document, because FreedomBox shall be already preconfigured with the configuration described here.

System administrators who want to migrate an existing email server to FreedomBox, or even away from FreedomBox to some other system, should find this document helpful. Likewise for developers, who want to write software tools to ease migration to/from FreedomBox email server easier, integrate with FreedomBox, or further develop FreedomBox itself.

1.2. Basic email configuration

A typical GNU/Linux system has a mail transfer agent (MTA) already preinstalled. Traditionally, this was important to be able to receive automatic notifications of problems from system software (such as cron when it executes background maintenance tasks, or mdadm or smartd when problems are detected with a disk drive).

mdadm and smartd send email notifications of disk problems to root@localhost by default. The configuration file /etc/aliases describes which local (or perhaps remote) user should receive those emails.

Today, on a desktop computer, some notifications are now embedded into the graphical user interface, without using email at all. For example, Ubuntu's Kerneloops and Apport alert the logged-in user of problems with the kernel or running applications and allow to automatically send bug reports to developers.

Apart from local mail delivery, it is common (on a network of many computers) that emails be aggregated on another server. Instead of a providing a local address in /etc/aliases, the administrator can provide an email address such as alice@example.com which resides on some centralised email server. That way, Alice (the network administrator) could receive notifications of problems with any workstation on the local network. For this to work correctly, some additional configuration on the local machine is important:

Also, it should be possible for user alice to write an email using console commands such as mail or sendmail, and if the local MTA supports it, the email will be relayed over the local network or Internet to its final destination. Then she can send emails to anyone, without having an account on GMail, Yahoo! or with any other third-party provider.

Other users besides Alice might have an account on the machine wonderland. If someone sends an email from the public Internet to bob@wonderland.example.com, it may be desirable that this email reaches the mailbox bob on the machine wonderland. For that to work correctly, the following is also necessary:

In the Debian operating system, it is discuss regularly which MTA should be installed by default. See Debate/DefaultMTA and the table below:

MTA

Local mail

Outgoing via smarthost

Outgoing to Internet

Incoming from Internet

nullmailer

(./)

(./)

{X}

{X}

msmtp

(./)

(./)

{X}

{X}

ssmtp

{X}

(./)

{X}

{X}

exim

(./)

(./)

(./)

(./)

postfix

(./)

(./)

(./)

(./)

On a FreedomBox, it is desirable that the administrator can receive and read automatic email notifications that might indicate problems. Users should be able to send emails to the public Internet, or to other FreedomBox users, without relying on a third-party email provider. And the users should also be able to receive emails sent to the FreedomBox from the public Internet.

2. The FreedomBox email server specification

The specification itself is proposed to be complete by the end of the Community Bonding Period (until June 7, 2021) and then amended based on experiences gained during implementation. Below are some ideas of what it should contain.

2.1. Challenges

2.2. Configuration

2.2.1. User accounts

The user accounts database on a FreedomBox exists in two places:

Files have the obvious advantage that they can be directly edited with a text editor, tracked in version control, ...

LDAP can be queried over a network (this may be useful for testing!)

2.2.2. Location of mailboxes

/var/mail/$USER is where users' mailboxes are traditionally stored.

Is /home/$USER/.maildir or /home/$USER/mail perhaps better? if /home resides on different storage media than /? or if quotas are to be used on /home? or maybe it makes backups easier?

2.2.3. Domains

A FreedomBox typically has only one domain name assigned to it.

(But then, what about Tor .onion addresses...?)

2.2.4. Aliases

should aliases be managed in /etc/aliases or elsewhere?