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.

https://github.com/zone-eu/zone-mta/pull/231

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 172.82.139.124 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

Fixed login issue for new users on Arrow

New users on the Arrow server may have been unable to log in to Crossbox. This was caused by a failure to create symlinks at /home to the /home2 partition after user creation. This should now be resolved.

DirectAdmin servers moved from rspamd to SpamAssassin

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.

More clear message for rejected forwarded email

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"

DirectAdmin Backups Resolved

Since deployment of the DirectAdmin servers we've been trying to work with a third party plugin that would allow us to perform incremental backups over the S3 protocol to ensure the best performance. While working toward that effort, we opted for rsync with the --delete flag to hold us over. The --delete flag, if you're unfamiliar, simply means that if files are removed on the primary server, rsync would remove them from the backup server as well (ensuring that old and deleted data did not stay in the backups).

As of today we've begun using DirectAdmin's built-in backup system, and while not ideal, will mean that we will more consistently have backups for accidentally deleted data, which is of value. Backups will, for the moment, be consistent and plentiful.

This is not likely the final backup system that we will use on the DA servers, given that full backups eventually cause a heavy hit to system performance as usage on the servers grow. We will continue to work toward the secondary goal of strong incremental backups (which only backup new changes each time).