MXroute changelog mxroute.com

New

We're ramping up an internal campaign against invalid sender and recipient domains. Below should serve as a more detailed explanation.

As a general rule, we cannot assume that a domain which does not presently resolve is an invalid domain. The domain could be experiencing a temporary DNS issue, or we could be experiencing one ourselves. For this reason, email that you send to or from an invalid domain sits in queue and we try again to deliver it every few minutes. This becomes problematic when users collectively send to and from hundreds, or thousands, of actually invalid domains every hour. It causes email queues to explode in size, and it makes it more difficult for us to actually identify problems on our platform as the statistics can be masked by invalid domains that will stay in queue for the maximum amount of time configured.

Automating the blocking of invalid sender/recipient domains has proven to not be a reliable job, as a temporary DNS issue does occasionally occur, and that would cause us to block a valid domain as invalid. Moving forward, we will be performing audits on our platform for invalid sender/recipient domains multiple times throughout each day. The goal is this is to quickly return to you a clear error message at SMTP time when you've attempted to send email to or from an invalid domain.

An example of an invalid domain and one that we just blocked prior to posting this: @pop-os.localdomain

We'll keep trying new things until we get the results that we want. The best results we've had thus far on communicating changes and status have been from Headway (Changelog) and Instatus (Status page). For that reason, these two pages are going back into production:

https://headwayapp.co/mxroute-changelog

https://status.mxroute.com/

New

While rspamd is objectively more efficient, we've reverted our DirectAdmin servers to use SpamAssassin. The most significant reason being that the SpamAssassin user configuration in the DA panel would not work fully as expected (ex. no wildcards on white/blacklist), and this led to us spending too much time trying to work with users to achieve their goals here (or to explain why they couldn't and were better off than if they were able to). The most wise decision appears to be to restore that page to work as users expect.

We expect a very functional configuration that helps reduce spam to look something like this: https://www.dropbox.com/s/5mmd017tfvvzw2b/Screen-Shot-2020-01-22-11-05-52.59.png?dl=0

If you see false positives to any excessive degree, maybe try "Medium Threshold" instead.

No you do not have the ability to train the filters, bayesian learning is not effective or efficient and we're not using it to train when you move email to/from the junk/spam folder.

New

When recipient services are guaranteed to reject a forwarded email based on the sender (sender domains that specify "reject" in their DMARC record), we block the sender's email from being forwarded as the only possible impact of sending an email that is guaranteed to be rejected would be negative IP reputation (you wouldn't receive the forwarded email anyway, no benefit, only harm to be done).

Previously we've relied on a default rspamd message "554 5.7.1 Matched map: SENDERFROMBLACKLIST" which was returned to the sender. This message has been adjusted to:

"Your recipient is forwarding email and the domain you are sending from forbids it by DMARC"

Improvement

DirectAdmin servers have seen an update to Roundcube 1.4. This includes their new beautiful and responsive skin, and marks the removal of the third party skins that played this role in the interim.

New

The London server has been migrated from cPanel to DirectAdmin. This aims to correct performance and stability issues over the past months, as well as solve the problems caused by cPanel licensing changes. You need to know some details if you are on this server:

• The control panel is now at https://london.mxroute.com:2222
• You can find some tutorials here: https://mxroutehelp.com
• Email filters are created under Settings in Roundcube.
• We are working to get Crossbox back online for London, a location where it has previously been unstable.
• The server is not physically in London, but is close enough to still have very low latency to locals (NL).

New

By request, credit existing on an account will now be used to pay any open invoice automatically.