Following the move of my email provider from Ionos to Purelymail and fun with symbolic addressing I began to wonder if it would be possible run my commercial email service on the local ash server, in parallel to the hydrus email server. Not that I intend to do this; I would prefer to have someone else to blame if the CEO’s mail breaks.

Virtual Domains

The Exim4 documentation cites two meanings of virtual domains:

  • A domain for which there are no real mailboxes; all valid local parts are aliases for other email addresses. Common examples are organizational top-level domains and “vanity” domains.

  • One of a number of independent domains that are all handled by the same host, with mailboxes on that host, but where the mailbox owners do not necessarily have login accounts on that host.

It is the latter meaning that I want to explore.

The Exim4 documentation goes on to provide an example of how a virtual domain could be configured. Based on the description, this is what was configured.

The router

Based on the example, this is the router configuration for a virtual domain.

# Router for virtual domains
# Use of domain_data to avoid using tainted data
# Data is considered tainted if if comes from the mail

virtual_domains:
    driver = accept
    domains = dsearch;/etc/exim4/domains
    local_parts = wildlsearch;/etc/exim4/domains/$domain_data
    transport = virtual_mailboxes

It relies upon the existence of a file in the /etc/exim4/domains directory, named after the required virtual domain. The file is the same format as the /etc/aliases file, mapping valid email names to local users. Note the comment regarding tainted data. Using the _data suffix ensures that tainted data is not used directly.

So, a domain file for example.com say, could have the following contents:

user.alias:   user
^user\\W.*:   user

You’ll note the use of wildlsearch for looking up names in the domain file.

The configuration file was named 250_exim4-config_virtual_domain which means it is defined right after the primary configuration for sending mail and before routers for local delivery.

The transport

The configuration for the transport also closely follows the documentation example:

# Transport for virtual mail boxes
# Use of local_part_data to avoid complaints about "tainted data"
# Data is considered tainted if it comes from the mail

virtual_mailboxes:
    driver = appendfile
    file = /var/mail/${local_part_data}
    user = ${local_part_data}
    # group must be set to allow exim to write to user's mailbox
    group = mail

The transport directs the delivery to the users mailbox. In order to allow Exim4 to update the mailbox file, the group must be set.

Note that local_part_data is used to avoid taint.

Transports are not sensitive to the order of definition, so this transport configuration was place in a file called 30_exim4-config_virtual_mailboxes.

Authentication

Exim4

The virtual domain users need to be added to the /etc/exim4/passwd file, the format of which is described in the man page for exim4-config_files.

Dovecot

I use Dovecot’s passwd-file to authenticate users, rather than /etc/passwd. This allows the users of the domain to have their email address as the username.

Updating the system

The new Exim4 configuration template can be created and installed with the following commands:

sudo update-exim4.conf.template -r
sudo update-exim4.conf

Restart Exim4 with:

sudo systemctl restart exim4