Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• DraftEmailConfiguration

FreedomBox email server specification

Version: 0.1 by ?StevenChamberlain

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.

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.

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:

• A meaningful hostname such as wonderland.

• A domain name for the network where the local machine is located, such as example.com (this is obviously not so relevant any more for laptops and handheld devices that move around between networks all the time).

• Correct clock setting (ideally synchronised using NTP).

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:

• The machine wonderland needs to be reachable from the public Internet on TCP port 25, despite any router or firewall that is present.

• The MTA on wonderland must recognise the hostname and domain name in the email address (wonderland.example.com).

• The MTA might need to support SSL/TLS to receive email at all from certain email providers (should test this: gmail, web.de...? and must the certificate match the MX hostname, and be issued by a trusted CA too?)

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

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.

The FreedomBox email server specification

• requirements described at https://wiki.debian.org/FreedomBox/TODO/GSoC2021

• ideas from https://salsa.debian.org/freedombox-team/freedombox/-/issues/56

• ideas from https://github.com/mail-in-a-box or other free-software projects

• ideas from proprietary products (which may actually use free software, like cPanel/WHM does)

Challenges

• spam!
• password brute-forcing attacks
• reputation-based filtering, DKIM, SPF, and how to actually get email delivered to GMail, Microsoft, Yahoo! and other common third-party providers (and not land in the Junk folder)
• performance: on minimal hardware, how much RAM does the spam filter or virus checker or IMAP daemon consume? how fast can a message be received, scanned and delivered into a mailbox?
• scalability: would the configuration described here still be suitable with 500 users or more on one server?

• bounce spam, which might occur if received mail is forwarded on to another email address but isn't deliverable - this could be abused by spammers, which the FreedomBox owner is responsible for

Configuration

User accounts

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

• /etc/passwd

• an LDAP database (LMDB?)

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!)

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?

Domains

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

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

Aliases

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