MTA

Authorized recipients

If a Webmail user is allowed to send email to any recipient, the Webmail user can misuse the system by sending email to random recipients. It is therefore required to configure to which domains (or email addresses) a Webmail user is allowed to send email to.

The list of allowed domains (or email addresses) can be configured on the “Authorized recipients” page (Admin ‣ MTA ‣ Authorized recipients)

Typically the authorized recipients are set to all the domains handled by the gateway. By default the authorized recipients list is empty which mean that a webmail recipient cannot reply to any email.

Tip

If you only want to allow a Webmail user to send email to specfic email addresses, and not to all email addresses from a domain, only add the allowed email adddresses to the “Authorized recipients” list.

Configuration

Webmail Messenger 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.

MTA configuration

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).

In a typical setup with “Server mode” set to “Addon”, Webmail Messenger only needs to receive a special tunnel email from the gateway. The initial setup wizard adds the following domain to the relay domains: webmail.cipher.mail

Warning

It is advised to use the value configured by the initial setup wizard. Only change the “relay domains” if you have a good reason to do so.

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

Warning

Do not configure “Reject unverified recipient” unless you have a good reason to do so. Webmail Messenger does not need to validate recipients.

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”.

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.

Webmail relay host

The “Webmail relay host” is the default next-hop destination for delivery of email sent by webmail users. If left empty, email will be delivered using mx-records.

“Webmail relay host” can be an IP address or a domain name. If the option “mx” is checked, the MX-records of the “Webmail relay host” will be used instead of the A-records (this setting is only used if the “Webmail 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 Webmail Messenger 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 Webmail Messenger 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.0192.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:

  1. Open the “MTA lookup tables” page (Admin ‣ MTA ‣ Lookup tables)

  2. Click Add lookup table

  3. On “Add MTA lookup table” page set map type to “hash” and name to “tls-policy”.

  4. Add the following lines to the content field:

    example.com       encrypt
    
  5. Click Add

  6. Open the “MTA config file” page (Admin ‣ MTA ‣ Config, then click “MTA config file”)

  7. Add the following line to the Postfix main config:

    smtp_tls_policy_maps=hash://etc/postfix/maps.d/hash-tls-policy.map
    
  8. 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”.