Why we removed the “deliver spam to spam folder” option for panel.mxroute.com

This is one of those changes that looks small on the surface and feels big if you relied on it.

For the average user, here is the simple version: removing this option reduces the number of ways your email can behave unexpectedly. The complexity behind that feature runs far deeper than most people realize. It has been one of the most frustrating parts of our service for years. It has led to confusion, feelings of lost mail, cancellations, and understandably angry users.

Maybe it comes back one day after we fully rewrite and redesign the logic behind it. Right now, there are too many structural problems tied to how it works. For the sake of reliability and clarity, it had to go. I am asking you to trust that this decision was justified and made in the interest of long term stability.

If you want the technical explanation, here it is.

The option to deliver mail to the recipient’s spam folder does not behave the way people assume it does in our current stack. The logic is rooted in legacy Perl code that we did not write. As we continue moving away from third party vendor logic, this is one of the areas where that old foundation becomes a liability.

There are actually two separate problems with this feature.

The first is architectural. Even when it is not outright breaking, it does not perform well in practice.

In order to meaningfully populate a spam folder, the scoring threshold has to be lowered. For most users, lowering that threshold means legitimate email will regularly be classified as spam. We do not operate like Google. We reject a significant amount of mail at the SMTP layer and do not accept large volumes of mail that we already know to be spam just to sort it later. The mail that makes it through to SpamAssassin often shares scoring ranges with legitimate mail. There is not much clean separation.

That means if you tune the system aggressively enough to keep the spam folder active, you will also put legitimate email in there. Not occasionally. Not rarely. Under most realistic configurations, you are looking at legitimate messages landing in spam constantly. For many users, that can mean multiple times per day.

A spam folder that quietly captures real mail every hour is not a feature. It is a liability.

The second problem is mechanical, and this is where things get worse.

If the recipient address is a forwarder without its own mailbox, and an incoming message is flagged to be delivered to that address’s spam folder, the alias cannot be fully expanded in the way you would expect. Instead of delivering to the spam folder of the actual destination mailbox, it defaults to the spam folder of the Linux user account that owns the domain.

For example:

If forwarder@mxroute.com only forwards mail to jarland@mxroute.com and has no matching mailbox by that name, and the system is configured to deliver spam to the recipient’s spam folder, you would reasonably expect it to land here:

/home/linuxuser/imap/mxroute.com/jarland/Maildir/.INBOX.spam

Instead, it lands here:

/home/linuxuser/Maildir/.INBOX.spam

That location is tied to the system level Linux user, not the mailbox. The only way to access it is by visiting:

https://yourserver.mxrouting.net/webmail

Then logging in as the Linux user with the DirectAdmin password.

It never reaches jarland@mxroute.com. I will not see it in the mailbox. The only way to find it is to know that this hidden location exists and go looking for it manually.

That is not acceptable behavior for a modern email service.

Explaining this to someone who just wants email to work is not reasonable. It violates expectations. From the user’s perspective, the feature is broken. No one should ever have to be told to log in as their system user to retrieve mail that was addressed to a mailbox.

We have spent years simplifying the experience, building a more coherent control panel, and removing layers of inherited complexity. Leaving this behavior in place undermines that effort. It creates confusion and erodes trust.

For now, the function has been removed from panel.mxroute.com. If you still access DirectAdmin, you will see the option there. I understand that its removal may be frustrating if you relied on it. However, when weighing ongoing confusion and support friction against removing the feature entirely, this is the most responsible choice available to us today.