Most spam filtering is about mail you never want to see. The Blocker module solves a different, quieter problem: mail you do want handled, but only after a person has looked at it first — outgoing mail to a competitor or a departed client's domain, mail containing certain content phrases that should be reviewed before it leaves the building, or mail from an address (an ex-employee, a specific external domain) that should never reach staff inboxes automatically.
This is closer to a lightweight approval workflow than a spam filter: block, store, alert someone, and let them decide whether it should go through, be returned, or be discarded.
Rule conditions cover both who the mail is to/from and what it contains:
- Sender or recipient lists — block by specific address, address pattern, or sender display name, with separate allow-lists and block-lists so exceptions are explicit rather than accidental.
- Content or subject phrases, including wildcards — hold mail containing specific terms that should be reviewed before sending or before reaching a mailbox.
- Missing phrases — the reverse: block anything that does not contain a required phrase, which can act as a simple "password in the content" mechanism for mail that should only pass with a known marker.
- Attachment type — hold or strip specific attachment types outright, useful for both security (executable attachments) and policy (large media files clogging mailboxes).
- Recipient count or message size — catch accidental mass-sends or unusually large outbound messages before they leave.
A hold is only useful if someone finds out about it and can act on it without digging through logs:
- Alert the right person when a message is blocked, and separately alert if the held-message store grows past a configurable size — a queue nobody is watching is not a review process.
- Store the message for later inspection, archiving, or resending, rather than silently discarding it — most "blocked" mail in practice needs a decision, not automatic deletion.
- Release, return, or forward — send it on if it was a false positive, return it to the sender with an optional reason, or forward it to a nominated reviewer's own mailbox.
- Configurable auto-reply to the sender, with or without disclosing the actual blocking reason, if you want the sender to know something happened without exposing your internal policy.
A few patterns SMEs and startups actually use this for:
- Outbound review for a specific team. Junior staff or a specific department's outgoing mail held for a second pair of eyes before anything client-facing goes out, without slowing down the rest of the company.
- Departed staff and known-bad domains. Prevent mail to or from a former employee's personal address, or a competitor's domain, without relying on everyone remembering not to CC them.
- Content policy enforcement. Hold mail matching known-sensitive terms (unreleased product names, specific client names on a confidential deal) for review rather than a blanket ban that also catches legitimate mentions.
- Attachment hygiene. Strip or hold specific executable or archive attachment types on the way in as a lightweight extra layer alongside antivirus scanning.
None of this is a substitute for a proper DLP (data loss prevention) product if that is a genuine compliance requirement at scale — it is a proportionate, rule-based review layer for teams that need "hold and check," not a full classification and policy engine.
The Blocker module in Hexamail Guard and Hexamail Nexus holds mail matching sender/recipient lists, content or subject phrases (including wildcards and "missing phrase" password-style rules), attachment type, size, or recipient count. It alerts a nominated person, stores the message for review, and offers return-to-sender, forward, or release actions from a maintenance interface — combined with the Developer API, that review decision can also be triggered from your own internal tools instead of the mail admin console.