Message tagging (spam/ham)

When you click Mark as spam or Mark as ham in a message's detail panel, MxGuard records your judgement against that specific message. This page explains exactly what happens, what it does, and what it deliberately does not do.

What happens immediately

1. Your label is written to the verdict_overrides table, keyed by message identity (timestamp + sender + recipient + size).
2. An audit log entry is created (actor, action, target).
3. A coloured badge appears next to the recipient on the row: marked spam or marked ham.
4. The button you just clicked hides itself so you can't double-label. The opposite button stays visible so you can correct yourself if you change your mind.

The "Mark as spam" confirmation dialog

When you click Mark as spam, a browser confirm dialog appears asking whether to also add a permanent block rule for the sender domain:

• Click OK — the spam label is recorded and a row is added to sender_rules with action='block'. From this point onwards, all future mail from that sender domain is rejected with a 5xx at SMTP time, for every customer. Use this for obvious spammers you never want to hear from again.
• Click Cancel — only the spam label is recorded. No block rule is added. Future mail from the same sender is still scored normally. Use this when you're labelling for training but the sender might be borderline.

What labels do not do

Labels are training data, not live filters. Marking a message as spam does not change how the current model scores future messages. The live model is the file shipped at last retrain. Your labels accumulate until the next retraining job runs, then they shape the next model.

The only way to immediately change how MxGuard treats a sender is to opt in to the "add block rule" option above, or add a sender rule manually. Labels alone are slow-acting.

Release and delete (quarantine actions)

For quarantined messages, two extra buttons appear in the detail panel:

• Release — delivers the held message to the recipient's mailbox. A blue released badge appears on the row, both queue buttons disable, and the row hides after 4 seconds.
• Delete — drops the message from the HOLD queue. A grey deleted badge appears, then the row hides after 4 seconds.

Release and delete act on the live Postfix queue. They don't write a training label by themselves — if you want to teach the model that a released message was ham, click Mark as ham as well.

Persistence across feed refreshes

The feed polls every 5 seconds for users and 30 seconds for admins. When the page refreshes:

• marked spam / marked ham badges survive — they're loaded from verdict_overrides in the database
• released / deleted badges are transient and don't survive refresh, because the row itself disappears from the queue

Retraining cycle

Labels feed into the LightGBM training pipeline. The training process joins verdict_overrides with the captured message bodies in bodies.jsonl, builds a fresh labelled corpus, trains a new model, and validates it against a held-out set. If the new model scores better than the current one (typically by AUC), it's deployed.

How often this runs depends on volume. With a handful of labels a day, it's worth retraining weekly. With hundreds, nightly. Speak to support about retrain scheduling for your account.

What kind of mail to label

The most valuable training labels are:

• False negatives — spam that MxGuard let through (verdict was clean or tag). Mark these as spam.
• False positives — legitimate mail that MxGuard held in quarantine or rejected. Release them and mark as ham.

Labels on messages MxGuard already scored correctly (clear-cut spam already rejected, obvious clean mail already delivered) are less useful — the model already gets those right. Focus on the edge cases where MxGuard disagreed with you.