---
title: Strategy options
description: The three realistic strategies, including the one we advise against.
icon: GitBranch
---

The decision behind everything else on this subject. Context: recurring
virus-infection attempts by email on a shared-hosting account with 87 mailboxes.
Three strategies were realistic on this platform. This is what each would have
cost.

## Option A: Score-based filters and a central quarantine

**Chosen.**

Account-wide rules on the SpamAssassin score. That score is computed on the
*decoded* message, which is the property that matters here: malware hidden in
Base64 cannot escape it by being encoded.

Suspect mail is parked in one central
[Quarantine folder](/docs/it/email/quarantine-folder) that an administrator
reviews. A rule only graduates to permanent deletion after seven days with zero
false positives.

- **Zero mail loss by construction**: quarantine first, whitelist on top.
- **Nothing changes for the 87 users.** Their daily flow is untouched.
- **One place to review, one place to tune.**
- **No outgoing side effects**: no bounces, no reputation risk.
- Costs about two minutes a day of review during the observation window, then a
  quarterly purge.

## Option B: BoxTrapper

**Advised against.**

Every unknown sender receives an automatic "confirm you are human" message, and
their mail is held until they click.

- **Backscatter.** Spam senders forge their address, so the confirmation requests
  bombard innocent third parties. This is what gets a server blacklisted, and it
  is the exact mechanism being removed from the legacy filters.
- **Silent mail loss in practice.** o2switch's own documentation warns that many
  providers filter the confirmation emails out. The legitimate sender never sees
  the challenge, and their message waits in a queue nobody watches.
- **Eighty-seven queues.** Each user would have to monitor their own trapped mail.
- **Hostile to normal business.** Every new customer or supplier hits a wall on
  first contact.

Its one merit is aggression against low-effort spam. It does not come close to
paying for the rest.

## Option C: Status quo

Keep only the o2switch antispam sorting into each user's Spam folder.

- No administrative work.
- Under-scored malware keeps reaching inboxes, which is the problem that started
  all this.
- The legacy filters keep sending backscatter bounces.

## What was decided

**Option A**, with the legacy-filter cleanup done regardless of the option chosen.
That cleanup is not optional in any scenario: the old filters were damaging the
server's reputation on every spam they caught.

Option B is written down rather than dismissed silently, because it is the option
a hosting panel makes look attractive: it has a checkbox, and it appears to do
something. Both o2switch's documentation and ordinary deliverability practice
argue against challenge-response on a business domain.

## See also

- [Deployment runbook](/docs/it/email/deployment-runbook), how Option A was carried out
- [Current configuration](/docs/it/email/current-configuration), where it stands today