Customizing the mailbox spam filter settings
Note for Business Customers: These settings must be enabled by your administrator via the management interface.
The spam protection at mailbox is already optimally configured for you. However, if you still wish to deactivate individual components, please make sure to read more about how each mechanism works [here] before proceeding.
You can find the configuration of your spam filter in the web client under:
All Settings | Spam and Trash | Spam Settings
To simplify the explanations below, we use the following technical terms in this article:
- Client: The system that connects to our servers and attempts to deliver an email — for example, another mail server or a spam/virus botnet.
- False Positive: An email that was incorrectly classified as spam.
- False Negative: A spam email that was not detected.
If an email is detected as spam by our systems, it will be rejected — meaning our server refuses to accept the message. In this case, the sender’s system (the client) generates a bounce notification back to the sender.
As a result, the sender will always be informed by their own provider about the failed delivery attempt.
This bounce mechanism works in the same way as if someone had tried to send an email to a non-existent recipient.
The settings are divided into two main areas
Figure 1: Spam filter settings.
The technical filters section refers to filtering that takes place at the protocol level — in other words, before the server actually “sees” the email message.
The content filters section refers to filtering based on the email’s contents, checking for known patterns commonly used in spam. This also occurs before the message is ultimately accepted or rejected. Whether a detected spam message is directly rejected or moved to a designated folder can be customized according to your preference.
If you'd like to receive suspected spam in a dedicated folder, select "Junk".
Important: The options under technical filters always result in rejection (except for greylisting, which causes only a temporary rejection), even if content filtering is configured to move detected spam into a subfolder.
Greylisting as spam protection
With greylisting, the mail server temporarily rejects incoming mail from unknown clients. Our mail server sends a busy signal — just like a fax machine encountering a busy line. After five minutes, the client is allowed to attempt delivery again. Once a repeat attempt is made, the email is accepted.
This method does not block or bounce the message permanently, so there is virtually no risk of email loss due to this technique.
Why is this done?
Spammers and (virus-driven) botnets often have technical limitations or no interest in retrying message delivery. Legitimate mail servers, however, are used to busy signals and will retry — often for unrelated reasons during normal operations.
Known mail systems from previous successful transactions are no longer greylisted, meaning over 98% of all legitimate emails are delivered without delay.
Our recommendation: Keep greylisting enabled.
SMTP Plausibility Check
This test verifies whether the hostname provided by the sender's client (e.g., "I am mailbox") matches the hostname associated with the sender's IP address according to DNS — a procedure known as Reverse DNS Lookup. According to RFC standards, these strings must match exactly for proper mail server operation. Spammers and botnets often falsify this information to gain advantages.
In rare cases, legitimate but misconfigured mail servers may cause issues. If administrators of these servers have entered incorrect hostnames, and other factors are present, it is possible that such a mail server may be blocked in isolated cases.
The SMTP plausibility check is essentially the only spam filter that can result in false positives. User reports about false positives almost always originate from this check.
Summary
Risk of false positives: low but existent
Our recommendation: Disable the SMTP plausibility check only if you notice certain emails are not being delivered.
Realtime Blacklists (RBL)
RBLs are publicly accessible databases that list clients currently identified as spam sources. Mail providers can query these databases to protect their users.
These spam-sending clients may include virus-infected PCs, compromised servers, or mail servers with hacked user accounts. Because of the danger posed by mass spam distribution, such messages must be blocked or not delivered.
We view many RBLs critically, as there are countless blacklists out there — some of which follow overly aggressive or questionable listing practices.
At mailbox.org, we rely on only three or four well-respected RBLs, commonly used by major providers. These operate very conservatively and only list clients involved in concrete, ongoing incidents. No entries appear on our selected RBLs without reason, although even legitimate mail servers may be blacklisted temporarily if they are actively distributing spam or viruses.
Summary
Risk of false positives: very, very low
Our recommendation: Keep Realtime Blacklists enabled at all times.
Content Spam Filter
The content spam filter uses the well-known software SpamAssassin, which calculates the likelihood that an email is spam based on technical and content-related characteristics. If the likelihood is too high, the email can either be rejected or redirected to a specific folder.
We offer the following configuration options:
- Cautious: The risk of false positives is virtually non-existent, but more spam emails ("false negatives") may get through.
- Normal: The optimal balance between blocking the most spam and minimizing the risk of false positives, based on years of experience. This is our clear recommendation.
- Strict: Emails are classified as spam more aggressively. This blocks more spam, but also increases the risk of false positives.
Our recommendation: Use the "Normal" setting.
Block Executable Attachments
By default, mailbox.org blocks suspicious filenames (e.g., Windows files with double extensions), as these are almost always dangerous and rarely used for legitimate purposes.
Executable files attached directly to emails are also blocked due to the high risk of virus infections via trick emails. However, executable files inside a .zip
archive are allowed, as the risk is much lower.
If you disable this mechanism, all file attachments will be delivered, regardless of type.
Please note: Attachments detected as infected by major antivirus scanners will still be blocked.
General Summary
Risk of false positives: minimal, almost never affects legitimate emails.
Our recommendation: Keep this option enabled at all times due to the high risk of viruses.
Trainable Spam Filter
If you are still receiving spam despite all other measures, you can easily train a personal spam filter.
To do this, first select the corresponding message. Then click on the "Spam" icon:
Figure 2: Spam filter.
Alternatively, you can simply move the message to the Spam folder. This will also trigger the training process. If you made a mistake, just move the message back to the inbox.
About training effectiveness: The filter may require a certain number of examples before it reliably detects similar spam messages. The success of the training also depends on the content of the messages.
Blocking Unwanted Senders
If you regularly receive unwanted messages from a specific sender, you can block their email address using a blacklist. You will no longer receive their messages.
To do this, go to:
All Settings | Spam and Trash | E-mail Blacklist
Enter the sender’s address and click Block.
Conclusion
The only component of the mailbox.org spam protection that may cause issues is the SMTP plausibility check. We have not received any significant support tickets regarding other components of the spam protection system.
Therefore, we understand if you choose to disable the SMTP plausibility check when necessary.
Important: We strongly recommend keeping all other components enabled.
Please note: Effective spam protection always relies on the interaction of many different mechanisms. Only this way can the risk of false positives be minimized. We kindly ask for your understanding that we cannot accept complaints about insufficient spam protection if individual components of the system were disabled.