# Message Rules # Message Rules Admin path: **Content Checks > Message Rules** (`view_message_rules.cfm`, `inc/get_message_rules.cfm`, `inc/apply_message_rules.cfm`, `inc/update_spamassassin_config_files.cfm`, `inc/restart_mail_filter.cfm`). This page maintains a catalogue of **custom SpamAssassin rules** that score against a regex match in a specific part of the message (header, body, raw body, full message, or URI). Every rule a row on this page produces is appended verbatim to SpamAssassin's `local.cf` as a ` ` line, paired with a `score ` line, and (optionally) a `describe ` line. SpamAssassin then runs the rule on every message that reaches the SpamAssassin pass inside Amavis. The cutoff that turns a final score into a `tag` / `quarantine` action is set globally on [Anti-Spam Settings](https://docs.deeztek.com/books/administrator-guide/page/antispam-settings); this page only writes the rules themselves. Message Rules is the body/header equivalent of what [File Extensions](https://docs.deeztek.com/books/administrator-guide/page/file-extensions) does for attachment names. Both ride into `local.cf` / `50-user` on save, both are validated with `spamassassin --lint` before the mail filter restarts, but File Extensions matches the trailing extension of an attachment filename while Message Rules matches arbitrary regex against text inside the message. ## Where Message Rules sits ``` +---------------------------------------+ Message Rules | message_rules table | (this page) -----> | id, rule_name, rule_type, header, | | regex, score, rule_desc, applied | +---------------+-----------------------+ | v +---------------------------------------+ | update_spamassassin_config_files.cfm | | renders every row as | | | | score | | describe | | substituted at ##CUSTOM-MESSAGE-RULES| +---------------+-----------------------+ | v +---------------------------------------+ | apply_message_rules.cfm | | spamassassin --lint | | restart_mail_filter.cfm | | (docker container restart | | hermes_mail_filter) | +---------------+-----------------------+ | v +---------------------------------------+ | /etc/spamassassin/local.cf in | | hermes_mail_filter; rules contribute| | to every message's total score | +---------------------------------------+ ``` A row added here only affects the SpamAssassin pass — it does not reject at SMTP-time, it does not modify headers directly, and it does not bypass content filtering for any recipient. It just adds or subtracts from the final score, and whether that final score crosses a quarantine threshold is decided by the recipient's [SVF Policy](https://docs.deeztek.com/books/administrator-guide/page/svf-policies). ## Rule types | Type | What it matches | Cost | | --- | --- | --- | | `header` | A specific message header (`Subject`, `From`, `Return-Path`, ...) or any header when `ALL` is set | Very cheap; runs against parsed header values | | `body` | The decoded plain-text body | Cheap | | `rawbody` | The raw/HTML body before SpamAssassin decodes it (good for catching CSS tricks, hidden text, encoded payloads) | Cheap | | `full` | The entire raw message including all MIME parts and headers | Most expensive; use sparingly | | `uri` | URIs extracted from the message body | Cheap; ideal for catching suspicious link patterns | The Page Guide on the page calls out `full` as resource-intensive because SpamAssassin runs the regex against the whole raw blob; a greedy or expensive regex in a `full` rule can noticeably slow every scan. Prefer `body`, `rawbody`, or `uri` where they cover the case. ## Score semantics The `score` value behaves identically to a [Score Overrides](https://docs.deeztek.com/books/administrator-guide/page/score-overrides) weight, except this page creates the rule from scratch instead of overriding a shipped rule: | Score | Effect | | --- | --- | | Positive (`5`, `20`, etc.) | Adds to the spam score on match. Higher values push the message toward `tag` / `quarantine` | | `0` | Rule still runs but contributes nothing — useful for keeping the rule in place during a tuning pass without firing it | | Negative (`-3`, `-10`) | Subtracts from the score on match — effectively whitelists messages matching the pattern | The validation accepts any numeric value in the range `-999 .. 999` (per the input's `step="0.01"` and `min`/`max` attributes). The SVF policy assigned to the recipient determines what `total score` threshold triggers tag / quarantine — see [SVF Policies](https://docs.deeztek.com/books/administrator-guide/page/svf-policies). ## The page A Page Guide callout, a collapsible **Regex Helper** card (three tools: rule builder, common-pattern picker, regex tester — all client-side JavaScript that just populates the Add form), an Add Message Rule card, and an Existing Message Rules DataTable. ### Add Message Rule card | Field | Stored as | Notes | | --- | --- | --- | | Rule Name | `message_rules.rule_name` | Required. Letters, numbers, dashes, underscores only — no spaces. Must be unique. SpamAssassin uses this as the rule identifier in logs (`X-Spam-Status` header reports rule names that fired) | | Rule Type | `message_rules.rule_type` | Required. One of `header`, `body`, `rawbody`, `full`, `uri` | | Header | `message_rules.header` | Required when Rule Type is `header`. Letters, numbers, dashes, underscores only. Datalist suggests common headers (`Subject`, `From`, `Return-Path`, ...) plus the special `ALL` token to match any header. For non-header rules the field is force-cleared on save | | Regex Pattern | `message_rules.regex` | Required. A SpamAssassin-format regex like `/keyword/i`. For `header` rules a `~ ` prefix is auto-added on save (this is the SpamAssassin `=~` operator notation `header_name =~ /pattern/`) and stripped on display so the operator sees only the regex | | Score | `message_rules.score` | Required, numeric, `-999 .. 999` | | Description | `message_rules.rule_desc` | Optional. Surfaced into the rendered `local.cf` as a `describe` line, which feeds the rule into SpamAssassin's "why was this scored" explanations | The handler validates each field in order and returns to the page with `session.m_rules = ` for the first failure (form values are preserved through `session.form_*` so the operator doesn't re-type). Successful insert sets `applied = 2` (pending) before the apply chain runs, then bulk-updates all rows to `applied = 1` once `spamassassin --lint` and the restart succeed. ### Regex Helper card Pure client-side, no server roundtrip: | Tool | What it does | | --- | --- | | Build a Rule | Pick "match in body / header / raw / URIs," choose Contains / Exact / Starts / Ends / Any-of, type the text, click Build. JavaScript escapes regex metacharacters and assembles a `/pattern/i` string | | Quick Select Common Patterns | A `