Switch to Better Email-Technology

SWITCH TO BETTER EMAIL-TECHNOLOGY

Installation • Installation 10 • System Requirements 10 • OS 10 • Hardware 10 • Network 11 • Preparing the installation 11 • Webmaster Installation 11 • Worker Installation (on web host) 11 • Worker Installation (remote) 11 • Web/Database master setup 12 • Worker 12

Domains • Domains 13 • Add new domain 13 • Next Hop 13 • Recipient Verfcation 14 Mail Rules • Mail Rules 15 • Adding Mail Rules 15 • Lookup Order 17 • Connect 17 • Host connected over IPv6 17 • Host connected over IPv4 17 • IP address has a rDNS entry that can be forward confrmed (FCrDNS) 18 • HELO 18 • From 19 • To 19 • Body 20 • Subkeys 20 • ACL 20 • Pattern Lists 21 • TLS 22 • Concurrent Connection Limits 22 • Connection Rate Limits 22 • Greylist TTL 23 • Null Sender Rate Limits 23 • Message Rate Limits 24 • Message Size Limits 24 • Relay 25 • Blind Carbon Copy 25 • No List Traffic 25 Reporting • Reporting 27 • Logs 27 • Log Search 27 • Cluster 28 • License 28

Administration • Administration 30 • Resellers 30 • Hierarchies 30 • Domain Aliases 30 • Add a new Reseller 31 • Companies 31 • Add a new Company 31 • Users 31 • Add a new User 32

Confguration

Mail Core 34 • Mail Core Confguration 34 • Listen on ports 34 • Other ports 34 • Administrative Contacts 34 • Maximum Message Size 34 • SMTP Greeting 34 • Inactivity Timeout 35 • HAProxy Hosts 35 • TLS Private Key 35 • TLS Public Key 35 Pre-Data 36 • Pre-DATA Checks 36 • Early Talkers 36 • Delay 36 • DNS Lists 36 • Use FSL DNS Lists 36 • DNS Blacklists 36 • DNS Whitelists 37 • Domain Blacklists 37 • URI Blacklists 37 • rDNS 38 • Require rDNS 38 • Reject generic rDNS 38 • Reject invalid rDNS domains 38 • EHLO/HELO 38 • Require valid hostname 39 • Reject hosts that send mismatched HELO 39 • Reject bare IP addresses 39 • Reject mismatched IP literals 39 • Reject dynamic 39 • Bounce Messages 39 • Single recipient only 40 • Enable backscatterer DNSBL list 40 • Reject all 40 • Sender Policy Framework (SPF) 41 • Enabled 41 • Sender Authentication 41 • Skip rDNS/HELO rejections 41 • Greylisting 41 • Time 42 • Fail TTL 42 • Pass TTL 42 • Miscellaneous 42 • Single domain per session 42 Clickwhitelisting 43 • Click Whitelisting 43 • Enabled 43 • Secret 43 • Private Key 43 • Public Key 43 • Initial TTL 43 • Whitelist TTL 44 Outbound/Relaying 45 • Address Book 45 • Enabled 45 Post-Data 46 • Post-DATA Checks 46 • Watermarking 46 • Enabled 46 • Secret 46 • Expiry Time 46 • Reject Bounces without watermark 46 • Bounce Messages 47 • Check each received hop with SPF 47 • DSPAM 47 • Training 48 • Enabled 49 • Host 49 • Server Password 49 • Training Level 49 • Reject Level 49 • Enable Auto Training 49 • Auto Training Level 50 • SpamAssassin 50 • Enabled 50 • Host 50 • Reject Score 50 • Relay Reject Score 51 • MessageSniffer 51 • Enabled 51 • License ID 52 • Authentication 52 • Miscellaneous/Experimental 52 • Reject unreplyable messages 52 • Non-Latin character limit 52 Antivirus 54 • Anti-Virus 54 • ClamAV 54 • Enabled 54 • Hosts 54 • Reject Broken Executables 54 • Reject Encrypted Archives 54 • Enable PUA Signatures 55 • Packed 55 • PwTool 55 • NetTool 55 • P2P 55 • IRC 55 • RAT 55 • Tool 55 • Spy 56 • Server 56 • Script 56 • Enable DLP Signatures 56 • Reject OLE2 Macros 56 • Enable Google SafeBrowsing Signatures 56 • Enable Phishing Signatures 56 • Enable UNOFFICIAL Signatures 56 • Exclude List 56 • AVG AntiVirus 57 • Enabled 57 • ESET Mail Security 57 • Enabled 57 Attachments 58 • Filename Rules 58 • Archive Filename Rules 58 • Archive File Extensions 58 • Maximum Archive Depth 58 • MIME-Type Rules 59 Alerts 60 • Alerts From 60 • Alerts To 60 HAProxy 61 • Example HAProxy Confguration 61 Shared Cache 62 • Secret 62 • Port 62 • Unicast Hosts 62 • Multicast IP 62 • Multicast TTL 62 Mail Server 63 • Mail Server Confguration 63 • Microsoft Exchange 2003 63 • Microsoft Exchange 2007 63 • Microsoft Exchange 2010 63 • Microsoft Exchange 2013/2016 64 • Office 365 64 • Google Apps 66 • Zimbra 66 Reports 68 • User Reports 68 • Admin Reports 68

Miscellaneous

Hostname 70 • Changing Hostnames/ IP addresses 70 • Change IP Address 70 • Standalone TUXMAIL Server 70 • Master node 70 • Worker/Slave node 70 • Changing the Hostname 71 Data Import 73 • Backup File Import 73 DMX Migration 74 • Migrating from DefenderMX 74 • Exporting DMX Data 74 • Import DMX Data during Installation 74 10 Installation

Installation

System Requirements

TUXMAIL can be installed on a single server, but it is highly recommended to have at least two systems for redundancy and a dedicated server that runs the web interface (and databases) for best performance.

If you are sending a lot of outbound or relay traffic for a lot of domains and other SMTP servers (e.g. using TUXMAIL for SMTP AUTH or as a smart host), then it is highly recommended that you dedicate one or more servers to outbound traffic only and not to mix it with the inbound service. This is to prevent inbound and outbound services adversely affecting each other should there be any abnormal traffic levels.

A minimal installation of Redhat Enterprise Linux 7 (https://access.redhat.com/products/redhat-enterprise-linux) or CentOS 7 (https://www.centos.org) with all updates applied is required.

Hardware

The recommended system specifcation is:

• Intel Xeon CPU with minimum 2 cores or better • min. 8GB RAM for the Web/Database master (due to the ElasticSearch (https:// www.elastic.co/elasticsearch/) requirements) • 2GB RAM per Core for additional Workers • min. 32 GB HDD

In case of running both Web master and a Worker instance on the same host 16GB RAM are recommended.

A minimal Red Hat Enterprise Linux or CentOS installation with TUXMAIL uses around 3GB disk space, but a minimum of 32GB, all on one large partition, is recommended for a small system since the system uses space for logging, temporary fles, etc.. The database role will take approximately 5GB of disk space per million SMTP transactions logged.

We recommend to ensure the following:

• installation on machines at network edge within DMZ without any ‘helpers’ or ALG (Application Level Gateways) enabled on frewall (such as Cisco SMTP/ESMTP inspection, PIX fxup protocol or any other form of SMTP Proxy) • application must speak directly to the host originating the message and see its external IP (the only exception to this being if a HAProxy is used for SMTP traffic)

Preparing the installation

Before starting the installation verify that

• frewalld is enabled and running • the system hostname is set-up correctly (if not, run the command: hostnamectl set- hostname ) • a static IP address is set • at least 2GB swap space is available • all ports are open between the Web/Database master host and each worker host (the installer will correctly re-confgure and secure frewalld during its fnal step) • the root user on each worker host must be able to ssh to the Web/Database master host using a userid that can sudo to root. • the hosts all have an active internet connection

Webmaster Installation

1) download the TUXMAIL YUM repository fle 2) copy the .repo fle into the /etc/yum.repos.d/ directory on the webmaster host 3) run yum clean all and yum install tuxmail-web

Worker Installation (on web host)

In order to install a worker on the same host as the webmaster, simply run yum install tuxmail-worker tuxmail-worker-sync on the webmaster host.

Worker Installation (remote)

In order to install a worker on a remote host:

1) ensure a working ssh-connection to your webhost 2) run ssh root@ "tux_add_cluster_node `hostname` "|bash

After the Web/Database master has been installed successfully, the following steps are needed to complete setup:

1) Navigate to https://your-web-master-host-ip (or the appropriate DNS entry) using a browser (we recommend using the latest version of Firefox or Chrome) 2) Accept SSL exception 3) Optional step: import a backup fle (more Information here (/misc/data_import.md)) 4) Import your license file by either uploading the .json or copy-pasting its contents into the appropriate text feld 5) Create an initial Superadmin user by flling out the form

You can now login using the created initial credentials.

Once you’re done with your TUXMAIL setup, you should remove any hosts from your MX records that do not run TUXMAIL (e.g. backup MXs) as they will adversely affect fltering performance. Alternatively you can stop the SMTP services on any of these hosts and only start them in a DR scenario.

Worker

During worker installation, the following steps are being performed automatically:

• copy the SSH key from the master Web/Databese host, enables passwordless access to any of the cluster nodes • allows access through the frewall to the host • copies the tuxmail.repo fle to the host • starts the installation of ‘tuxmail-worker’ automatically which automatically creates a replica of the master node

Installation may take a few minutes to complete as virus and spam definitions are downloaded for the frst time to ensure everything is completely up-to-date. Once the installation is complete, your system is ready to scan emails.

Domains

Here you configure the Domains that you want to handle inbound mail for. Any inbound mail to recipients not in the domains listed here will be rejected by TUXMAIL. The domains are displayed in alphabetical order and show the next hop, disabled checkbox and the creation date, last update and the options to edit or delete the domain.

Add new domain

Enter the domain name in the input box provided. The disabled checkbox allows the administrator to disable reception of mail for a domain temporarily. This will defer all recipients to the domain, which means that any mail will be queued on the sending system, it is likely that the senders will get a warning that their message is queued after 4 hours and the mail will eventually be bounced back to them as undeliverable after 5 days (these are the RFC defaults).

Next Hop

Mail for this domain will be delivered to the specified host(s) specified here. You may add as many hops as desired by clicking the ‘Add another next-hop’ button. If the first next-hop server does not respond, then the subsequent next-hop is tried until the last is reached, at that point the message is queued and retried again later.

Field Description Host/IP IP address or Hostname of the destination server

Port TCP port number to connect to the host, default: 25 (if left empty)

allows reordering the hosts as the lowest priority next-hop will be Weight selected frst (optional)

Username and SMTP AUTH credentials to send to the host before message delivery Password

TLS specify whether TLS to be used opportunistically, required or disabled

See the Mail Server Configuration section for instructions on how these systems should be confgured to work correctly with TUXMAIL.

TUXMAIL will always attempt to verify each recipient as it is very important that messages are only accepted for email addresses that are valid on the backend mail server as it wastes computing resources and can cause Backscatter spam to be generated.

To do this is it performs a dummy SMTP transaction by connecting to the specified hosts and sends the recipient along with a dummy recipient to test whether the host is able to reject invalid recipients (or has a catch-all).

If a host is found to accept invalid recipients, a cache record is created and no further recipient verification is performed until this cache record expires after 24 hours at which point the host will be retested and a new cache entry created if it is still not capable.

As recipient verification is a common task, a connection pool is used so that multiple recipients can be verifed down the same connection without the need to reconnect each time. By default the pool connection is kept open for 5 minutes and a maximum of 10 pooled connections are allowed at any time. Once a recipient is verified the result is cached for 1 hour and invalid recipients are cached for 5 minutes but the cache entry is only used if there is no pooled connection available. This is done to provide the most accurate answer possible and to maintain the connection pool.

By default the recipients are checked with the Next Hop servers. Using the ‘Lookup Method’ drop-down, you can select ‘SMTP’ and configure a different SMTP server(s) to be used for recipient verifcation. You can specify multiple hosts by delimiting them with a comma, space or semicolon.

Mail Rules

Mail Rules are key/value lookup tables that TUXMAIL uses to implement nearly all of its functionality.

At each stage of an SMTP transaction, lookups are made by key into the mail rules and the results of these lookups are stored and used by TUXMAIL to implement various parts of its functionality.

Each lookup key prefixes the stage that it is looked up at e.g. connect, helo, from, to and body along with the item being looked up e.g an IP address, host/domain name or email address. The lookup item is then stripped by logical piece from most specific to least specific, piece by piece and looked up again until the lookup is empty.

Note

The lookup keys are always lowercase, but the values are case-sensitive, so they must be entered as shown

Adding Mail Rules

The GUI offers a guided interface allowing creation of new mail rules.

The frst step consists of creating a new mapping using one or a combination of lookup keys:

After creating a new Mail Rule, one or multiple subkeys can be defned:

Already defined subkeys belonging to a mail rule can be edited inside the same view or inside the listing table:

In case multiple subkeys have to be edited, the previous edit view can be accessed using the Edit ( ) action.

Lookup Order

Connect

These lookup the IP address and the rDNS hostname if it is available and it can be forward confrmed (FCrDNS). The FCrDNS requirement is to prevent spoofng.

Host connected over IPv6

Lookups start with the fully expanded IPv6 address and then strip one octet from the right until there are no more octets left. connect:ip:ip:ip:ip:ip:ip:ip:ip connect:ip:ip:ip:ip:ip:ip:ip connect:ip:ip:ip:ip:ip:ip connect:ip:ip:ip:ip:ip connect:ip:ip:ip:ip connect:ip:ip:ip connect:ip:ip connect:ip

Host connected over IPv4

The lookups start with the full IPv4 address and then strip one octet from the right until there are no more octets left:

IP address has a rDNS entry that can be forward confrmed (FCrDNS)

The lookups start with the full hostname and then strip the left-most label but leaving the leading dot, so to only match subdomains of that label. connect: fcrdns.host.sub.sub.domain.tld connect:.host.sub.sub.domain.tld connect:.sub.sub.domain.tld connect:.sub.domain.tld connect:.domain.tld connect:.tld

Last lookup is always blank and is used for defaults connect:

HELO

These lookup the HELO or EHLO argument.

If the HELO or EHLO contains a hostname or domain label, it is stripped in the same way as connect: The lookups start with the full hostname and then strip the left-most label, leaving the leading dot helo:host.sub.sub.domain.tld helo:.sub.sub.domain.tld helo:.sub.domain.tld helo:.domain.tld helo:.tld

If an IPv4 literal is sent, then it is not stripped helo:[ip.ip.ip.ip]

If an IPv6 literal is sent, then it is not stripped helo:[ip:ip:ip:ip:ip:ip:ip:ip]

The last lookup is always blank and is used for defaults.

These lookup the MAIL FROM argument e.g. the envelope sender or envelope-from address.

This is where it starts to get more complicated because TUXMAIL will combine each connect: lookup (except the bare connect: lookup) with each from: lookup as shown below (we call these combo tags) with an additional connect: lookup added at the top of the connect: lookup list.

These are: connect:__auth__

OR connect:__noauth__

Where __auth__ is used when the IP address has passed Sender Authentication and __noauth__ when not. This is very useful when whitelisting or blacklisting based on the sender or sender domain.

Once each combination has been looked-up, the 'bare' from: lookups are made. from:[email protected] (only if + addressing is used) from:[email protected] from:user+detail@ (only if + addressing is used) from:user@ from:<> (only if sender is null) from:host.sub.sub.domain.tld from:.sub.sub.domain.tld from:.sub.domain.tld from:.domain.tld from:.tld from:

These lookup the RCPT TO argument e.g. the envelope recipient or envelope-to address.

As with the from: lookups above each connect: lookup (except the bare connect: lookup) will be combined with each to: lookup as shown below, once that is complete the same thing is done with the from: lookups and then fnally the ‘bare’ to: lookups are made as below: to:[email protected] (only if + addressing is used) to:[email protected] to:user+detail@ (only if + addressing is used) to:user@

Body

Body lookups are made for each URI found within a message and are used to blacklist or to skip the URI DNS lookups (Domain Blacklists and URI Blacklists) for specifc domains.

Note

body: lookups do not include implicit sub-domain lookups, so body:tuxguard.com would match tuxguard.com and all sub-domains of tuxguard.com

Subkeys

ACL

Access Control Lists (ACL) are used for whitelisting, blacklisting and other administrative functions such as deferring or discarding messages based on their connection attributes. ACL are implemented using the acl sub-key in the Maps and can be used at any stage of the SMTP transaction: connect, helo, from, to, body and can return the following values:

Important

These values are case-sensitive!

Note

body: keys may only return OK (skip the URI lookup) or REJECT (reject the message), all other values are ignored.

Value Description Skip Skip any further ACL lookups

OK Whitelist through all checks except Anti-Virus and Attachment checks

CONTENT Whitelist through all pre-DATA checks

AUTH SPF- Same as OK, except it is only applied if the sending host can be authenticated PASS against the domain it is sending from (Sender Authentication)

Value Description Blacklist. Deferred until each recipient is known so that other whitelist entires REJECT can be applied frst (such as recipient whitelists). You can optionally specify a custom rejection message using REJECT:"custom message"

Instant Blacklist. An SMTP rejection is immediately returned. You can optionally specify a custom rejection message using IREJECT:"custom message". IREJECT Subsequent lookups that may return a whitelist result are not run, so use with care.

Defer with an SMTP temporary failure message. Deferred until each recipeint is TEMPFAIL known so that other whitelist entries can be applied frst. You can optionally specify a custom rejection message using TEMPFAIL:"custom message".

Instant Defer. An SMTP temporary failure is immediately returned. You can ITEMPFAIL optionally specify a custom rejection message using ITEMPFAIL:"custom message"

Prevent all checks except Anti-Virus and Attachment checks from running and DISCARD pretend to accept the message, but throw it away. Use with extreme caution!

Pattern Lists

You can also use Pattern Lists where more fne grained control is required. Pattern lists return one of two results, one where the pattern list matches and a default value if it does not

The format used for this is .

The following pattern lists are supported in ACLs:

• RegExp: Regular expression with forward slashes as delimiters, e.g. /regexp to match/OK REJECT • Simple: Simple wildcard match with exclamation marks as delimiters. Supported wildcards are ? (match single character) or * (match any character), e.g. !*match*!OK REJECT • CIDR: CIDR match. This is only used for connect: lookups that match an IP address. Delimiters are square brackets. As the key lookups do not allow for classless addressing, you must use a key that matches a class that is larger than the CIDR you are trying to match, e.g.: connect:10.100 acl [10.100.1.0/20]OK REJECT

If an ACL matches, a message header X-Haraka-AccessMap: is inserted into the message which shows the matching mail rule key.

TLS

Using the mail rules, you can enforce TLS and require it for certain connections, domains or recipients or you can prevent the STARTTLS extension from being advertised to specific hosts should they have a bad confguration that prevents TLS from being negotiated.

Using the map sub-key tls you can apply the following values:

Value Description SKIP Do not advertise TLS

REQUIRE Require TLS. Message will be rejected if the session is not encrypted

Require TLS and require the certifcate to pass verifcation. The message will be VERIFY rejected otherwise

Concurrent Connection Limits

Using the mail rule subkey concurrent you can implement concurrent connection limits with the value being the number of concurrent connections allowed per IP address. If the value is <= 0, then the limit is disabled for any connection that matches the key.

Note

Only connect: mail rules are checked for concurrency limits. Once the concurrency limit is reached, any subsequent connections will be tar-pitted for 30 seconds before being deferred with the message “concurrent connection limit (\) exceeded”.

Note

The concurrency limit is counted and applied per TUXMAIL worker and is not cluster-wide.

To disable Concurrent Connection Limits set the concurrent sub key to -1.

Connection Rate Limits

Using the subkey rate you can apply connection rate limits with the value being the number of connections allowed per minute, per IP address.

Note

Only connect: mail rules are checked for connection rate limits.

Once the connection rate limit is reached, any subsequent connections will be tarpitted for 30 seconds before being deferred with the message “connection rate limit exceeded”.

To disable Connection Rate Limits listing set the rate subkey to -1.

Greylist TTL

Using the subkey grey you can override the default greylist TTL by host or by destination domain.

To disable grey listing set the grey subkey to -1.

Note

Only connect: and to: map entries are checked.

Null Sender Rate Limits

Using the subkey null-rate you can configure a rate limit for messages with a null sender (Bounce messages). The value is specified as number of messages with an optional time period and metric. e.g. 5/1d (5 messages in one day).

If the time period is not supplied, then it defaults to 60 seconds and if the metric is not supplied then it defaults to seconds. The following metrics are allowed:

ValueDescription s Seconds (default)

m Minutes

h Hours

d Days

w Weeks

Note

Only to: mail rules are checked for null sender rate limits.

If the specified rate is exceeded, then all further recipients are deferred by sending an SMTP temporary error, which means the sending server will queue the message and retry it again periodically. This facility does not reject messages, it delays them to manage the rate of messages.

Using the subkey msg-limit you can confgure a message rate limit. The value is specified as number of recipients with an optional time period and metric. e.g. 5/1d (5 recipients in one day). If the time period is not supplied, then it defaults to 60 seconds and if the metric is not supplied then it defaults to seconds. The following metrics are allowed (not case-sensitive): (same as Null Sender Rate Limits).

You may use to:, from: and connect: mail rules, but note that they are looked up in this order (e.g. to, from, connect) which is the reverse of things like ACLs. Additionally, the mail rule type denotes where the limit is applied: e.g. to: = recipient, from: = sender, connect: = host IP address.

For example: to:[email protected] msg-limit 5/1d

This would limit the recipient [email protected] to a maximum of 5 messages per day whereas connect: msg-limit 300/1d would set the default limit for each unique IP address to a maximum of 300 valid recipients per day. You could then use more specifc mail rules to raise or lower the limit.

Message Size Limits

Using the subkey length you can configure custom message size limits up to the Maximum Message Size. The value is the maximum size with an optional metric which defaults to bytes if not specifed.

The following metrics are allowed (not case-sensitive): k (Kilobytes), m (Megabytes), g (Gigabytes)

Note

If you supply an invalid metric, an error will be written to the syslog and no limit will be applied.

All key types except body: are supported although the size limits are checked in reverse order (e.g. to, from, connect) as that is the most specifc order in this case.

If a message exceeds the confgured size limit, then the message is rejected with the message: message size of bytes exceeds limit of bytes

Note

In ESMTP, the sender can report the message size before the message data is sent. However, some servers cannot do this and in these cases the limit must be applied after the message is received. In this case and if the message has multiple recipients, then any recipient limits are only looked up if all recipients have a common domain name, otherwise they are skipped entirely

Relay

Using the subkey relay, you can allow specifc hosts relay permissions. Only the connect: map entries are looked up (so it has to match an IP address or confirmed rDNS name).

The value of the lookup can be either true or strict, where strict only allows a host to send email with an envelope-from domain matching any domain that you have defined in ‘Domains’. This is to prevent a hacked account or internal machine from sending mail that is not from one of your local domains.

Blind Carbon Copy

Using the subkey bcc, you can force TUXMAIL to add additional recipients to a message when a key matches. The value should be a list of recipients separated by comma, space or semicolon. Two variables are available, $1 will be expanded to the local part and $2 the host/domain part

TODO: example

No List Traffic

This is enabled on a per-recipient basis by creating an ACL for the recipient with the subkey no_list_traffic with a value of true or strict to enable a stricter mode (described below). It will only work on map entries with a to: match.

When enabled, this looks for messages from mailing lists to recipients that either never send mail out directly (e.g. shared mailboxes, role accounts and the like) or that should otherwise never receive bulk mailing list traffic as you will not subscribe them to any lists.

It is most useful for "role" mailboxes like info@ or support@ and can prevent a considerable amount of junk whilst still allowing person-to-person e-mail.

It looks for the following:

• Messages to a single recipient only • Envelope From matching noreply@ or bounce@ • Envelope From a VERP address (e.g. the from address contains the recipient address) • A List-Unsubscribe, List-ID or X-Requests-To header • A Precedence header of list • A blank, missing or undisclosed-recipients To: header • An X-Mailer header of ‘PHPMailer’ • The To: or Cc: header does not contain the envelope recipient address • The To: or Cc: header contains more than 11 recipients. • The From: address does not match the Envelope-From strict mode adds additional text checks of the body of the message:

• An HTML anchor that contains /u/ in the URL • The text “This is an advertisement” • unsub, unsubscribe, remove or removeme followed by a period (.) to catch any HTML links containing this in the URL • Text to the effect of: “reply to this message with the subject of N” and variants • Text to the effect of: “prevent further messages” and variants • The text “do not reply to this” followed by “mail” or “message” • Text to the effect of: “this is an auto-generated message” and variants • The text “Unsubscribe” • The text “If you no longer wish to receive” • Text to the effect of: “You can opt-out by” and variants • Text to the effect of: “You are receiving this newsletter because” and variants

If any of these conditions is met, then the message will be rejected with the message “This recipient does not accept messages from mailing lists”

Reporting

Logs

The logs page shows the last 50 transactions in descending time order. If a row is highlighted in Red, the transaction was rejected, in Yellow, the transaction was deferred and no highlighting means the message was accepted.

Note

Connections that do not create a transaction are not recorded. This means they must at least reach the SMTP MAIL command. This is to prevent hosts hitting rate-limits or IREJECT blacklist entries from flling the logs display. You can still fnd these in the UNIX syslog on each worker in /var/log/maillog.

The number of transactions found and the number of pages is also shown, previous and next page buttons are shown allowing you to page through the results.

You can click on a result to take you to the message detail. This will show all the detailed information for the message, who it was sent by, if it used transport layer security, who it was sent to and where the message was delivered to for each recipient along with the headerinformation Sender, From, Reply-To, Subject, Message ID, Size and the overall status. If the message contained any attachments, then each is displayed along with their type and an md5 hash which allows you to check each with an online service like VirusTotal. You can also view all of the message headers and see all of the detailed test results.

Log Search

The search input box can be used to search for messages and offers a search engine style free- text lookup where the input is broken into terms (a term is a single word).

All search terms are treated as optional, as long as one term matches a result will be returned. Multiple words can be treated as a single term that must appear in the same order by surrounding them with double-quotes. You can prefix a search term with + to specify the term must be present and - to specify that it must not be present. Wildcards can be used within a term, ? to replace a single character or * to replace zero or more characters. You can use AND, OR and NOT and you can group terms and operators together using parentheses. Quote terms in parenthesis to search as a single term that must appear in the same order.

You can prefix the field name in front of any search term e.g. field:term to limit the result to only where the search term matches a given feld. Without a feld prefx, terms are checked automatically across all of the following felds:

Attribute Field Name Notes To match all of the transaction in a single connection, Transaction ID uuid replace the .\ at the end of the UUID with a * (e.g. \*)

IP address remote_ip

rDNS Hostname remote_host

Sender Address sender

Sender Domain sender_domain

Recipient rcpt

Recipient rcpt_domain Domain

Sender Header h_sender Address

From Header h_from Address

Reply-To Header h_replyto Address

This feld includes the \<>'s surrounding the message ID Message-ID mid so you must enclose the wholte Message ID in quotes e.g. Header ""

Cluster

The cluster page shows all of the active worker nodes in a TUXMAIL cluster. The graph shows the number of connections for each cluster member over the last 7 days. You can use the slider to increase or decrease the time displayed on the graph.

The table underneath the graph shows each node and provided the SMTP service is running it will display the key metrics for that node. CPU, Memory, Swap, Disk and Inode usage are shown.

The data on this page is updated automatically every 10 seconds

License

The license page allows you to apply a new license or view the current license, which shows the maximum number of domains permitted, the license type and which machines the software is licensed to and when the license expires. After installing a new TUXMAIL license you must restart the tuxmail-web.service for the new license to be read.

Administration

Resellers

TUXMAIL provides two ways to organize and manage very large, complex email installations, Hierarchies and Domain Aliases.

Hierarchies

Hierarchies allow you to organize and safeguard access to data groupings in TUXMAIL to authorized individuals. You can create groupings where Domains can be grouped into Companies and Companies can be grouped into Resellers.

For example:

• The MX Domains zebras.zoo.com, owls.zoo.com and birds.zoo.com can be grouped into the Company Zoos • The MX Domains rockcreek.parks.com, central.parks.com and yosemite.parks.com be grouped into the Company Parks • The MX Domains barbados.resorts.com, aruba.resorts.com and puertorico.resorts.com be grouped into the Company Resorts

And the Companies Zoos, Parks and Resorts can be organized into the Reseller Recreations.

You can then create roles that allow specific users access configure or view only specific parts of Hierarchies such as:

• A Domain Administrator for Zoos can modify any Domain in the Company Zoos • A Help Desk user for the domains in the Company Parks can view data for any Domain in Parks • A System Administrator for all units in the reseller Resorts can modify any Domain in Resorts • A Domain Administrator for the Domain birds.zoo.com can modify the confguration of birds.zoo.com

Domain Aliases

Domain Aliases allow you to organize the configuration of Domains into to similar groupings For example creating owls.zoo.com and birds.zoo.com as Domain Alias of zebras.zoo.com means that any change made to the configuration of zebras.zoo.com will also be applied to owls.zoo.com and birds.zoo.com.

And if you were to create the new domain hippos.zoo.com as a Domain Alias of zebras.zoo.com, it would inherit the same configuration as that of zebras.zoo.com and any future configuration changes made to zebras.zoo.com would be applied to hippos.zoo.com.

Note that Domain Aliases are created when you use the Domain -> Add New Domain menu to create a new domain that should be based on an existing actual Domain.

Add a new Reseller

Simply Fill in a descriptive unique Name for the Reseller Then fill in as much information as you require in the rest of the text boxes.

Then Add the record. You will now be able to create the Roles for: - Reseller Administrators users - Reseller Help Desk users

Companies

Companies allow you to organize, limit and access Domain data such as message logs message details, reports and traffic statistics in TUXMAIL to authorized individuals. Creating a Company and assigning Domains to that company will allow you to create Roles for: % TODO: missing??

Add a new Company

Simply Fill in a descriptive unique Name for the Company and select the Reseller that the company is assigned to.

Then fll in as much information as you require in the rest of the text boxes.

Then save the record. You will now be able to create the Roles for: - Company Administrators users - Company Help Desk users

Users

TUXMAIL allows you to create Local users who can administer and view the records for the TUXMAIL resellers, Companies and domains. Local users are defined a manually created logins for specific individuals who can manage and view all or only specific units of your TUXMAIL cluster.

There are seven type of Administrator logins:

• Super Administrators are allowed to create, view and change any confgurations or records in your TUXMAIL confguration. • Reseller Administrators are allowed to create, view and change any confgurations or records in Reseller groupings you have created.

• Reseller Helpdesk Administrators are allowed to view and any confgurations or records in Reseller groupings you have created. • Company Administrators are allowed to create, view and change any confgurations or records in Company groupings you have created. • Company Helpdesk Administrators are allowed to view and any confgurations or records in Company groupings you have created.

Add a new User

Fill in a descriptive unique login Name for the user.

Then:

1. Fill in as much information as you require in the rest of the text boxes. 2. Select the User Type from the pull down menu list 3. Select the Domain or Company the User should be able from the pull down menu list

Confguration

Mail Core Confguration

Listen on ports

The checkboxes specify which TCP ports that TUXMAIL should listen on. Port 25 must be enabled if you want to receive external e-mail.

Port 587 is used for SMTP Submission and requires that anyone using that port use TLS (STARTTLS) and SMTP Authentication before they are allowed to send messages. It is typically enabled if you want to allow email clients (MUA) like Outlook or Thunderbird, for example to use TUXMAIL as a relay server

Other ports

This allows for a comma separated list of other TCP ports to listen on. Typically, this would be used if you needed to support clients who cannot connect on port 25 or 587 (e.g. because the ports are blocked by their ISP or corporate frewalls).

Port 465 (SMTPS) has a special meaning and if specified will use SSL encryption, but this requires a SSL/TLS certifcate to be specifed in the TLS Public/Private Key options below.

Administrative Contacts

This is a comma separated list of email addresses that should receive administrative messages from any of the TUXMAIL systems. This means that any email directed to postmaster, abuse, security, noc or root sent to the hostname of the TUXMAIL machine and will include any messages from any of the TUXMAIL cron jobs will be sent to all of the contacts specified here. If the list is blank, then any of these messages are rejected with the message ‘No administrative contact confgured’.

Maximum Message Size

This specifies the maximum allowable message size globally. You may specify lower limits per host, sender or recipient using the Maps. If a message exceeds this size then the message is rejected with ‘Message too big!’

SMTP Greeting

This allows you to specify a custom SMTP banner message which is sent when a host initially connects to TUXMAIL. The default banner looks like this:

220 mx1.fsl.com ESMTP TUXMAIL 2.6.1 ready (A42B3586-E9EA-438A-A25A-B69CC1A34301)

The hostname, ESMTP and the Session ID (shown in brackets) are always sent on the first line as the hostname and ESMTP are required in the SMTP protocol and the Session ID aids debugging.

Inactivity Timeout

The maximum idle time of a connection (e.g. where no data is sent) before the connection is forcefully closed with a ‘421 timeout’ message. The default is 300 seconds (5 minutes), it should not be set to less than 60 seconds

HAProxy Hosts

A comma separated list of IP addresses or CIDR masks of hosts that should be allowed to use the HAProxy PROXY protocol extensions. See the HAProxy section for more details.

TLS Private Key

The TLS private key in PEM format to be used for both incoming and outgoing SMTP connections. Important: As this is global for all SMTP listeners in a cluster, it should be a wildcard certifcate.

A self-signed wildcard certificate can be used provided you do not have any email clients (MUAs) using port 587 as they will display a certifcate warning

TLS Public Key

This Text Box should contain TLS Public key in PEM format that goes with the Private key specified above. Any intermediate certificates should be placed in reverse order below the public key.

Important

If you have a hostname specific certificate do not use the TLS Private Key or the TLS Public Key text boxes. You will need to copy the contents of the TLS Private key to the /etc/haraka/config/tls_key.pem on the Master/DB server and copy of The Public Key followed any intermediate certificates in reverse order to the contents of /etc/ haraka/config/tls_cert.pem on the Master/DB server

Pre-DATA Checks

Pre-DATA checks are tests that run before the message body and headers are seen. These tests are important as they save considerable computing resources so provide better scalabilityand can save considerable bandwidth.

Early Talkers

Early Talkers are hosts that send data before the SMTP banner is sent or send data before aresponse to the previous command has been sent where this is not permitted by the SMTPprotocol.

Delay

To catch early talkers at the banner requires a small delay to give enough time for the data to be received. The default is 500 milliseconds, you shouldn’t set this to 30000ms (30 seconds) asmany hosts will not wait that long.

DNS Lists

These use DNS lookups to see if an IP address or Domain name is listed. The result from a DNS list lookup must be in the 127.0.0.0/8 range except for 127.0.0.1 otherwise the result is ignored and the list disabled from further queries.

If a list returns a lookup timeout then the listis automatically disabled and retested every 5 minutes to see if it is working again to prevent the lookups from adversely affecting performance.

Use FSL DNS Lists

This requires a yearly subscription and configures the options below to query all of the Fort Systems provided DNS lists

DNS Blacklists

Looks up the connecting IP address on the specified lists and rejects the message if the host is listed. The recommended lists to use here are:

• zen.spamhaus.org • bl.spamcop.net • b.barracudacentral.org

Note

zen.spamhaus.org is not free for commercial use, you must pay for a feed or the query service if you wish to use it for an extended period.

DNS Whitelists

Looks up the connecting IP address on the specified lists and whitelists the message through all pre-DATA tests only, post-DATA content checks are still run and the message can still be rejected.

The recommended list to use here: list.dnswl.org.

Note

DNSWL is not free for commercial use, you must pay for a feed if you wish to use it for an extended period.

Domain Blacklists

Looks up the full domain name of any rDNS names, HELO domain, envelope from domain, Message-ID header domain or any domains found within the message body and rejects the message if the domain is listed.

The recommended lists to use here:

• dbl.spamhaus.org • fresh.spameatingmonkey.net

Note

Spamhaus is not free for commercial use, you must pay for a feed or the query service if you wish to use it for an extended period.

URI Blacklists

Looks up the domain name stripped to the organization boundary of any domains found in the message body only and rejects the message if the domain is listed.

The recommended lists to use here:

• black.uribl.com • multi.surbl.org

Note

URIBL and SURBL are not free for commercial use, you must pay for a feed or the query service if you wish to use it for an extended period. rDNS

Reverse DNS (rDNS) are the hostname(s) that are returned when the IP address of the connecting host is looked up in the DNS. It is standard practice that all email servers that send mail externally to other internet hosts should have rDNS confgured. Many sites (including AOL) will not accept messages from hosts with no rDNS.

Note

To avoid any potential false-positives, rDNS test failures are ignored if sender authentication succeeds

Require rDNS

Require that the connected host must have a rDNS entry. If no rDNS entry is found, the message is rejected, if the lookup returns a timeout or a lookup error, then the message will be deferred and the sender will retry it later.

Reject generic rDNS

Reject rDNS entries that are generic which contain at least two or more octets of the IP address in the name or contain dynamic words (indicating a dynamic IP) but excludes names containing static or business (indicating a static IP or business service).

Reject invalid rDNS domains

Reject rDNS entries which contain top-level domains (TLDs) that are not valid. Common TLDs used on internal networks: .local, .lan and .corp are automatically excluded from these checks.

EHLO/HELO

HELO/EHLO is sent as the first command that should be sent after connection (once the banner is received). HELO is used for older-style SMTP connections and EHLO is for Extended ESMTP connections and the response of EHLO tells the remote client which SMTP extensions are supported (e.g. STARTTLS, AUTH, SIZE etc.).

Note

To avoid any potential false-positives, HELO/EHLO test failures are ignored if sender authentication succeeds

Require valid hostname

The RFC states that a fully-qualified hostname (not a domain name) should be sent as the HELO/EHLO argument and enabling this option requires this. If the sender fails to send it in this way, the connection is rejected.

Reject hosts that send mismatched HELO

HELO/EHLO can also be used multiple times within a connection (to reset transaction state) and this option ensures that the host always sends the same arguments as it is reasonably common for poorly written spam cannon software to attempt to cycle through different HELO names each time it sends them. With this option enabled any message that is sent with the HELO/EHLO in this format will be rejected.

Reject bare IP addresses

The RFC states that IP address should always be sent in literal format e.g. [1.2.3.4] or [dead::beef]. Enabling this option enforces this and any message that is sent using a bare IP address will be rejected

Reject mismatched IP literals

Reject messages from connections where the IP literal sent does not match that actual connection IP address. If the connection IP is an RFC1918 address, then this option is ignored.

Reject dynamic

Reject HELO/EHLOs that contain all or part of the IP address of the connected host (e.g. they look like generic rDNS names).

Bounce Messages

Bounce messages are administrative messages sent using a special null envelope sender address to ensure that should delivery fail another bounce message will not be set. They are used to tell a sender if a previously accepted message was rejected when delivery was attempted or that a message is delayed and is still in the queue and for out-of-office replies and vacation notices.

They are essential to the working of SMTP and disabling them entirely will cause issues where your senders think that messages have been delivered when in fact they were not. Typically, users will see them when they have a typo in an email address or send a message to a mailbox that doesn’t exist or has been deleted.

One of the main issues with bounce messages is that poorly configured sites will send bounce messages to mail from spoofed senders (e.g. where spam is sent using someone else’s email address as the return address) and depending on how many messages were sent - the number of bounce messages received could be signifcant. This is called Backscatter.

To protect your domains from spoofing in this way you should always configure an SPF record for them. It won’t completely stop this from happening, but it can significantly reduce the amount of issues this can cause and combined with the options below and with rate-limits for null sender messages per-recipient can mitigate any issues that might arise.

Note

Also see the post-DATA Bounce Messages and Watermarking sections

Single recipient only

Bounce messages should only ever be to a single recipient. When this option is enabled any bounce message with multiple recipients will be rejected.

Enable backscatterer DNSBL list

Query the backscatterer DNSBL list for the connected IP address when they attempt to send a message from the null sender and reject the message if the IP address is listed.

Whilst this can be useful if you are under a Backscatter attack, it can still cause valid bounces to be rejected from hosts that are listed, so it should only be used when necessary.

Reject all

When enabled, this will reject all bounce messages.

Note

This should only be used in exceptional circumstances.

SPF is a method to prevent sender address forgery and protects the envelope sender address, which is used for the delivery of messages. It allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain.

The domain owner publishes this information in an SPF record in the domain's DNS zone, and when someone else's mail server receives a message claiming to come from that domain, then the receiving server can check whether the message complies with the domain's stated policy.

See the OpenSPF website for more information and a wizard to set-up SPF for your domains. We recommend that all domains publish an SPF record as it is also useful as a whitelisting mechanism.

SPF checks are always run for every message and is used as part of Sender Authentication heuristics

Enabled

Enabling this option allows TUXMAIL to reject messages where the SPF check returns Fail e.g. the domain owner specified that mail from their domain should not come from the connected IP address.

Sender Authentication

Sender Authentication uses heuristics to determine whether the connected IP address sending a message is related to the domain name that the message is reported to be from. If an SPF record is published by the domain and it is not overly broad (e.g. does include large IP ranges or have +all result) then the SPF result is used, otherwise another set of DNS checks are run to determine this. Sender authentication can be used for whitelisting, blacklisting and is used by TUXMAIL internally to skip some stricter tests that can sometimes cause false-positives at some sites

Skip rDNS/HELO rejections

Skip rDNS and HELO/EHLO check failures when Sender Authentication succeeds.

Greylisting

Greylisting intentionally defers messages from unknown servers for a short period of time to prove that server (or group of servers) correctly retries the message again later (this is a core requirement of a mail server). This delay also greatly helps the effectiveness of DNS and URI blacklists due to the inherent lag time between spam detection and DNS listings.

Confguration Options: Enable or Disable greylisting globally

Time

The amount of time in seconds that a host should be greylisted for. If further the host sends further retries during this period then they are greylisted again. The default and recommended value for this is 850 seconds. This is because many sites have a default retry period of 15 minutes and this ensures that these hosts are only ever deferred once.

Fail TTL

The amount of time to keep a greylisting key in the cache before it is automatically expired (in seconds). The default and recommended value is 90000 seconds which is 25 hours which allows a host with a 24 hour retry interval to pass greylisting.

Pass TTL

The amount of time to keep a greylist pass key in the cache since it was last used before it is expired (in seconds). The default is 3628800 seconds (42 days).

Miscellaneous

Single domain per session

A single SMTP session can create multiple transaction which can result in a messages being accepted. When enabled, this option only allows multiple transactions where the sender domain name is identical to the previous transaction or if the domain name and host can be authenticated using Sender Authentication, otherwise the messages will be deferred to force the host to try again later. This can help slow down messages being injected from compromised hosts.

Click Whitelisting

Click whitelisting is a false-positive avoidance system. When enabled it provides a clickable link in most SMTP rejection messages which should appear in any bounce messages received by a sender when their mail is rejected by TUXMAIL. It allows them to whitelist themselves by clicking the link and solving a Google ReCAPTCHA, after which they can resend their message and it will be accepted.

To enable it you must register with Google ReCAPTCHA (https://www.google.com/recaptcha/ intro/v3.html) and register a new site to get the Site Key (Public Key) and a Secret Key (Private Key).

Note

Click whitelisting uses a web server embedded into the SMTP server running on TCP port 3000, so to use it you must open port 3000/tcp to all worker nodes. It runs on the worker nodes and Click whitelisting uses the Shared Cache to store the whitelist keys.

Enabled

Toggles Click Whitelisting on or off. You must enter a Secret, Private Key and Public Key for the feature to start working regardless if this is enabled or not.

Secret

To prevent someone from abusing the Click Whitelist a secret is used to prevent tampering with the click data which is entered into the Cache

Private Key

The site key as provided by Google ReCAPTCHA.

Public Key

The secret key as provided by Google ReCAPTCHA.

Initial TTL

How long (in seconds) should the Click Whitelist key be valid for. The default is 604800 (7 days). This is to prevent whitelist keys from being used long after the rejection was frst sent.

How long (in seconds) should a whitelist key be valid for after a message is successfullyreceived.

The default is 3456000 seconds (40 days). Provided that a message is successfullyreceived from the whitelisted sender, then the whitelist key will be refreshed to this value, soprovided at least one successful message is sent within this time, the whitelist entry will not expire.

Outbound/Relaying

Outbound or relaying is when a trusted host is allowed to send non-local mail to hosts on the internet. Any host which uses SMTP AUTH is automatically trusted as is any host explicitly allowed to relay using the Maps.

If SMTP AUTH is used, then TUXMAIL will automatically look for the SMTP AUTH username and password within the body of the email being sent. If both username and password are found the message is rejected and a warning sent to the user.

This is a crude method to try and prevent a user from replying to a Phishing message with their username and password.

Address Book

For outbound traffic, the Address Book will record all of the correspondents e-mail addresses that a user sends messages to. The address book is then consulted for each inbound recipient to see if the sender is present in the recipient’s Address Book.

If a match is found, then certain spam checks are bypassed which reduces potential false- positives and increases scanning efficiency.

Enabled

This enables or disables the Address Book feature.

Post-DATA Checks

Post-DATA checks are those that are run against the actual headers and message body. They are the most computationally expensive checks to run as they require the entire message to be received frst

Watermarking

Watermarking makes a small modification to both inbound and outbound messages so that when an inbound message is received the system can determine that the message is a reply. This allows for invalid bounce messages to be rejected and replies to bypass spam checks.

This reduces overall system load and prevents false-positives. It works best when all outbound mail for inbound domains contains these watermarks.

Note

Watermarking is required when DSPAM is used as the training signatures are stored in the watermark added to each message, so if this is disabled your users will not be able to train DSPAM at all.

Enabled

Enable or disable the watermarking feature globally.

Secret

Secret key to encrypt the watermark with. This is to prevent the watermarks from being abused, only the systems that generate the watermark with a common secret key will be able to decrypt them and trust they have not been tampered with.

Expiry Time

Length in days that the watermark is valid for, to prevent them from being abused. The default is 14 days.

Reject Bounces without watermark

Reject any bounce messages that do not contain a valid watermark.

Note

If you enable this option, you must ensure that all of your outbound mail is sent via TUXMAIL, so that all outbound mail contains the watermarks otherwise valid bounce messages will be rejected.

Also see the pre-DATA Bounce Message options

Check each received hop with SPF

Parse each Received header and extract the IP address and check against the recipient domain SPF record. If a None result is returned the test is skipped as the domain does not publish an SPF record otherwise unless one of the lookups returns a Pass result, the message will be rejected.

DSPAM

Important

DSPAM requires the Watermarking feature to be enabled for training to work correctly. This is because the message watermark is used to store the DSPAM signatures.

DSPAM is an open-source statistical spam flter. It classifies messages into Innocent and Spam categories using statistics based on the tokens (words and headers) used in a message. TUXMAIL uses one DSPAM database per configured inbound domain, so all the users of a domain ‘share’ the same classification database. This provides a good trade-off between accuracy, training burden and the overall size of the DSPAM databases.

For DSPAM to be effective, it must learn what is Innocent and what is Spam by training. TUXMAIL uses a hybrid training mode called TONE (Train on near error), which means that if it doesn’t have a high confidence about a message’s classification, then it will tag the subject of a message with either [SPAM?] or [NOTSPAM?] which means it wants the recipient of the message to train it and tell it if the classification is correct or not. The user does this by forwarding the message to a special training e-mail address (called a training alias), the user would also do this if the message wasn’t tagged but was incorrectly classifed.

In addition to the user training, if the Enable Auto Training option is enabled, then TUXMAIL will automatically train DSPAM with Spam when a connected host is listed on one of the configured DNS or URI blacklists, the message is to a valid user and the load average of the system is low. When auto-training, the message is checked twice - once to see if DSPAM already thinks the message is Spam or not and then again to train DSPAM on the message if the classification is incorrect or if the confidence is lower than the ‘Auto Training Level’, this is to ensure that DSPAM is not over-trained on Spam messages.

DSPAM requires training on 2,500 messages before it considers its database is mature enough to be very confident with its classifications and until this threshold is reached, DSPAM will ‘water

TUXGUARD GmbH © 2020 48 Confguration down’ its classifications to prevent false-positives and you will find that it gets some initial classifcations wrong and will require an amount of ‘near-error’ training during this time.

If DSPAM and SpamAssassin are both enabled in TUXMAIL, then DSPAM is run first and the results will be automatically scored in SpamAssassin via a supplied plug-in:

Confdence Innocent ScoreSpam Score 0% to 50% -0.001 0.001

60% -1.0 1.0

70% -2.0 2.0

80% -3.0 3.0

90% -4.0 4.0

100% -5.0 5.0

Training

For training to work correctly you must set-up a DNS hostname that resolves to the IP addresses of all of the machines that you installed the tuxmail-worker RPM.

This is so that when the user wants to train DSPAM, they forward the message to one of the training aliases that points to the confgured DNS hostname.

To train DSPAM, the user forwards the message to either spam@ or notspam@.

For example: if you have two systems called mx1.tuxguard.com and mx2.tuxguard.com, you would create a DNS CNAME called training.tuxguard.com that points to both mx1.tuxguard.com and mx2.tuxguard.com. When a user wishes to train TUXMAIL on a message that is spam, they would forward the message to [email protected] which would cause their mail server to send the forwarded message directly to TUXMAIL which can then train DSPAM accordingly.

Important

For a training message to be accepted, the host sending the training message MUST be allowed relay permission by TUXMAIL. Relay permission is granted to any host that successfully uses SMTP AUTH or that is explicitly allowed to relay via a map entry. This is a security measure to prevent unauthorized users from sending training messages.

If there is a problem with the training message, such as the signature not being found or being sent from an unauthenticated host then the message will be returned to the sender with the appropriate error message. Successful training messages do not elicit any response from TUXMAIL: once training is complete - the message is simply discarded.

Enable or Disable DSPAM globally.

Host

A comma-separated list of host/ip:port of the DSPAM servers that you want TUXMAIL to query. Leave it blank to use the TUXMAIL supplied DSPAM instances.

Server Password

The server password that DSPAM expects. For the TUXMAIL supplied DSPAM instance, this is automatically generated, so do not change it or TUXMAIL will not be able to communicate with DSPAM.

If you are using your own DSPAM hosts, TUXMAIL will authenticate itself as @default, so your ServerPass directive in dspam.conf should be:

ServerPass.default ""

Training Level

Minimum confidence level before TUXMAIL will modify the subject to add [SPAM?] or [NOTSPAM?] to request that the user train DSPAM on the message to improve the accuracy of future messages.

Default is 75%

Reject Level

Confidence level at which to reject messages. Set this to 0 (zero) to prevent any messages from being rejected.

Default is 95%

Enable Auto Training

Enable or Disable Auto Training. Auto Training is used to keep DSPAM accurate with fresh spam messages by training it on messages that are sent to valid mailboxes but where the host is listed on a DNSBL or URIBL and the system load isn’t high.

To prevent over training, a classification is run first and if the confidence is less than the Auto Training Level , then the message is run through DSPAM again in Inoculate mode which aggressively trains DSPAM on the tokens found inside the message.

Messages are only auto trained if the initial confidence level is less that this value. This prevents over training DSPAM, so be careful not to set this value too high.

Default is 85%.

SpamAssassin

Apache SpamAssassin is the #1 Open Source anti-spam platform giving system administrators a flter to classify email and block spam (unsolicited bulk email).

It uses a robust scoring framework and plug-ins to integrate a wide range of advanced heuristic and statistical analysis tests on email headers and body text including text analysis, Bayesian fltering, DNS blocklists, and collaborative fltering databases.

TUXMAIL provides a preconfigured installation of SpamAssassin along with an automatically updated set of custom rules and plugins. The SpamAssassin Bayes plugin is disabled by default as DSPAM provides better accuracy and is easier to train. A plugin is supplied with TUXMAIL so that SpamAssassin will add score based on the DSPAM results. See the DSPAM section for details.

By default SpamAssassin considers a message to be Spam if it scores >= 5 at which point TUXMAIL will tag the subject with [SPAM] and set an X-Spam-Flag: YES header which can be used to deliver messages to the users ‘Spam’ or ‘Junk’ folders.

See Mail Server Confguration

Enabled

Enables or Disables SpamAssassin globally

Host

A comma-separated list of host/ip:port combinations of systems running the SpamAssassin spamd daemon. Leave blank to use the local spamd instance that is configured automatically.

Reject Score

SpamAssassin score at which to start rejecting messages.

Default: 10

SpamAssassin score at which to reject messages that are being sent from a host that is allowed to relay (via relay permissions or SMTP AUTH). This is to prevent outbound spam from being allowed to be sent through TUXMAIL.

Default: 5

MessageSniffer

Note

MessageSniffer is an optional extra available at additional cost.

You can Sign up (http://www.armresearch.com/Pricing/Forms/trialForm.jsp) for a free 30 day trial, the licenses cost between $99 and $495 per server/year depending on your non-spam mail volume (this will be analyzed during your trial period).

MessageSniffer is an intelligent, anti-spam scanner that uses advanced pattern recognition and collaborative learning technologies to accurately identify spam, scams, viruses, and other email borne malware.

It consistently captures more than 99% of spam on average (calculated from spamtrap processing data, customer reports, telemetry, and lab tests on live messages) and has the lowest false positive rates in the industry. MessageSniffer scans more than half a billion messages per day while we receive fewer than 300 false positive reports per month!

TUXMAIL automatically reports hosts to MessageSniffer’s local IP reputation database whenever a recipient or message is rejected that MessageSniffer has not scanned. This helps to build an effective local IP reputation database using data from other TUXMAIL tests.

It requires no confguration and is highly recommended, especially for high volume sites.

Once Enabled and the License ID and Authentication code have been entered, you must login to the system as root and run: tux_confg.js

To manually download and install the initial MessageSniffer rulebase. After the rulebase has been installed TUXMAIL will automatically start, begin using the service ans automatically update the rulebase every 45 minutes.

Enabled

Enables or Disables MessageSniffer globally.

The license ID provided by Arm Research.

Authentication

The authentication code provided by Arm Research.

Miscellaneous/Experimental

Reject unreplyable messages

Checks the Reply-To, From and Sender headers (in that order) to ensure that the domain resolves to a valid MX record and that the message can be replied to. The message will be rejected if it is not.

Note

Experimental feature

This modifies the From header and changes the Display Name (what is shown in the users email client). It is designed to give a visual cue to the recipient to make it more obvious where a message has come from and how trusted the source is to prevent them being a victim of Phishing, Malware, Viruses or Spam.

The following changes are made:

[*] is added to denote that the message was received over a secure channel (e.g. SSL/TLS).

[!] is added to denote that the envelope sender domain could not be linked to the host that sent the message (e.g. it failed Sender Authentication).

If the envelope-from and from address do not match it will change the Display Name to: “ on behalf of ”

If the message is being received from a mailing-list, then the Display Name will be changed to: “ via ”

Note

None of these changes will affect the recipient’s ability to reply to the message. It is purely for display purposes.

Non-Latin character limit

Note

Experimental feature

Reject any message that contains more than this percentage of non-latin characters (e.g. Russian, Chinese, Japanese, Greek, Arabic etc.) in the subject line or message body.

Note

This is a global setting for all domains, do not enable it if you have users that might exchange email in non-latin languages.

Anti-Virus

TUXMAIL currently supports ClamAV and ESET Mail Security Anti-Virus engines. Anti-Virus and Attachment checks are always run before Spam and other checks and are excluded from being skipped by any Map ACLs (to prevent spam whitelisting from allow viruses through).

Important

Should any enabled Anti-Virus engine fail, then messages will be deferred by TUXMAIL to prevent allowing delivery of potentially infected messages.

ClamAV

ClamAV® is an open source (GPL) anti-virus engine and is included by default with TUXMAIL. The options below enable rejections of messages based on the type of signature detected in the message. If any viruses are detected but the relevant option is disabled, then the virus name is written to the X-Haraka-Virus: header which can be used for scoring later in the scan sequence (such as within SpamAssassin).

Enabled

Enable or Disable ClamAV anti-virus scans.

Hosts

If you wish to direct ClamAV scans to a dedicated cluster of ClamAV installations rather than using the TUXMAIL supplied daemon, then you can supply a comma-separated list of host/ ip:port combinations here and TUXMAIL will use those instead. Leave blank and each TUXMAIL host will use its locally installed daemon.

Reject Broken Executables

When enabled, this will reject messages with attachments that contain broken executables detected by ClamAV.

Reject Encrypted Archives

When enabled, this will reject messages with attachments that contain encrypted ZIP or RAR fles. Encrypted archives cannot be scanned as they cannot be unpacked by ClamAV.

When enabled, this will reject messages with attachments that contain ‘Potentially Unwanted Applications’ identifed by ClamAV. From the ClamAV documentation - these include the following types of unwanted applications:

Packed

This is a detection for files that use some kind of runtime packer. A runtime packer can be used to reduce the size of executable files without the need for an external unpacker. While this can‘t be considered malicious in general, runtime packers are widely used with malicious files since they can prevent a already known malware from detection by an Antivirus product.

PwTool

Password tools are all applications that can be used to recover or decrypt passwords for various applications - like mail clients or system passwords. Such tools can be quite helpful if a password is lost, however, it can also be used to spy out passwords.

NetTool

Applications that can be used to sniff, flter, manipulate or scan network traffic or networks. While a network scanner - for example - can be a extremely helpful tool for admins, you may not want to see an average user playing arround with it. Same goes for tools like netcat and the like.

P2P

Peer to Peer clients can be used to generate a lot of unwanted traffic and sometimes it happens that copyrights are violated by downloading copyright protected content (Music, Movies) - therefore we consider them possibly unwanted as well.

IRC

IRC Clients can be a productivity killer and depending on the client - a powerful platform for malicious scripts (take mIRC for example).

RAT

Remote Access Trojans are used to remotely access systems, but can be used also by system admins, for example VNC or RAdmin.

Tool

General system tools, like process killers/fnders

Spy

Keyloggers, spying tools

Server

Server based badware like DistributedNet

Script

Known "problem" scripts written in Javascript, ActiveX or similar

Enable DLP Signatures

When enabled, message containing Credit Card Numbers or Social Security Numbers identified by ClamAV Data Loss Prevention module will be rejected.

Reject OLE2 Macros

When enabled, messages containing attachments which contain any Microsoft Office Macros will be rejected. This can prevent a lot of malware droppers, but may impact your users if they send and receive a lot of documents that contain macros.

Enable Google SafeBrowsing Signatures

When enabled, messages containing URLs listed on the Google SafeBrowsing list will be rejected.

Enable Phishing Signatures

When enabled, messages identified as potential Phishing will be rejected. ClamAV recommends that this not be used to reject messages.

Enable UNOFFICIAL Signatures

ClamAV allows anyone to write their own signature databases. These always have .UNOFFICIAL added to their name so they can be identified as from the ClamAV or not. Enabling this option allows messages that match an .UNOFFICIAL signature to be rejected

Exclude List

This is a list of viruses, one per line, that should not be rejected if detected. Wildcards are supported, * will match many characters and ? will match a single character only or regular expressions can be used by enclosing the pattern with //. Comments are prefxed with # You can negate a match by prefxing it with ! Negative matches are always checked frst.

AVG is an optional add-on. It must be installed on each TUXMAIL worker host before it is enabled. See Appendix E for installation instructions

Enabled

This enables or disables AVG AntiVirus scanning

ESET Mail Security

ESET Mail Security is an optional add-on. It must be installed on each TUXMAIL worker host as per the ESET documentation before it is enabled.

Note

Only the Anti-Virus portion of ESET Mail Security is used, the Anti-Spam engine is not as it is inferior to the other engines supported by TUXMAIL.

Enabled

This enables or disables ESET Mail Security scanning.

Attachments

This allows you to prevent specific files, file extensions and MIME types from being accepted to comply with corporate policies and to act as a first defence for Anti-Virus and Malware as many viruses and malware droppers can be blocked simply by preventing specifc fle extensions.

The supplied defaults mirror the attachment policy of Google (https://support.google.com/mail/ answer/6590?hl=en).

Filename Rules

A list of flenames to reject, one per line. You can use wildcards, * to match any character and ? to match a single character. Matches are not case sensitive.

If any match is found, the whole message is rejected

Archive Filename Rules

Same as above, but only applies to fles found whithin an archive such as ZIP, RAR, etc.

Archive File Extensions

A comma-separated list of fle extensions that should be treated as archives and unpacked.

Any archive format that is supported by libarchive (https://github.com/libarchive/libarchive/ wiki/LibarchiveFormats) can be used here.

Default: .zip, .tar, .tgz, .z, .gz, .rar, .7z

Maximum Archive Depth

Maximum allowed depth of archives. If the depth exceeds this, the message will be rejected.

Default: 5

Note

Encrypted archives that contain encrypted sub-archives cannot be expanded and will cause the message to be rejected.

List of MIME types to reject, one per line. Wildcards are allowed, * matches any character, ? matches a single character. Matches are not case-sensitive.

The content-type headers of the message and any MIME part and attachment are checked against this list.

Default: - message/partial (because partial messages cannot be virus scanned) - message/ external-body (because external message bodies cannot be virus scanned) - application/msdownload (typically .exe and .dll fles)

Alerts

Alerts are sent when a trusted host (e.g. a host with relay permissions or SMTP AUTH client) does something unexpected like exceeding the configured rate-limits, sending a virus or blocked attachment or sending a message that is rejected on delivery by the destination system.

Alerts From

This is the from address used in the alerts. Default: postmaster@ where local-host-name is the hostname of the system that generates the alert.

Alerts To

A comma, space or semicolon delimited list of recipients that the repots should be sent to.

HAProxy

You can install HAProxy in front of any number of TUXMAIL workers and have it load balance the connections. TUXMAIL has built-in support for the HAProxy PROXY protocol which ensures that TUXMAIL sees the correct external IP address and port instead of the IP address and port of the HAProxy host.

You must configure TUXMAIL with the IP addresses of any HAProxy instances in the HAProxy hosts setting for this to work correctly.

If you connect to TUXMAIL from any host listed as a HAProxy host, it will not send an SMTP banner, instead it expects a PROXY command to be sent at which point it will reset the connection attributes accordingly and then send the SMTP banner to start the session.

If no PROXY command is received within 30 seconds a ‘421 PROXY timeout’ SMTP response will be sent.

Example HAProxy Confguration

Here is a snippet from haproxy.cfg for typical port 25 and port 587 listeners that point to TUXMAIL hosts. listen smtp :25 mode tcp option tcplog option tcp-check tcp-check expect rstring ^220\ tcp-check send QUIT\r\n tcp-check expect rstring ^221\ balance roundrobin server :25 check-send-proxy check inter 60s send-proxy ... listen smtp_submission :587 mode tcp option tcplog option tcp-check option tcp-check tcp-check expect rstring ^220\ tcp-check send QUIT\r\n tcp-check expect rstring ^221\ balance roundrobin server :587 check-send-proxy check inter 60s send-proxy ...

Shared Cache

The shared cache must be configured when TUXMAIL is run in a cluster, it is used to synchronize cache values between the cluster hosts. The cache holds data like valid/invalid users, greylist entries, address books, rate limit tokens etc

Secret

A secret value used to prevent cache poisoning or from multiple clusters from interacting with each other.

Port

The UDP port to use for the Shared Cache. Default is 6920.

Unicast Hosts

A comma separated list of hostnames or IP addresses that the cache updates should be sent to by unicast. This is only necessary if you have cluster nodes on different subnets or if you do not want to use multicast to send the cache updates.

Multicast IP

A multicast IP address (within 224.0.0.0/4) that the cache updates should be sent to. The cluster nodes will automatically subscribe to this multicast IP and use it to send and receive their cache updates.

Multicast can only be used when the machines are on the same LAN (e.g. same subnet) unless the default gateway router has been expressly configured to forward multicast packets to other subnets

Multicast TTL

The multicast TTL to set on any multicast packets that are sent. This is used only when you have configured your routers to send multicast traffic across subnets and this limits the number of networks the multicast packet will cross before being dropped.

The default is 1 which means that the packets are restricted to the same subnet and will never be forwarded by a router.

Mail Server Confguration

All domains that TUXMAIL is configured to accept inbound mail should ensure that their mail servers are confgured in such a way that:

• All spam checks are disabled, this is to prevent wasted I/O in performing checks that have already been done by TUXMAIL, to prevent backscatter as should those spam checks return an SMTP rejection when TUXMAIL is delivering the message will force it to generate a bounce message to the sender and to prevent support issues that might arise from inaccurate spam checks on the mailbox host. • All rate limits and throttling are disabled, otherwise this can cause delivery failures or delays. • All frewall SMTP proxies or protocol ‘helpers’ are disabled. For example: Cisco ESMTP/SMTP inspection, Cisco PIX fxup protocol SMTP (Mailguard), Watchguard SMTP Proxy, Endian Mail Proxy etc. • Confgured to reject any invalid recipients at the SMTP level. This is very important to prevent backscatter and to prevent wasted I/O in TUXMAIL.

If your mail server is capable of accepting spam results from an external system or can be configured with system-wide rules to deliver messages to a ‘Spam’ or ‘Junk’ folder, then you should confgure it to do so on the presence of the header X-Spam-Flag: YES.

Microsoft Exchange 2003

See https://support.microsoft.com/en-us/kb/823866#bookmark-6

Microsoft Exchange 2007

See https://technet.microsoft.com/en-us/library/bb123891(v=exchg.80).aspx .

You can use the Exchange Management Shell (https://docs.microsoft.com/en-us/previous- versions/tn-archive/cc505910(v=technet.10)) to automatically route messages that TUXMAIL determined to be spam to the users ‘Junk Email’ folder by running:

New-TransportRule "TUXMAIL_Spam" -HeaderContainsMessageHeader "X-Spam-Flag" -HeaderContainsWords "YES" -SetSCL 6

Microsoft Exchange 2010

See https://technet.microsoft.com/en-us/library/bb123891(v=exchg.141).aspx for instructions if you use Edge Transport servers or http://www.jjclements.co.uk/2010/09/23/exchange-2010- recipient-fltering-on-a-hub-transport-server/ if you only have a Hub Tranport server.

New-TransportRule "TUXMAIL_Spam" -HeaderContainsMessageHeader "X-Spam-Flag" -HeaderContainsWords "YES" -SetSCL 6

Microsoft Exchange 2013/2016

This requires an Edge Transport server to work correctly. See https://technet.microsoft.com/en- us/library/bb125187%28v=exchg.150%29.aspx for instructions on how to reject unknown recipients. You will need to enable both recipient fltering and enable the Recipient Lookup

New-TransportRule "TUXMAIL_Spam" -HeaderContainsMessageHeader "X-Spam-Flag" -HeaderContainsWords "YES" -SetSCL 6

Office 365

For a domain being protected by TUXMAIL the following settings should be configured in the Office365 Exchange Admin Center. These rules will ensure that Office365 honors any spam classified by TUXMAIL and delivers it to the user's ‘Junk’ folder and to ensure that no other fltering is done by Office365.

Create the SMTP connector to accept email from the TUXMAIL gateways.

Create the SMTP connector to send all outbound email through the TUXMAIL gateways (this is optional. It’s only required if outbound email is to be routed to DefederMX servers)

Then create the mail fow rule to correctly process email from the TUXMAIL gateways

In ‘mail flow’ -> ‘rules’, click the + icon and select the ‘Bypass spam filtering…’ option and enter the following settings:

Name: Honor TUXMAIL classifcations

Apply this rule if: A message header…. Includes any of these words.

Click the ‘Enter Text...’ link and specify the header name as ‘X-Spam-Flag’.

Click the ‘Enter words…’ link and add ‘YES’ and click ‘+’ to add it, then click ‘OK’.

Click ‘add condition’ and select ‘The sender… IP address is in any of these ranges or exactly matches’, then add the IP address(es) or IP address ranges of your TUXMAIL installation, click ‘OK’ when complete.

Under ‘Do the following….’ ensure that ‘Set the spam confidence level (SCL) to…’ is set, then click the ‘Bypass spam fltering’ link and specify the SCL as ‘5’ in the drop-down and click ‘OK’.

Scroll down and tick the ‘Stop processing more rules’ option.

Click ‘Save’.

The rule should look like this example:

% TODO: insert image from page 79

Add another rule, click the + icon and select the ‘Bypass spam filtering…’ option and enter the following settings:

Name: Bypass spam fltering for mail from TUXMAIL

Apply this rule if: The sender… IP address is in any of these ranges or exactly matches

Add the IP address(es) or IP address ranges of your TUXMAIL installation and click ‘Save’.

Do the following… ‘Set the spam confdence level (SCL) to…’ ‘Bypass spam fltering’.

Click ‘Save’

The rule should look like this example:

% TODO: insert image from page 81

To ensure that Office365 correctly rejects invalid recipients, under ‘mail flow’ -> ‘accepted domains’, switch the ‘domain type’ from ‘Authoritative’ to ‘Internal relay’, click ‘Save’ and then change it back from ‘Internal relay’ back to ‘Authoritative’ again and click ‘Save’.

This was found to be necessary for Office365 servers to correctly reject invalid recipients, despite the documentation.

If you wish to scan Outbound mail from Office365 with TUXMAIL, then create the following entry in TUXMAIL -> ‘Maps’: connect:.outbound.protection.outlook.com relay: true

Then in the Office365 Exchange Admin Center go to ‘mail flow’ -> ‘connectors’, click ‘+’ to add a new connector:

Select From: ‘Office 365’, To: ‘Partner Organization’ and click ‘Next’.

Enter ‘Route outbound mail to TUXMAIL’ as the Name and click ‘Next’

Select ‘Only when email messages are sent to these domains’ and click ‘+’, enter ‘*’ as the domain name and click ‘Ok’, then click ‘Next’.

Select ‘Route email through these smart hosts’ and click ‘+’, enter the IP address or hostname of the TUXMAIL outbound hosts and click ‘Save’, then click ‘Next’.

Untick ‘Always use Transport Layer Security (TLS) to secure the connection’ and click ‘Next’. Enter an external e-mail address in the area provided to validate the connector and click ‘Validate’.

Once validated click ‘Save’.

The added connector should look like this example:

% TODO: insert image from page 83

Google Apps

In the Google Apps Admin Console, navigate to Apps -> Google Apps -> Gmail.

In ‘Settings for Gmail’, scroll to the bottom of the page and click ‘Advanced Settings >>’.

In the ‘General Settings’ tab, scroll down the page to the ‘Spam’ heading and click ‘Configure’ on the ‘Inbound Gateway’ setting.

In the description field enter ‘TUXMAIL’, then under gateway IPs add the external IP addresses of your TUXMAIL systems and then tick the ‘Automatically detect external IP (recommended)’ option.

Under ‘Message Tagging’ tick the ‘Message is considered spam if the following regexp matches’, then under ‘Regexp’ enter:

^X-Spam-Flag:\s+YES\s*$

Then select ‘Message is spam if regexp matches’ and tick the ‘Disable Gmail spam evaluation on mail from this gateway; only use header value’ option

%TODO: insert image from page 85

Finally click ‘Add Setting’ and then ‘Save Changes’ to apply the changes. Once you have all inbound traffic being routed to Google Apps via TUXMAIL, you may tick the ‘Reject all mail not from gateway IPs’ option to prevent anyone from bypassing TUXMAIL and sending traffic directly to Google for your domains.

Zimbra

To disable Zimbra spam and attachment fltering by domain run: zmprov md domain.tld +amavisBannedFilesLover TRUE zmprov md domain.tld +amavisSpamLover TRUE

Where domain.tld is the domain name you wish to disable.

You can disable it completely for all domains by runnning: zmprov -l ms `zmhostname` -zimbraServiceEnabled antivirus zmprov -l ms `zmhostname` -zimbraServiceEnabled antispam

This will cause "***UNCHECKED***” to be prepended to the subject line of every email. To prevent this you must edit /opt/zimbra/amavisd/sbin/amavisd and change the following value:

$undecipherable_subject_tag = '***UNCHECKED*** '; to $undecipherable_subject_tag = '';

And restart Zimbra: /etc/init.d/zimbra restart

Even with the Spam filtering disabled, Zimbra should still automatically deliver any message that TUXMAIL thinks is spam to the recipient's ‘Junk’ folder.

If you have DSPAM enabled in TUXMAIL, then you can configure the Zimbra ‘Junk’ and ‘Not Junk’ buttons to automatically send the training messages to the DSPAM training aliases by running: zmprov mcf zimbraSpamIsSpamAccount [email protected] zmprov mcf zimbraSpamIsNotSpamAccount [email protected]

Reports report_view

User Reports

Multiple times during a 24h timespan can be picked here in order to send out auto-generated user reports to all domain users in case there was traffic related to them.

Admin Reports

A cumulative daily, weekly or monthly report for all domains is being sent automatically to each email-address specifed in the corresponding lists. domain_report

Miscellaneous

Changing Hostnames/ IP addresses

Change IP Address

Standalone TUXMAIL Server

It is not necessary to change to the TUXMAIL configuration to change the IP address of a standalone TUXMAIL server. Simple change the IP address of the standalone server and restart the TUXMAIL services: systemctl restart tuxmail-web systemctl restart haraka

Master node

Shutdown the services on the Master and all of the Slaves: systemctl stop tuxmail-web (master only) systemctl stop haraka

Change the IP address of the Master: nmcli con mod ipv4.addresses "ip.ip.ip.ip" systemctl restart network

On each slave, edit /etc/tuxmail/env and change the IP address for each of the following variables to refect the new IP address of the Master node:

DSPAM_HOST=ip.ip.ip.ip TUX_DB_HOST=ip.ip.ip.ip TUX_ES_HOST=ip.ip.ip.ip TUX_REDIS_HOST=ip.ip.ip.ip

Edit /var/lib/pgsql/9.4/data/recovery.conf and change the host=ip.ip.ip.ip to reflect the new IP address of the Master node, then restart the PostgreSQL server on each worker/slave with systemctl restart postgresql-9.4

Finally restart the services on the Master and Slaves: systemctl start tuxmail-web (master only) systemctl start haraka

Worker/Slave node

On the Worker/Slave node that is changing IP address, shutdown the following services:

On the Master node, run the following commands: firewall-cmd --zone=tux_cluster_nodes --remove-source=old.ip.ip.ip firewall-cmd --zone=tux_cluster_nodes --remove-source=old.ip.ip.ip --permanent firewall-cmd --zone=tux_cluster_nodes --add-source=new.ip.ip.ip firewall-cmd --zone=tux_cluster_nodes --add-source=new.ip.ip.ip --permanent

Change the IP address on the Worker/Slave node: nmcli con mod ipv4.addresses "ip.ip.ip.ip" systemctl restart network

Check the “Shared Cache” settings in the TUXMAIL Web UI and modify them as necessary.

If the Worker nodes are on separate subnets, then you will need to specify the IP addresses of each Worker node for cache sharing to function properly, however if they are on the same subnet, then Multicast can be used and this will work without modifcation.

Then restart the services: systemctl start postgresql-9.4 systemctl start haraka

Changing the Hostname

Changing the hostname of a Master node is not recommended unless the system has not been in production.

This is because on a TUXMAIL installation, you must access the web interface using the Master node hostname to be able to log-in to the web interface as an administrator.

Accessing the Master node using any other hostname will cause it to presume that you want to log-in to TUXMAIL as a user of a domain that is handled by TUXMAIL and therefore trying to login as an Admin will fail.

If the hostname of the Master is changed, then you will need to restart the following services once the hostname has been changed: hostnamectl set-hostname systemctl restart tuxmail-web systemctl restart haraka (if the Master is also an SMTP Worker)

You can change the hostname of a Worker/Slave node, however this will cause the following issues:

• The “Cluster” page on the will show the old hostnames as offline for the following 24 hours. • The “Cluster” page graphs will show the old hostnames separately to the new hostnames and will not disappear from the graph for 7 days. • The click URLs generated by the node (if Click Whitelisting is enabled) will reference the old hostname and will not work unless the old hostname is pointed to the new hostname by use of a CNAME. The old hostnames might still be accessed for up to 40 days after it is changed. • View/Release of quarantined items will not work unless the old hostname is pointed to the new hostname by use of a CNAME. Old hostnames might still be referenced for up to 60 days after the name is changed depending on the log retention confgured. • The PostgreSQL replication will still use the old hostname for its replication slot, this will not cause any issues unless you reuse the same hostname on a different node.

Once the hostname is changed on a Worker/Slave node, the following services should be restarted: hostnamectl set-hostname systemctl restart haraka

Backup File Import

During frst initialization of TUXMAIL web, an option to import a backup fle is being offered.

%TODO: screenshot%

Option Description Upload backup allows picking archive fle from local storage

allows specifying of path to backup archive already present on target Path to backup host

Import toggles import of superadmin accounts from the backed up host Superadmin

Import License toggles import of license data from the backed up host

In case import of superadmin and/or license are turned off, the initialization will proceed as usual i.e. offer forms to provide the missing data.

Migrating from DefenderMX

In order to migrate from an existing DefenderMX instance to TUXMAIL, the following steps need to be completed on the dmx-web host:

Important

Before beginning migration, in order to prevent data loss make sure to Backup or Snapshot your defendermx-web host in case something goes wrong!

Important

The migration will only backup and migrate data present on the web host. Workers need to be reinstalled!

Important

Logfles are currently not bein exported!

Exporting DMX Data

1) Upload the export script (/files/dmx_exporter.sh) to the web host, e.g. via scp (eventually grant execution permissions using chmod +x 2) Stop the defendermx web service: systemctl stop dmx_web 3) Run the export script: ./dmx_exporter.sh $your_output_path This will dump the contents of the Postgresql DB to a tar.bz2 archive and store it to the provided output path. Users, Domains, Mail Rules and Conﬁgurations will be exported that way. 4) Retrieve the backup archive (filename format is dmxbak_.tar.bz2 and store it locally for later.

Import DMX Data during Installation

After successful installation of TUXMAIL-web, during initial startup the first step will for an optional backup fle import. See more information here (/misc/data_import) The created .tar.bz2 is to be used here as backup fle input.