MTA

Configuration

CipherMail gateway uses Postfix for the “Mail Transfer Agent” (MTA). The MTA is responsible for sending and receiving email. The “MTA configuration” page (Admin ‣ MTA ‣ Config) can be used to configure the most important Postfix settings. Postfix parameters which cannot be configured with the “MTA configuration” page can be configured with the “MTA config page”

Tip

The MTA configuration can also be configured by editing the Postfix configuration files from the command line.

The relevant Postfix settings will be explained in the following section. For a more thorough explanation of all the Postfix settings see the Postfix documentation (http://www.postfix.org/documentation.html).

Relay domains

The relay domains are the destination domains the MTA will accept email for (and subdomains if “Match Subdomains” is selected). These are normally the domains for which internal users have mailboxes.

Note

In a typical setup, at least one relay domain should be configured unless the gateway is only used for sending email and not receiving.

My Networks

A connecting SMTP server is only allowed to send email to external domains, i.e., to domains not listed as a relay domain, if the IP address of the sending SMTP server is added to “My Networks”. The networks added to “My Networks” should be specified in CIDR notation (for example 192.168.1.1/32 or 10.1.2.0/24).

Warning

Only add IP ranges you fully control to “My Networks”. If unknown IP ranges are added, the gateway will be an “open relay” and misused for sending spam. This might result in blacklisting your IP addresses.

My Hostname

“My Hostname” should be set to the fully qualified domain name of the email server. My hostname is used as the default value for many other configuration parameters. For example it is used as the default domain for email messages sent without a domain name. It is also used for the default SMTP Helo name.

Match subdomains

If set, sub domains of the relay domains are also accepted as a relay domain.

SMTP Helo Name

The “SMTP helo name” is the name the SMTP server reports when connecting to external SMTP servers. If “SMTP helo name” is not explicitly set, “My Hostname” will be used for the SMTP helo name.

Important

If the gateway directly delivers email to external recipients (i.e., not using an external relay host) it is important that the SMTP helo name of the gateway is equal to the reverse lookup of the external IP address. If the SMTP helo name is not equal to the reverse IP lookup of the external IP address, or reverse IP lookup is not configured (for example PTR records are missing), outgoing email might be flagged as spam by some mail servers.

Reject unverified recipient

If a mail server is setup to relay email for certain domains, the mail server should know which recipients will be accepted by the server it relays to, i.e., it should know for which email addresses valid inbox exists. If email for all email recipient addresses is accepted without knowing whether the next email server will accept the email, there is a risk of generating “backscatter”.

Note

Backscatter, occurs when an intermediate mail server accepts a message without checking whether the next mail server will accept the message. If the next mail server does not accept the email, the intermediate mail server must bounce the message back to the original sender because the mail server already accepted the message. If the email was sent by a spammer using a forged sender address, the message will be bounced back to the forged sender.

There are multiple options for a mail server to know which recipient addresses are valid and which are not. One option is to let the gateway server “learn” which recipient addresses are valid by querying the next mail server. If an email is received for a yet unknown recipient, the server checks with the next mail server whether the recipient is valid or not. The email will only be accepted if the next mail server reports that the recipient is valid. The result of this verification process will be cached for some time.

Unverified Recipient Reject Code

The verification procedure is activated by enabling “Reject unverified recipient”. The “Unverified Recipient Reject Code” is the SMTP result code used when the email is not accepted by the next mail server. This should initially be set to 450 which indicates that the error is a temporary error and that the connecting mail server should retry after some time. The “Unverified Recipient Reject Code” can be changed to 550 if the verification procedure works correctly. The SMTP result code 550 indicates that the error is a permanent error. The connecting mail server will stop retrying if the error code indicates that this is a permanent error. See the Postfix documentation for more information on address verification (http://www.postfix.org/ADDRESS_VERIFICATION_README.html).

External relay host

The “External relay host” is the default next-hop destination for delivery to domains not listed as relay domain. If left empty, email will be delivered using mx-records.

“External relay host” can be an IP address or a domain name. If the option “mx” is checked, the MX-records of the “External relay host” will be used instead of the A-records (this setting is only used if the “External relay host” is specified).

If the next-hop server requires authentication, SASL should be enabled for the next-hop server.

Internal relay host

The “Internal relay host” is the default next-hop destination for delivery to domains listed as relay domain. If left empty, email will be delivered using mx-records.

“Internal relay host” can be an IP address or a domain name. If the option “mx” is checked, the MX-records of the “Internal relay host” will be used instead of the A-records (this setting is only used if the “Internal relay host” is specified).

If the next-hop server requires authentication, SASL should be enabled for the next-hop server.

Before filter message size limit

The maximum size of a message (in bytes) that the MTA accepts. If a message exceeds the maximum size, the message is rejected.

After filter message size limit

The Mail Processing Agent (MPA) of the gateway is responsible for encryption, decryption and signing of email. The “After filter message size limit” is the maximum size the MTA accepts after the message has been handled by the MPA. The size of a message after encryption, decryption and signing can be larger than the size of the email before encryption, decryption or signing. The “After filter message size limit” should therefore be larger than the “Before filter message size limit” otherwise the MTA will not accept the email from the MPA.

A safe default is to set “After filter message size limit” at least twice as large as the “Before filter message size limit”.

MTA config file

Postfix has a large number of settings. The “MTA configuration” page only supports the most important Postfix settings. Settings not supported by the “MTA configuration” page, can be configured with the “MTA config file” page.

Important

Changes to the Postfix configuration file on the “MTA config file” page are not validated. Care must be taken when modifying the Postfix configuration directly. If the Postfix configuration is incorrect, the MTA might not function properly.

SASL

If the “External relay host” or “Internal relay host” requires authentication, a SASL account for that host should be added. SASL credentials for a host can be added on the “SASL passwords” page (Admin ‣ MTA ‣ SASL).

MTA Client access list 

The “MTA client access list providers” page contains a list of providers that support a dynamic IP lookup service. This is for example used when the CipherMail gateway should be configured as a relay host for Office 365 or G Suite. Because Office 365 or G Suite do not provide SMTP authentication, the “My Networks” setting should be populated with the Office 365 or G Suite IP ranges. The “Office 365 SMTP endpoints” and Gmail client access list providers will dynamically lookup the IP ranges used by Office 365 and G Suite.

For more information on how to setup the CipherMail gateway as a relay host for Office 365 or G Suite, see ???.

Email forwarding 

Under certain conditions, for example if the gateway runs out of disk space, local system services might sent email to the local system accounts (for example to the root user). Email for local system accounts should therefore be forwarded to the gateway administrator. On the “Email forwarding” page, email forwarding can be configured.

Important

Make sure the mailboxes to which the emails are forwarded to are periodically monitored for important system messages.

Header checks 

With header checks, each message header is matched against a list of defined patterns. If a pattern matches, the action for the pattern is executed. For matching and action syntax, see the Postfix header checks documentation (http://www.postfix.org/header_checks.5.html).

Example: the following rule will reject the email if the subject of the email starts with make money fast:

/^Subject: make money fast/     REJECT spam detected

RBL 

A Real-time Blackhole List (RBL) is a list of black-listed IP addresses published by a DNS server. The MTA dynamically checks whether an external client is black-listed by checking whether certain DNS records exist. The MTA rejects the request if the client IP address is listed in the DNS server.

An RBL entry should be specified as DNS-SERVER-HOST[=d.d.d.d]. Where the =d.d.d.d part is optional and depends on the RBL list whether is should be specified or not.

Static black-list

The static black-list contains a list of black-listed IP addresses. The difference between the static black-list and the RBL list is that the static black-list is a list of IP addresses which is manually updated by by the admin whereas an RBL list is dynamically formed by quering a remote DNS server. The static black-list option can be used if you need to black-list a specific IP address.

A range of IP addresses can be specified by leaving out the last octets from an IP address. An optional rejection reason can be specified. Example: your IP was black listed because it is sending spam.

Example: 192.168.88 will black-list all the IP addresses from 192.168.88.0 → 192.168.88.255.

Static white-list

The static white-list list contains IP addresses which should be allowed to connect even if the IP addresses are black-listed by an RBL.

MTA lookup tables 

Postfix uses map files for access control, address rewriting, content filtering etc. With the “MTA lookup tables” page, Postfix maps can be created from the GUI. The map can be used from the Postfix main config files (main.cf or master.cf) by referring to the filename of the map file.

The following map types are supported:

btree
cidr
hash
pcre
regexp

It depends on the Postfix setting which map type should be used.

Note

A lookup table will be created in the directory /etc/postfix/maps.d/. The filename extension of the generated map file depends on the “Map type”. The full filename of the loopup table will be /etc/postfix/maps.d/MAP-TYPE.NAME.map.

Example of a lookup table:

Suppose you want to make sure a connection to the domain example.com is protected with TLS, i.e., TLS for that domain should be mandatory. The Postfix setting “smtp_tls_policy_maps” can be used to setup the TLS policy for remote domains.

Use the following procedure to create an TLS SMTP client policy:

Open the “MTA lookup tables” page (Admin ‣ MTA ‣ Lookup tables)
Click Add lookup table
On “Add MTA lookup table” page set map type to “hash” and name to “tls-policy”.
Add the following lines to the content field:
```
example.com       encrypt
```
Click Add
Open the “MTA config file” page (Admin ‣ MTA ‣ Config, then click “MTA config file”)

Add the following line to the Postfix main config:

smtp_tls_policy_maps=hash://etc/postfix/maps.d/hash-tls-policy.map

Click Apply

Now all email sent to example.com will only be delivered if the receiving server supports TLS.

Note

For more advanced TLS policies see the Postfix documentation (http://www.postfix.org/TLS_README.html)

SMTP transports 

By default all email sent to external recipients, i.e., email addresses not matching any relay domain, will be delivered to the “External relay host” or if “External relay host” is not configured, to the server identified by the MX records for that domain. Email sent to one of the relay domains will be handled in a similar way, except it now uses “Internal relay host”.

By adding an SMTP transport, the next hop server can be explicitly overridden.

Example:

Suppose you want email to example.com to be delivered to the SMTP server with hostname alternative.com on port 2525. The default transport can be overridden by adding a new “SMTP transport” rule. Set “Domain or email address” to example.com, set “Relay Host” to alternative.com and port to 2525.

Tip

More advanced transport rules can be directly added by editing the “Transport config” directly (click the Transport config link). Any advanced transport rules not recognized by the parser will be shown under “Raw Line”.