Spam filtering is one of the few places where a mail provider has to look at a lot of mail. That creates a temptation to learn from everything: which messages each user opens, which they move to folders, which links they click. Those signals improve accuracy, but they also build a behavioural profile of every mailbox. A filter can be effective without doing that. The choice is about what the filter is allowed to look at, and what it is allowed to remember.
Decide on the message, not the recipient
The principle is simple. Decisions should depend on properties of the connection and the message: the sending server, its authentication results, the structure and content of the message. They should not depend on what a particular recipient did with earlier mail. Once a filter starts keying decisions to individual behaviour, it needs to store that behaviour, and the store becomes a record worth protecting.
Connection-level checks
The cheapest checks happen before the message body is accepted. A server can reject connections that do not speak SMTP correctly, enforce rate limits per source, and consult DNS-based blocklists such as Spamhaus lists, which publish reputation for IP addresses. Blocklists are fast and effective against known bad infrastructure, but they can also block legitimate mail that shares an address space with abusers. Use them as one signal, with a reason to recheck when a legitimate sender reports being blocked.
Greylisting
Greylisting, described in RFC 6647, temporarily rejects mail from an unknown combination of sending address, envelope sender and recipient. A legitimate mail server queues the message and retries after a delay, and the retry is accepted. Many spam systems do not retry, or do not retry soon enough. Greylisting needs no content analysis and no user data beyond the triplet itself.
It has costs. The first message from a new sender arrives late, which some people find unacceptable for time-sensitive mail. Senders that use pools of outbound addresses can retry from a different address and be deferred again, so implementations usually match on subnets. The triplet store is also a record of who writes to whom. Keep it small, expire entries quickly, hash the values if you can, and do not log them beyond what operations requires.
Authentication and reputation
SPF, DKIM and DMARC give the filter a verified claim about the sending domain. A message whose DKIM signature aligns with its From domain, and whose domain publishes a DMARC policy, can be scored differently from an unauthenticated message claiming the same name. For background on those records, see SPF, DKIM and DMARC explained.
Reputation can then be keyed to sending domains and IP addresses, not to recipients. A domain that repeatedly sends unsolicited mail to many accounts builds a poor reputation that applies to all of them. The reputation data describes senders. It says nothing about what any individual user did, which keeps the profile on the sending side of the exchange.
Content rules
Content analysis looks at the message itself: headers, structure, URLs, known phrases and image-only layouts. Rule-based engines such as SpamAssassin and rspamd score messages against a shared rule set and combine the scores into a decision. The rules are the same for everyone, which is a feature for privacy and a limit for accuracy.
Statistical classifiers, such as Bayesian filters, learn token frequencies. Trained on a shared corpus of known spam and legitimate mail, a classifier is a global model. Trained on each user's own folders, it is a per-user profile of that person's mail. Both are legitimate engineering choices, but they are different privacy decisions, and the second should be made explicitly and disclosed.
Leaving control with the user
Where personal preferences matter, give the user the rules rather than learning them silently. Sieve is a standard mail filtering language, and it runs on the server in a form the user can read and change. ITProMail makes Sieve available on the Operator and Shadow plans. A simple rule that files messages already tagged as spam by the server looks like this:
require ["fileinto"];
if header :contains "X-Spam-Flag" "YES" {
fileinto "Junk";
}
The user decides what is junk, and the decision is visible in the script rather than hidden in a model.
Tradeoffs to accept on purpose
- Without per-user learning, some false positives will persist. Give users an easy way to report and release mail.
- Quarantine is safer than rejection for uncertain messages, but it means the operator holds mail. Set a retention period for quarantined messages and keep it short.
- Avoid bounce messages to forged senders, which create backscatter. Reject during the SMTP conversation where possible.
- Log decisions, not content. A line showing that a message scored a given value is enough for debugging.
Filtering without profiling is slightly less accurate than filtering with full behavioural history, and it is much easier to explain to the people whose mail is being filtered. For how the platform approaches privacy more broadly, see the security overview.