The shutdown of the MX1 server has been delayed to June 9th.
MX1 Server Shutdown Delayed
LiteSpeed on Ocean, One, and London
LiteSpeed web server deployed on Ocean, One, and London servers in attempt to speed up webmail performance.
Rspamd deployed on Echo server
SpamAssassin has been replaced with rspamd on the Echo server. This may change some of the email headers used for spam filtering by the server. The "SpamAssassin Settings" page in DirectAdmin will continue to function as normal.
Other servers will soon receive the same treatment.
At the end of May (time not specific, we'll give time to account for timezones) the MX1 and Galaxy servers will be permanently shut down. These servers were based on our first product iteration, and are not salvageable. There are only a few customers left on them, and we've sent emails to everyone about this. A few were unreachable and no longer have valid email addresses on their MXroute accounts, hopefully they'll see the announcement here.
Anyone paid up beyond the month of May will receive a refund, these are being manually processed (a few each day).
While this is not how we intend to get rid of older servers over time, these two servers are unique. This should not have you questioning if other servers will see a similar fate in the future.
DirectAdmin disk quotas fixed
Disk quotas should now be displaying properly in DirectAdmin.
Outbound rate limit fixed
For some time our 300 outbound per hour limit has been a soft limit, as the rate limit module for rspamd had not been functioning as intended under some edge cases. This has been fixed, and the limit has been reapplied. You may be able to burst slightly over the limit, but should not rely on it.
mail.com / GMX bounce mitigated
If you recently sent an email to mail.com or GMX it is possible that you received this error returned back:
"Nemesis ESMTP Service not available No SMTP service IP address is black listed"
We've added mitigation for this now so that you will no longer receive bounce errors, and these emails will be delivered anyway while we work on building a relationship with the email provider in question.
Comcast bounce mitigated
Comcast has been returning messages like this for some of our IPs:
"554 resimta-po-03v.sys.comcast.net resimta-po-03v.sys.comcast.net 220.127.116.11 found on one or more DNSBLs"
Despite finding these IPs to be quite clean in our tests, Comcast appears to subscribe to some obscure RBL that we do not know to check (or they use their own internal RBL). Our relays were not configured to retry these emails from different IPs, and were instead bouncing them back to senders. We've added mitigation to our relays that should correct this. After we're satisfied that the change works in all cases, we will submit a PR to the open source project that we utilize for our relays.
Dropping TLS v1.1
In lastest software updates we are removing support for TLS v1.1. This will break severely outdated software. If you must continue to use outdated software, you should consider the use of SSL to be insecure with that software and use non-SSL connections. A better option would be to upgrade your software. Significantly old software generally does not support secure connections as security is defined by the latest standards. TLS 1.1 is reaching end of life status on March 31 of this year, and should be removed from secure systems.
Adjustments to outbound rejections
Three email rejection messages were reported to us several times recently:
"Your access to submit messages to this e-mail system has been rejected"
"You are not allowed to connect"
"Recipient address rejected"
These seem to have a correlation with Microsoft/Exchange recipients. We determined that the first two are likely issues of IP reputation, and so we've put in place rules to ensure that we retry delivery from several IPs before bouncing those back to the sender.
The third case (Recipient address rejected) had been tested under the same conditions for several hours and found to not be related to IP reputation at all, but to be an issue with Office 365/Exchange servers. It may be as simple as the recipient no longer existing at that domain, or as complex as an unknown misconfiguration by the recipient party (or their IT department). For the time being, we're considering that to be a legitimate bounce error that we cannot assist with. You can read more about that here: https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/non-delivery-reports-in-exchange-online/fix-error-code-550-5-4-1-in-exchange-online