Why Spam Filtering Shouldn't Silently Delete Your Text Messages

Everyone wants spam filtering to be aggressive — right up until it gets one important message wrong.

A scam text slipping into your inbox is annoying.

A legitimate message from a doctor, bank, school, employer, delivery service, or another first-time sender disappearing without a way to review it can be much worse.

That is the tradeoff behind almost every spam-filtering system.

The goal is obviously to catch as much unwanted messaging as possible.

But an automated spam decision is still a decision.

And I do not think a messaging app should treat every one of those decisions as unquestionable truth.

Spam filtering is a judgment, not a fact

Some messages are obviously suspicious.

Others are much harder.

A message might come from a number you have never seen before. It might contain a link. It might be written in an unusual format. It might arrive from an automated system rather than a person.

None of those things, by themselves, prove that the message is spam.

That matters because legitimate text messaging often starts with an unfamiliar sender.

The FCC has specifically acknowledged that consumers expect wanted texts from numbers they may not recognize, including appointment reminders and two-factor authentication messages.

The wireless industry's own guidance makes the same broader point.

CTIA's messaging best practices talk about protecting people from unwanted messaging while still facilitating wanted traffic, including things like banking alerts, school notifications, medical messages, shipping updates, and appointment reminders.

That is a much harder problem than simply asking:

"Is this number in my contacts?"

Unknown does not mean spam.

And suspicious does not always mean unwanted.

False positives are a real part of the problem

Spam filtering usually gets discussed in terms of what it fails to catch.

A bad message reaches the inbox, so the filter must not be aggressive enough.

But there is another failure mode:

a legitimate message gets classified incorrectly.

Regulators account for this problem at the network level too.

When the FCC introduced rules requiring providers to block certain text messages that are highly likely to be illegal, it also required a contact process for senders whose legitimate messages were blocked by mistake.

The FCC refers directly to erroneously blocked texts.

That does not mean network blocking and app-level spam filtering are the same thing. They are not.

A carrier can stop a text before it ever reaches your phone.

A messaging app can receive a delivered text and then decide where to show it.

Those are different layers.

But the underlying lesson is useful:

even systems designed to stop abusive messaging need to account for mistakes.

There is no serious reason to assume that every automated classification will always be correct.

The cost of being wrong is not always equal

Suppose a spam filter misses one fundraising message.

You see something annoying.

You delete it.

Now consider the opposite mistake.

A legitimate first-time message is classified as spam and permanently destroyed before you ever know it existed.

Maybe it was only an advertisement.

But maybe it was an appointment reminder.

A verification code.

A fraud alert.

A school notice.

A recruiter trying to reach you.

A delivery update.

The point is not that these messages are constantly being misclassified. There is no good evidence for some universal false-positive rate, and I would not pretend there is.

The point is that the consequences of a false positive can sometimes be much higher than the consequences of letting one unwanted message through.

That is why recoverability matters.

Hiding a suspected message is different from destroying it

There is a useful middle ground between:

"show everything in the inbox"

and

"delete anything that looks suspicious."

You can separate suspected spam from the main inbox.

You can silence its notification.

You can make it less disruptive.

And you can still leave it somewhere the user can inspect later.

Major messaging platforms already use versions of this idea.

Apple's current Filter Spam documentation says its on-device spam detection places suspected junk in a Spam folder without notifying the user. Apple also provides a way to restore a message if it was categorized incorrectly.

Google Messages similarly provides a reviewable spam area and a Report not spam action for messages that were classified incorrectly.

Google's broader spam system is more complex and can also prevent some messages from being delivered, so these products should not all be treated as technically identical.

But the reviewable-folder pattern itself makes sense.

Suspected spam can be quiet without being irreversible.

That distinction is important.

Blocking someone and classifying spam are not the same decision

There is another difference I think messaging apps should respect.

When you manually block a sender, you have made an explicit choice.

You know which number you are blocking.

Maybe it is harassment. Maybe it is a persistent advertiser. Maybe you simply never want to hear from that sender again.

That is very different from software saying:

"I think this message might be spam."

One is a direct user instruction.

The other is an automated judgment.

Those two actions should not automatically have the same consequences.

This is also why endlessly expanding a manual block list is not a complete solution when unwanted messages keep arriving from different numbers.

I wrote more about that in Why Blocking Spam Texts One Number at a Time Doesn't Keep Up.

Manual blocking is useful when a particular sender is the problem.

Automatic spam classification is trying to solve a broader and less certain problem.

That deserves a little more humility.

Reviewable does not mean impossible to miss

There is an important caveat here.

Putting a message in a Spam folder is not the same as guaranteeing that the user will see it.

If a message arrives quietly without a notification, someone may still never open the Spam folder.

So reviewability is not a magical solution to false positives.

It simply avoids the more permanent failure mode:

the message existed, the filter was wrong, and there is now no way for the user to find it.

A reviewable spam folder gives the user another chance.

That is all.

And sometimes that second chance matters.

Spam filtering can happen on the device

Keeping suspected spam reviewable also does not require uploading an inbox to a cloud service.

Spam classification can happen locally.

Apple explicitly documents on-device spam detection.

Google Messages also uses on-device machine learning for parts of its spam protection, although Google's system additionally uses online services for some checks and processing.

The broader point is simple:

a messaging app can evaluate an incoming message on the phone itself.

You do not inherently need to send private message contents to a remote spam-scanning service just to decide that something looks suspicious.

For a private messaging app, that distinction matters.

How ZenSMS approaches it

ZenSMS takes a conservative, review-first approach.

Messages identified as likely spam are handled quietly, but they remain available in the Spam tab for review.

Automatic spam classification is also separate from manually blocking a sender.

ZenSMS performs its spam classification locally on the device. Messages are not uploaded to a ZenSMS server for cloud spam scanning.

And I do not claim that every spam decision will be correct.

That is exactly why suspected spam remains reviewable.

The aim is not to create the cleanest-looking inbox possible at any cost.

It is to reduce the noise while still respecting the possibility that an automated decision can be wrong.

A good spam filter should leave room for uncertainty

Spam filtering will always involve tradeoffs.

Make the filter too permissive and more junk reaches the inbox.

Make it too aggressive and you increase the risk of hiding something the user actually wanted.

There is no perfect setting that eliminates both problems.

So I think the safer design principle is straightforward:

when software is uncertain, reduce the disruption without pretending the uncertainty does not exist.

Filter the likely spam.

Keep it out of the way.

Let the user review it.

And make correction possible when the filter gets something wrong.

Because the best spam filter is not necessarily the one that makes the most messages disappear.

It is the one that reduces the noise without quietly taking control away from the person whose messages they are.