11. Multi-tenancy
A typical MTA just takes responsible to receive and send emails for just one domain.
However, s/qmail features with its predecessor Qmail virtual domains and is capable to process on a single host millions of emails per day; thus can be used even for large email providers (ISP).
Depending on the technical and commercial negotiations with the customers, the ISP requires to respect and to enforce certain in particular security settings for those. s/qmail supports this providing the concept of multi-tenancy based on the domain of the customer; both while receiving (qmail-smtpd) and sending the emails (qmail-remote).
In particular, the following settings are subject of multi-tenancy:
- IP addresses (either IPv4 or IPv6)
- Authentication (userid and password)
- X.509 client certificate
- User data base (email accounts)
- TLS security settings + level
Within s/qmail those settings can be customized and individually provided per responsible domain, while the emails for different domains facilitate the the queue and partially the same modules.
11.1 qmail-smtpd
11.2 Multi-tenancy of qmail-remote
Apart from QMTP/QMTP, Auth, and TLS support, s/qmail's qmail-remote implementation differs differs from its predecessors by means of its multi-tenancy capabilities.
Multi-tenancy means, that the delivery channel and behavior depends on the sendings domain taken from the Rcpt To: information.
Remember, that s/qmail/ is an Mail Transfer Agent including a Mail Delivery Agent. In a usual case, qmail-remote acts irrespectively of the sendings domain; but this may be subject of customization.
The following control files support multi-tenancy:
- authsenders
- domainips
- domaincerts
- smtproutes (indirectly)
Multi-tenancy means, that qmail-remote can be set up to provide per sending domain the following (connection) information:
- The local IP address it uses (providing, several IP addresses are available as displayed by ipmeprint).
- the EHLO greeting,
- the identity for the specified domain,
- the TLS requirements, and perhaps
- the presented per sending domain (user) certificates.
While the capability of multi-tenancy is provided in any of those control files, the concept shall be discussed for domainips and smtproutes.
11.2.1 Binding qmail-remote to distinct IP addresses per sending domain
In case you use s/qmail to host and support different (virtual) domains, it might be necessary to use in particular a dedicated IP address for sending emails, which are unique per domain, even running just one instance of s/qmail.
control/domainips allows you to specify for qmail-remote:
The first line is the classical case: Mails to send for 'example.com' are send via IPv6 on the specified address and the EHLO greeting is now provided as mail.example.com. The second line shows a particular scenario: Mails from 'security.com' are send using the IPv6 Link Local Unicast address fe80::ee01 which makes only sense, if the recipient host resides on the same network segment and perhaps invokes additional scanning prior of delivering the email to the purported recipient. The third case advices qmail-remote to bind for all other domains to one particular available IP address.
Note: qmail-remote respects the individual domain labels, separated by dots.
Within s/qmail's ./bin directory you will find the program ipmeprint which will show you all available IP addresses qmail-remote can bind to:
Note: This is a sample for my server with the fixed bug [20170630#1/3.3.6].
11.2.1 qmail-remote Authentication per sending domains
While qmail-remote provides authentication by means of the smtproutes control file, the original approach was sender based, employing authsenders:
Now, qmail-remote will authenticate while delivering mails for '@example.com' thru the gateway 'relay.example.com' with the given identity 'user' and 'passwd'. This scheme can be extended to individual sender addresses 'info@example.com' or to default to all delivery attempts and forwarding all emails to 'mailrelay.example.com'.
Since the password is provided in cleartext form, care has to be taken, that permissions of this control files are suited not to leak these sensible data.