MTA
Configuration
Webmail Messenger uses Postfix for the “Mail Transfer Agent” (MTA). The MTA is responsible for sending and receiving email. The “MTA configuration” page () 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).
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 ().
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.88will black-list all the IP addresses from192.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 ()
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 (, 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”.