Automatic creation and management of HTTPS certificates
In this quarter new releases, there’s a new option on the ‘Branding Management’ page in the ‘HTTPS SSL Certificate’ section, ‘Generate and manage a TLS certificate for me via Let’s Encrypt‘. We strongly recommend that you enforce that all connections to the control panel are done over HTTPS (you can require this in the Server Settings page). In order to do this, you need to provide a TLS certificate that’s used to encrypt all communication with the control panel. In the past, you needed to acquire a certificate from a third party, and ensure that you remembered to renew the certificate when it expired and upload the replacement.
Now, you can just select the ‘Generate and manage … for me‘ option, and we’ll take care of acquiring a certificate and renewing it when required – no further work on your part is required, and you don’t need to worry about how to get a CSR, or whether you have all the ‘intermediate chain’, or anything like that. Even better, the certificate is free, although you may wish to donate to the Let’s Encrypt project (letsencrypt.org) who provide the certificate. Although uploading your own certificate is still possible, we recommend that users use this new option, to offload the certificate management to us.
Combining domain and email aliases
It’s now possible to use both an email and a domain alias in the same address. For example, if the domain example.org is an alias for the primary domain example.com, and example.com has an email alias example_alias@ for the primary mailbox example@, then:
- firstname.lastname@example.org is an alias for email@example.com
- firstname.lastname@example.org is an alias for email@example.com
- firstname.lastname@example.org is an alias for email@example.com
For more information, please see knowledge base article here.
Admin level sender/recipient whitelist/blacklist
An additional level of sender and recipient whitelisting and blacklisting has been added this week, enabling admins to configure their own set of default whitelists and blacklists. If lists are configured for an admin, then those will be used for domains that are linked to that admin, rather than the cluster-wide defaults.
The admin ‘chain’ will be followed until a single set of default values is found. For example, if example.com is linked to sub-admin1, and sub-admin1 has lists configured, those will be used for example.com. If sub-admin1 does not have lists configured but is linked to admin1, which does have lists configured, then example.com will use the admin1 lists. If admin1 does not have lists configured, and has no ‘parent’ admin, then example.com will use the cluster-wide defaults.
If a domain does not want to use the default lists provided by the admin (or cluster-wide defaults), the ‘use default values’ setting may be turned off.
Note that currently, domain users will not be able to see any admin-level lists that apply to the domain (and will instead see the cluster default lists instead). This will be addressed in an upcoming update.
Synchronise local recipient list and email aliases via LDAP
For users that do not wish to automatically detect destination mailboxes with the incoming filter, or manually manage the destination mailbox (local recipient) list, this week’s update adds a new option to synchronize the mailbox list with an LDAP server. To enable this, head to the new ‘LDAP Mailbox Sync’ option at the domain level, and enter in the details (hostname, username, password, etc) for the LDAP server to use. With typical configurations, that should be everything that’s required for the mailboxes and aliases configured on the LDAP server to be added to the local recipients and email alias lists in the control panel.
Please note that Local Recipients are not enabled by default, after verification of the mailbox list this option can be enabled via the control panel.
For other LDAP configurations, you’re able to configure a filter to narrow down the list of directory entries to synchronize, and specify how the directory entries should be converted (mapped) into the local recipient and/or email aliases (on the mapping tab). Super-admins are also able to configure additional default mappings, to further ease configuration for their users.
For more information, please see our knowledge base article.
New “Mailboxes Overview” Page
Users with ‘features preview’ enabled are able to see the initial version of our new ‘Mailboxes Overview’ page in this week’s release. This page will be a central location where a super-admin, admin, or domain user is able to manage mailbox level settings.
The initial version moves the ‘local recipients’ page to the ‘mailbox’ tab in this new page. This brings consistency with other pages (for example, the ability to export the list, group and filter results, and use the page without navigating to ‘domain level’), and introduces the ‘mailbox’ term, which we will be moving to, rather than the less user-friendly ‘local part’.
Also in the initial version, the ’email address aliases’ page moves to the ‘mailbox aliases’ tab in the new page. Again, this brings consistency, and uses the term ‘mailbox alias’ (or just ‘alias’) rather than ’email address alias’.
The final tab in the initial version is currently only available when logged in as a domain user (or super-admin or admin that has moved to ‘domain level’), and is the ‘Configuration’ tab. The ‘use local recipients’ option from the old ‘local recipients’ page has moved here, but is now called ‘Accept mail only for specific mailboxes’ and has more help information available. Two new options are also available, that aren’t available in the old pages: the ability to automatically add mailboxes to the list on the ‘mailbox’ tab (‘Automatically discover mailboxes’), and the ability to set a maximum number of mailboxes for the domain.
We’ll be adding more functionality to the ‘Mailboxes Overview’ page in upcoming releases. In the meantime, if you have any feedback about this or any other feature preview, please do send that along – we incorporate as much of this as possible into development before features move to general release.
Automatic Email Scout Reports
The “Domain Settings” page includes a new option with this release: “Automatically Enable Daily Email Scout Reports”. When you enable this option, an Email Scout Report, which shows the messages that are quarantined, will be automatically added for each mailbox (when a message is successfully delivered to it).
You’re able to have one, two, or three reports sent each day, at times of your choice – the report will automatically cover the period since the previous report. For example, you might have an 8 a.m. report covering all mail quarantined overnight, a 12 p.m. report for mail quarantined since 8 a.m., and then a 4 p.m. report for mail quarantined since midday.
More flexibility around the automatic reports, and how the reports look, will be available later in the year. More information about the current automatic report functionality is available in our article here.
Outgoing Filtering / Interface
Outgoing delivery IP reputation check
The ‘Manage Outgoing Delivery IPs’ page has two new tabs that are used to check the reputation of your outgoing delivery IPs. To ensure consistent delivery, it’s important that these IPs are not listed on external blacklists (DNSBL). Filtering and automatic locking provide most of what’s required to keep a clean reputation, but some manual maintenance is typically also required, particularly for newly added IPs. The system comes configured with several of the most widely used blacklists, but you can add and remove lists using the ‘Configure Reputation Check’ tab.
The ‘Reputation Check’ tab allows you to select one or more of your outgoing delivery IPs, and then check those IPs against a set of DNSBL. You may check one IP against one DNSBL (click the ‘load’ icon in the cell), check one IP against all DNSBL (select the row and use the ‘check’ action), check all IPs against one DNSBL (click the ‘load’ icon in the column heading), or check all IPs against all DNSBL (select all rows and use the ‘check’ action).
For more information, please see knowledge base article here.
Incoming + Outgoing
It’s now possible to customize what action is taken for messages based on the classification – for example, you may wish to configure a domain so that all messages that are classified as phishing are not available in the user’s quarantine. The simplest method of configuring this is to use the log search pages to locate an example of the messages that you want to customize and use the ‘Change action for messages like this’ action. This will take you to the new ‘Customise Actions’ page, with most of the required fields already completed for you.
You are able to define which messages the customization applies to by matching against the messages’ main, sub, and extra class. For example, this allows you to match all phishing messages (main class ‘phish’), all messages that are larger than permitted (main class ‘blacklisted’, subclass ‘oversize’), or all messages that match a specific custom filtering rule (main class ‘blacklisted’, subclass ‘rule-.*’, extra class the name of the rule).
You’re able to choose from several possible actions for messages that match, including rejecting the message without quarantining, reject and quarantining, or silently dropping the message (blackholing).
This functionality is currently only available to users that have ‘features preview’ enabled.
Temporary Log Search
We record detailed meta-data for nearly all connections to the filtering servers. In a few cases, we’re unable to associate the connection to a specific domain or outgoing user (e.g. the recipient is to a domain that is not handled by the filtering server). We are therefore unable to expose those logs to domain level users, but super-admins or (for the outgoing filter only) admins are now able to access these in the web interface in the new ‘Temporary Log’ pages (available when ‘features preview’ is active). Note that much more limited information is available for these connections since they do not typically progress very far. These are most commonly used when diagnosing initial connection issues – for example, someone is using the wrong port for the outgoing filter or is not authenticating with the outgoing filter.
Global Journal Address
One of the features that the archiving product offers is the ability to ingest messages in Microsoft Exchange’s “journaling” format; this is used to ensure that messages that are sent within a domain are also added to the domain’s archive. A limitation of this functionality is that it requires that the domain’s MX records are set to the cluster – this would be the case if using the incoming filter but is less appealing for anyone wishing to use the archiving product without the incoming filter.
In this release, a new “global” journal address functionality has been added, that considerably simplifies using Exchange journaling with the archiving product. Each archived domain is assigned a unique mailbox in the cluster, specifically for ingesting journaled messages. An added advantage is that you no longer need to connect to the submission port (587) to add journaled outgoing messages and the delivery port (25) to add journaled incoming messages – the system will figure it out for you.
For example, the example.org domain might have the unique mailbox firstname.lastname@example.org. You can simply use this address when configuring journaling in Exchange, and the system will ensure that it’s journaled under the correct archiving domain.
To see the mailbox for a domain, simply go to the “Archive Status” page at the domain level. The system attempts to show a branded domain name if one is being used, and will otherwise default to the hostname of the cluster. For more information, please see our article here.
Thank you for reading! Until our next quarterly technical update, keep spam away. We invite you to drop us a comment in the section below.