Triage & Investigation

Define capture rules based on symbols, scores, or header patterns. Stream entries appear in the Mail Streams viewer with full message detail: decoded body, MIME structure, headers, and scan results.

The Ask LLM panel sends the captured message to your chosen model with a curated preset or custom prompt. Responses are cached so repeat lookups are instant.

Show me all the messages my classifier got wrong. What does this phishing campaign look like? Why is this sender hitting my custom rule?

Streams let you curate investigation queues. The LLM integration accelerates analysis: explain the verdict, classify the pattern, suggest improvements.

The Ask LLM panel offers curated presets — explain a verdict, explain a suspected false positive, surface a missed-spam signal, or suggest a rule — plus custom prompts. The model receives only the decoded message and its scan results, never raw payloads.

An approval queue for corrective actions: block this sender domain, add this address to a blocklist, ship this composite rule. Auto-triage and the campaign judge file proposals here instead of touching your filter. In the product's own words — nothing runs until approved.

Each row shows who proposed the action and with what confidence, what the action would do, and how often it has been proposed. Approve it and it goes through the rescan-verifying remediation engine; every applied action is revertible.

Before an operator ever sees a proposal, a second, adversarial model reviews it — accept, unsure, or reject, with a confidence. It is configured to be a different model from the one that proposed the action, so the reviewer isn't marking its own homework.

The result is a queue where the easy calls are obvious and the contested ones are flagged for you.

What does the system want to change, and should I let it? Which of these proposals do two independent models agree on?

Automation you can audit: the LLM proposes, a second model challenges, a human approves.

Campaigns clusters slipped (non-rejected) mail by sender domain, ranking campaigns by near-misses — messages that came close to rejection but slipped through.

Instead of triaging 500 individual messages from the same attack, you see one campaign row. One campaign = one decision: investigate, learn fuzzy, add to a map, or dismiss.

What's hitting us repeatedly? Which campaigns are trending? What nearly got caught?

The campaigns panel surfaces the needles in the haystack: coordinated attacks that spread across many messages but share a sender domain or pattern.

The LLM-assisted campaign judge evaluates samples from a whole campaign at once. It returns a verdict plus one-click actions (train Bayes/neural, fuzzy-enqueue, add to map) — applied across the campaign.

Greylisting already delays borderline mail and asks the sender to retry. Second Chance spends that waiting time productively: while a message sits parked, an enrichment worker forms a verdict on it — from an LLM, from cluster evidence, or both — and the retry is decided with information the first scan never had.

Fail-open by design: if no verdict arrives, the retry simply re-scans against reputation feeds that have had time to catch up. You are never worse off than plain greylisting.

Second Chance is armed by enabling the greylist action threshold — an override applied live through Score What-If, not a config rebuild. Disarming is the same switch, and takes effect just as fast.

The panel shows what the window bought you: rescued spam (parked below the reject threshold, released at or above it), released-unchanged, and still awaiting retry.

A login or verification code that gets greylisted arrives after it has expired. A monitor on the same page detects code-bearing mail, tracks how much of it is being delayed, and learns the confirmed templates worth fast-pathing.

Detection runs in shadow: candidates are flagged and confirmed campaigns learned, but greylisting is not yet bypassed — you can see exactly what the bypass would do before you trust it with your transactional mail.

Rspamd Console provides queue management for Bayes, Neural, and Fuzzy learning. Queue entries by type, monitor queue depth, and drain on schedule instead of per-message.

The Learn Queues panel shows pending entries per queue, drain progress, and recent drain results. Schedule drains or trigger manually from the dashboard.

How many Bayes learn operations are pending? Did the last neural train succeed? Which fuzzy hashes failed to learn?

The queue overview gives visibility into learning state. Drain progress shows OK/fail/total counts so you can verify training succeeded.

Per-message learning adds latency. Batch learning lets you drain queues on your schedule — overnight, during low-traffic windows, or on-demand.

The dashboard exposes this via the Learn Queues panel. Configure schedules, monitor queue depth, and trigger drains from a single interface.