There are three important Mail Assure changes, one live now, and two coming soon, of which you need to be aware. Depending on how you use Mail Assure, you may need to make changes to your firewall, custom integrations, or other settings.
New IP for LDAP Authorisation, LDAP Sync, Continuity, and invitation/password Emails
The IP addresses that connections for LDAP Authorisation and LDAP Sync originate from have changed. If your firewall is based on a hostname, like securemail.management, then you should not need to make any changes. If your firewall has IP addresses, then you need to remove the old addresses (184.108.40.206 and 2001:1af8:4500:a034:101::2) and add the new addresses: 220.127.116.11 and 2001:978:2:6::20:10.
Similarly, email that is sent using the “Continuity” functionality in the app previously arrived from the old addresses and now will arrive from 18.104.22.168 and 2001:978:2:6::20:10. If you have your firewall configured to only accept mail from specific IP addresses (rather than from hostnames) then you should remove the old IPs and add the new ones.
Finally, invitation emails to new technicians, and password reset emails for lower level users (ones that do not use N-able SSO) will also arrive from the new IP addresses. Again, if your firewall is set to only allow mail based on IP address, please remove the old addresses, and add the new ones.
This change is effective as of the 17th of April, 2022. We apologise that we did not communicate this change in advance, and we’re working on improving processes to make sure that any future changes do arrive with plenty of advance notice.
Outgoing Filtering: SMTP AUTH must use TLS
If you are protecting outgoing mail as part of Mail Assure Protection, and you are authenticating with a username (e.g. “example.com” or “firstname.lastname@example.org”) and a password, then you need to ensure that you are using TLS (this should be a simple checkbox style option in your mail server – it may also be called “STARTTLS”). Connections that do not establish an encrypted (TLS) connection will not be able to authenticate, and so your outgoing mail will not be accepted. This change must be made before the end of May, 2022.
Using an encrypted connection ensures that if someone manages to get access to your network traffic, they are unable to read the authentication credentials when your server sends mail. It is most likely that you are already using TLS, but please check this to ensure that there is no disruption to your outgoing traffic.
Dropping support for HTTP, connections will redirect to HTTPS
All HTTP connections to the app already redirect to HTTPS, but HTTP API requests are permitted (but strongly recommended against). Later in the year, all HTTP API connections will also respond with a “301” redirect to the equivalent HTTPS connection. Generally, redirects will be automatically followed, but if you have a custom integration using the control panel API, and it is using HTTP, please change it to use HTTPS as soon as possible.