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
