John Doe administers a Kolab Enterprise installation, but the complete environment for what we’ll call “example.com” involves server systems hosted by third parties — such as a web server for the corporate website, and maybe other application servers.

This article outlines the possible solutions to one or more of these environments being restricted somehow.

A Restricted Kolab Environment

A Kolab environment could be hosted on a consumer-grade Internet connection, such as one may have at home or in a small office (SOHO), that may or may not incur any of the following parameters causing restrictions;

• A dynamic IP address, potentially causing Anti-Spam measures on receiving mail servers to not accept messages.
• An ISP that prevents outbound connections on port 25, or worse, intercepts connections outbound on port 25.
• Flimsy router hardware/software that does not facilitate DNSSEC or TCP DNS queries.

In such scenarios, the Kolab environment could be configured to use an external server to relay mail messages, using submission and authentication. It should then be the remote server that connects to receiving mail servers.

This article does not include the configuration of the external server to be configured. However, the section “Configuring Postfix” does apply to Kolab environments as well.

A Restricted Web- or Application Server

A web- or application server could be configured on a per-application basis, for as far as individual applications allow such configuration (such as WordPress with the WP Mail SMTP extension might), or the local MTA could be used to relay all mail messages.

Individual applications should be configured not unlike other generic desktop clients using Kolab’s submission service — using authentication that corresponds to the specific email address of the specific application.

Application servers that use a static IP address exclusive to that server/tenant (i.e. is not behind source network address translation) can simply be configured with a relayhost setting, and its address(es) added to the receiving server’s mynetworks.

But suppose it is the application servers that have dynamic IP addresses or are prohibited from using port 25 securely, and no individual application can be configured to use Kolab’s submission service.

In such cases, the MTA can be configured to use authentication against a Kolab submission service.

Configuring Postfix

Create a file /etc/postfix/relay-credentials and ensure the permissions are restrictive. Example contents are as follows;

smtp.example.com someone@example.com:password

Create a hash db mail from this file:

# postmap /etc/postfix/relay-credentials

Add the following configuration to /etc/postfix/main.cf:

relayhost = [smtp.example.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/relay-credentials
smtp_sasl_security_options =
smtp_tls_security_level = encrypt

Finally, restart the Postfix service:

# systemctl restart postfix

NOTE: The account for which the credentials are used must be allowed to use the sender address used in the emails. For example, if the credentials used are for webmaster@example.com, and mails are sent out using an envelope sender address of noreply@example.com, then webmaster@example.com must have been allowed to send email using the noreply@example.com sender address (using an alias or through delegation).