9. Remote Delivery and Mail Forwarding

Once a SMTP address is inserted in s/qmail's remote queue, the message (residing in mess) is scheduled for remote delivery. qmail-rspawn picks up those addresses and calls qmail-remote to finally transmit the message to the responsible MX host, in case SMTP is used as transport protocol.

Unlike other MTAs/MDAs, s/qmail (by means of qmail-rspawn) follows the principal

which means, qmail-remote does not do delivery pipelining for the same message and recipients for the very same MX, though it is enabled to do so. This behaviour may be changed in the forthcoming releases.

9.1 Features of qmail-remote

qmail-remote is a 'versatile' remote Mail Delivery Agent and is enabled to support the following delivery protocols:

• ESMTP on port 25 together with STARTTLS (see ...) and Auth capabilities (see ...)
• Submission on port 587 (see ...)
• ESMTPS on port 465 together with Auth support.
• Respecting the MTAs SIZE announcement (RFC 1870).
• Binding to particular outgoing IP addresses.
• QMTP on port 209.
• QMTPS on port 6209 providing TLS encryption and Auth capabilities using X.509 client certificates.

qmail-remote brings multi-tenancy support to s/qmail based on the sender-domain.

9.2 qmail-remote's SMTP default delivery

qmail-remote provides full support of (E)SMTP, except for announcing the SIZE of the email upon sending. qmail-remote includes a parser recognizing the server's (E)SMTP command list and in particular acting upon

• STARTTLS
• AUTH [login, plain, cram]

issued by the server.

On the other hand, qmail-remote may include in the 'Mail From:' reply

• AUTH=userid (as 'xtext')
• SMTPUTF8

qmail-remote's EHLO greeting depends on the content of the control files

1. me (default)
2. helohost -- perhaps with additional information
3. smtproutes -- per sending domain (see below; multi-tenancy)

SMTP connection to a remote host is facilitated by qmail-remote according the the received MX value from DNS. The received information on the connections are used in this order, until a SMTP connection is established. Thus, a blocked port 25 on a particular MX host or IP address does not inhibit a final successful SMTP transmission.

qmail-remote provides two mechanisms to cope with potentially mis-behaving SMTP server hosts by means of the control files:

• timeoutconnect: This is the time to wait for SYN from the server, which defaults to 60 seconds.
• timeoutremote: The time to wait for a SMTP response from the server; by default 1200 seconds.

In practice, there is no need to change the defaults, except for extrem tarpitting hosts, where the timeoutremote limit needs to be increased.

9.3 qmail-remote's SMTP manual routing delivery

The usual MX lookup for the recipient domain can be overrules by means of particular SMTP routes, telling to which host qmail-remote has to connect to, given a certain recipient domain. The control file smtproutes instructs qmail-remote to which and how to connect to providing the touple domain:relay.

In the first case, .af.mil (but not af.mil itself) is routed by its MX records; any other address is artificially routed to heaven.af.mil. In the second case, any other address is directed to cloud7.af.mil on port 465 (SMTPS). The third case tells qmail-remote to route traffic for inside.af.mil to the particular host firewall.af.mil on the dedicated port 26.

The sample tells, that more specific (domain) addresses have precedence over generic once; thus a fine-tuned delivery concept may be constructed.

Notes: Within smtproutes hostnames (FQDN) have to be supplied because the provided information is subject of a DNS lookup. Port numbers are separated by means of a semi-colon ';'.

9.4 QMTP delivery of qmail-remote

Apart from SMTP tranmission, qmail-remote can be advised to rather user QMTP/QMTPS for delivery to a peer host. Apart from s/qmail, both qmail and Postfix support QMTP, while the secure QMTPS (equivalent roughly with SMTPS) as a feature of s/qmail only.

QMTP/QMTPS delivery have precedence over SMTP/SMTPS. Thus, setting up the control file qmtproutes will take use of this delivery mechanism (irrespectively of the port).

A typical qmtproutes control file follows the syntax of smtproutes:

In the first case, the entire (remote) mail traffic is routed to the host qmtphost.af.mil; while the second instruction tells to forward mail for security.af.mil over the same host; but now using QMTPS.

Notes: For QMTP/QMTPS no MX DNS lookup is facilitated; thus this delivery scheme can be used among peers only.

9.5 qmail-remote's IP source address

Under certain circumstances you want qmail-remote to connect the remote MTA 'differently' using a dedicated IP address and not the primary. There are two cases to consider:

1. Multi-tenancy: qmail-remote acts differently according to the sending domain. This is discussed in chapter 11.
2. In a casual case, you need to specify a seperate IP address for a given destination host. This can be facilitated by means of control/smtproutes.

Setting up a specific loacalip by means of smtproutes is accomplished given a IPv6 LLU address by the following:

fe80::1%eth0 specifies the outgoing IPv6 address including the network interface name. This address is not route-able. However, if you setup a particular NAT address table you can re-write this address to any IP you need. Of course, specifying an IPv4 or IPv6 route-able address is also possible; but these are standard cases.

9.6 Authentication of qmail-remote

qmail-remote's authentication mechanisms are explained in chapter 5.

9.7 Transport Layer Security with qmail-remote

qmail-remote acts as client regarding even a TLS connection. The client has the ability, to actually chose the specific TLS features, the server is providing. The control file tlsdestinations provides this kind of fine-granulated settings.

On the other and, the server may require from qmail-remote to present a X.509 certificate (and of course to posses a key file. These settings are subject of the control file domaincerts which again makes use of the multi-tenancy features of qmail-remote.

9.7.1 Defining tlsdestinations for qmail-remote

The way, qmail-remote uses TLS security for a remote host is subject of the control file tlsdestinations. In fact, one can advice qmail-remote

1. to omit TLS security for a particular host/domain; for instance if this is ill-behaving,
2. to optionally use a fine-grained level of TLS security for a particular host/domain, or
3. to require TLS security (on a particular level) or otherwise not to to deliver mail for that domain/to this host.

For general use, the control file tlsdestinations can be as simple as that:

This says: Do TLS as best as you can with any target host!

However, depending on your requirements, tlsdestinations may be quite complicated, while providing an interface to the lower layer OpennSSL or LibreSSL security functions, fortunately providing the same API.

Server Authentication

Before going into details, we may recap, which kind of TLS connections are possible; either based on Diffie/Hellman (DHI) or RSA key exchange (KEX) and - we now focus on that - server authentication:

1. Given DH KEX, the key material can be anonymously exchanged; thus no server authentication is required. Often this is called 'Anonymous Diffie-Hellman' ADH.
2. The exchanged key material can be digitally signed by the server. This is only possible, if the server posses both a X.509 certificate and a corresponding private key, actually used for signing.
3. The X.509 certificate of the server may be issued by a CA and signed by it. Now, once we have the root-cert of the CA, we can verify the authentication of the X.509 certificate offered by the server.

Currently, qmail-remote does support all those mechanism, but neither uses an Certificate Revocation List CRL nor the possibility to check the X.509 server certification by means of the Online Certificate Status Protocol OCSP.

TLS Primitives (Cipher Suite)

TLS is a protocol constantly under pressure. Weak features may be removed, new features are hyped, until it is proven, that those are weak again. The cryptographic primitives which are used for a TLS connection are summarized in the Cipher Suite. One concept of TLS is, that the server has to promote his capabilities, and the client can chose one of those.

qmail-remote allows to pin-point the Cipher Suite by means of the 'Mod_SSL' API.

tlsdestinations (control file)

For qmail-remote the control file tlsdestinations bundels all the TLS settings which are given for any remote server. We may distinguish among 'unspecified' and 'distinguished' destinations.

A) Regarding 'unspecified' destinations, the following settings are possible:

Thus, it is possible to actually 'trim' the evaluation for any destination:

1. A single character before the colon (:) is the most generic form; even not demanding a X.509 certificate (anonymous KEX).
2. Double characters require a TLS connection and potentially do a a validation upon the received X.509 certificate.

B) Regarding specific domains, it is not only possible to require a TLS connection, but additionally to provide additional verification parameters:

Note: Within s/qmail's script directory a small program is available to determine the fingerprint of a given X.509 certificate.

C) Cipher Suite pinpointing is possible for all cases and is entered as first parameter following the pipe '|'. However, be aware, that either a too restricted Cipher Suite will inhibit the TLS connection and in particular, the current expression of the Cipher Suite needs to be matched against the current OpenSSL/LibreSSL implementation.

D) Special and general cases are given as follows:

In general, once port 465 is used in any control file (like authsenders or smtproutes) SMTPS is used; in case 6209 is specified, QMTPS will be tried.

9.7.2 Automatic TLSA checks of qmail-remote

qmail-remote is instructed to do an automatic DNS lookups for the recipient domain's MTA (given per MX lookup and A/AAA) as defined in RFC 6689 known as TLSA or DANE (DNS-Based Authentication of Named Entities). Here qmail-remote does not do a DNSSEC based TLSA verification, but rather trusts the received DNS information from a (potential validating) cache resolver.

The idea the following:

• Whenever a SMTP (or QMTP) connection is made, a DNS lookup is faciliated to check for a DANE record.
• If given, the DANE records include (mostly) the fingerprint of the X.509 certificate used for the TLS connection.
• The fingerprint in the DNS and the one received in the TLS handshake are compared.
• In case they match, the result is displayed in qmail-remote log; if not, a warning is given (in the logs) and the sending of the email is deferred until finally bounced.

This happens completely automatic and no particular customization is required. However, there may be cases, when the match does go wrong (erroneously) and should be avoided. Therefore, the following settings in qmail-remote's control file tlsdestinations are provided using the '/' prefix:

Thus, TLSA lookups can be disabled (per 'slash' prefix) for global settings or for particular domains (not MTAs!). In case no TLSa record is received, TLS continues as usal.

It should be noted, that TLSA records indicate via Usage their scope and policy:

• 0 PKIX-TA: The X.509 certificate is 'public' and the remote MTA sends the entire X.509 certificate chain (Trust Anchor). qmail-remote will performe verification based on the received information automatically.
• 1 PKIX-EE: The X.509 certificate is 'public' and the remote MTA sends only his own cert; assuming a valid trust store for qmail-remote. This needs to be provided within control/tlsdestinations.
• 2 DANE-TA: The X.509 certificate is 'self-signed' and the entire certificate chain is transmitted in the TLS handshake. qmail-remote will only perform fingerprint checks on the MTA cert. Additionally, the trust store shall be made available by means of tlsdestinations.
• 3 DANE-EE: End point self-signed X.509 certificate given. qmail-remote will perform fingerprint checks on the MTA cert.

In case of RFC 822 email, only 'DANE-' types shall be used according to RFC 78xx. The other given DANE cases Selector and Matching Type are automatically handled by qmail-remote.

9.8 Setting up domaincerts for qmail-remote

Once in a while, a MTA (as server) may ask qmail-remote to present a X.509 certificate for authentication purpose. This happens only, if both parties are within the same administrative domain. Since qmail-remote provides multi-tenancy support, this problem can be solved by means of the control file domaincerts:

In any case, qmail-remote needs to have access to its X.509 certificate and the corresponding keyfile (for a particular sending domain), which might be password protected. Alternatively, the certificate (in PEM format) includes the keyfile (and needs to be available unprotected). This information is comparable with the authsender approach, thus careful protection of in particular keyfile and password (within the control file) is necessary.

Once qmail-remote sends an email from 'example.com' (to the respective MX host), it is prepared to present the required X.509 certificate. The server is responsible to verify those informations.

However, it is also possible, that the server posses a general (public) certificate to be used for all deliveries. This can be accomplished simply providing the asterics symbol '*' before the colon.

Note: Providing the certificate to the peer is an option for qmail-remote and needs to triggered by a Certificate Request from the server. The X.509 certificate has to usually to match the sender's domain or the FQDN of qmail-remote.

9.9 Bounce forwarding with qmail-remote

Though with s/qmail's Recipient extension less likely for double-bounces, bounces may hit the system for wrong spelled or none-existing (recipient) email addresses. Bounces can be re-directed to particular s/qmail instances or other MTAs for further processing.

Either by means of SMTP oder with QMTP (given the control files smtproutes and qmtproutes, bounces can be forwarded with the following syntax in either of those files providing the bounce host and port:

9.10 SMTPUTF8 support of qmail-remote

s/qmail is 8-bit clean and thus supports UTF8 characters out-of-the box. qmail-remote recognizes UTF8 emails and is capable to support Punycode email addresses, given 'libidn2' is used upon compilation and linking.

qmail-remote respects UTF8 emails and forwards those labeled as 'Mail From: <XXX> SMTPUTF8' under the following circumstances:

1. The sender's or recipient's email address ('Mail From:', 'Rcpt To:') contains UTF8 characters.
2. qmail-smtpd has received the email flagged as SMTPUTF8.

• [FEHCom]
• [Impressum]
• [News]
• [top]