Two independent systems, configured separately. The classifier judges individual messages as part of the spam score. The advisor reviews your mail flow periodically and proposes configuration changes. Both are off by default, and both can run against a model hosted entirely inside your own network.
1. The message classifier
For each inbound message, the appliance sends a compact summary to a language model and asks for a structured verdict: a category, a threat score, a confidence score and a short reason. It is one weighted signal among many — not a verdict on its own.
Why it is calibrated, not just prompted
The obvious implementation asks “is this spam?” and gets a model’s opinion of whether mail is wanted, which is not the same question and produces a filter that eats newsletters and invoices. This one is instructed explicitly that legitimate marketing, newsletters, transactional notifications and ordinary cold business outreach are not spam, and that high threat scores are reserved for messages that are deceptive, impersonate a brand or person, try to steal credentials or money, or carry malware.
It then classifies into one of six categories — phishing, malware, scam, spam, marketing, legitimate — and only the first four count as a hit. The score and confidence are separate on purpose: a model that is unsure should not move your threshold.
Thresholds
| Setting | Default | Meaning |
|---|---|---|
| Threat threshold | 75 | Minimum threat score (0–100) to count at all. |
| Minimum confidence | 60 | Below this the verdict is ignored regardless of threat. |
| Weight | 4 | Added to the spam score on a hit. Default spam threshold is 6. |
| Timeout | 8 seconds | On timeout the check yields no opinion. |
With the defaults, a classifier hit alone does not quarantine a message — weight 4 against a threshold of 6. It needs corroboration from another signal. That is intentional: it means a model error cannot quarantine mail by itself. Raise the weight above the threshold only once you trust it in your environment.
It always fails open. A timeout, an unreachable endpoint, an expired key, a malformed response — any failure yields no opinion and the message proceeds on its other signals. An AI provider outage cannot stop your mail.
It learns from your quarantine
Every message an administrator releases from quarantine is recorded as a labelled example of legitimate mail for your organisation. Those examples are then included in subsequent classification requests — six by default — so the model calibrates to what your business actually receives.
No training, no fine-tuning, no data retained by anyone: the examples live in your database and are sent as context with each request. You can also supply written guidance describing your organisation, which is included in the same way — for example naming the industry terms, suppliers or transactional senders that generic filters routinely misjudge.
What is sent
Per message: the sender, the subject, and the body truncated to 4,000 characters, plus your guidance and examples.
With a hosted provider, that message content leaves your infrastructure. It is the one place in the product where anything does. If that is unacceptable for your data classification — or your customers’ — use self-hosted inference below and it never happens.
2. Self-hosted inference
The classifier speaks two protocols: the Anthropic messages API, and the widely-implemented OpenAI-compatible chat completions API. The second is what matters here, because it is what local inference servers expose. Point the endpoint at your own server and no message content crosses your network boundary.
| Setting | Value for a local server |
|---|---|
| Provider | openai |
| API base | Your endpoint, e.g. http://10.0.0.20:11434/v1/chat/completions |
| Model | Whatever your server serves |
| API key | Any non-empty value — see below |
The API key field must not be left blank, even when your server ignores authentication. The classifier treats a missing key as “not configured” and returns without calling anything — so the feature appears enabled and silently never runs. Put any placeholder in the field. This is the single most common configuration mistake with a local model.
Both AI systems can share one endpoint: leave the advisor’s connection fields blank and it inherits the classifier’s. Give the advisor a larger or slower model if you prefer, since its calls are far less frequent and it has a longer timeout.
Because the request is a plain HTTP call with no vendor SDK, anything presenting an OpenAI-compatible endpoint works — a local inference server, a self-hosted gateway, or a private deployment from a cloud provider inside your own tenancy.
3. The tuning advisor
Filtering products are usually mistuned in one direction and nobody notices until a customer complains. The advisor exists to close that loop: it periodically reviews a summary of recent mail flow together with your current configuration, and proposes bounded changes.
Two modes
- Overseer (default) — proposals are queued for an administrator to approve or reject. Nothing changes on its own.
- Autopilot — approved-by-policy changes are applied automatically, within the guardrails below.
The guardrails
These are the reason autopilot is a reasonable thing to turn on:
- A restricted set of settings only. Booleans, bounded numbers and fixed choices from an explicit catalogue. It cannot touch credentials, transport or TLS settings, mail routing, or any free-text field.
- Changes that weaken protection are never auto-applied. They can only ever be proposed for a human to approve.
- At most five changes per run, and only proposals at or above 70% confidence.
- It verifies itself and reverts. After applying a change it snapshots mail flow for six hours, and automatically rolls the change back if the quarantine release rate exceeds 3% or the block rate jumps by more than 0.2 points — i.e. if good mail started being caught.
- Blocklist entries are held to a higher bar than settings: 90% confidence and at least five flagged messages, so no single message can get a sender blocked.
- Every run and proposal is recorded with its before-and-after metrics, and remains reversible.
Data minimisation
The advisor summarises up to 500 sampled messages per run. Subjects of flagged mail are included; message bodies are excluded by default. Leave that setting alone unless you are running fully self-hosted inference — it is the difference between sending a statistical summary and sending your customers’ correspondence.
Enabling it
- Spam → AI classification. Choose provider, endpoint, model and key. Save, then watch the mail log: classifier hits appear as a scoring reason, so you can see what it is contributing before you rely on it.
- Leave the weight at 4 initially. It cannot quarantine on its own at that weight, which makes the first week observation rather than enforcement.
- Write your organisation guidance. This is the highest-value field on the page and usually the difference between a useful classifier and a noisy one.
- Release from quarantine as normal. Each release becomes a calibration example automatically.
- AI → Autopilot, in overseer mode. Review its proposals for a few cycles before considering autopilot.
Licensing. The AI classifier and the tuning advisor are Enterprise features. The rest of the filtering stack — weighted scoring, DNSBL, SPF and DKIM alignment, content heuristics, Bayesian filtering, DMARC, greylisting, anti-malware and attachment policy — is not gated on them.