Today we launched the new server named Blizzard. New orders will be provisioned on this server.
We've identified several rejection messages that could potentially indicate the need to retry later or from a different IP, but should be limited a bit further than they've been in how long they'll sit in queue and retry for. Basically, we've determined that if an email has failed delivery from 4 different IPs while returning one of a few different error messages, those emails did not benefit from sitting in queue for up to 3 days (and were destined for failure no matter how long we retried them). Most of these will be self-explanatory in their bounce messages and we don't need to inform you of it, but there's one we wanted to get out in front of:
Google: "Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been temporarily rate limited."
When Google returns this message, we all hear "That IP has sent too much spam, the reason this was rejected is because of how Google views that IP address." The thing is, this isn't always correct. There are emails that Google will consistently reject with this error no matter what IP they come from. They might return this error and accept another email from that same IP just seconds later. Basically, Google is not always being truthful in their message. Regardless of that, we still retry emails that return that error from 4 different IP addresses, in up to 3 different IP ranges. However, we now stop there. If after trying delivery from 4 IPs an email continues to return this message, we are bouncing it back to the sender. We've determined that at this stage there is no benefit to continuing to hold it in queue for up to 3 days as that email will always return that error no matter what, and will never be accepted by Google. In our review of this scenario over the last two months, 100% of the emails that qualified for this scenario were forwarded emails from Twitter, that's really all we're talking about here.
The SpamAssassin Setup link was changed to Rspamd Setup in DirectAdmin on Arrow and Echo servers.
The latest version of exim isn't working with our custom transport, causing failure to sign DKIM messages. If you noticed this recently on the Arrow server, this has been fixed.
We've deployed rspamd in replacement to spamassassin on the Arrow server. This may change some of the email headers used for spam filtering by the server. The "SpamAssassin Settings" page in DirectAdmin is expected to function normally.