Rules
What happens to mail as it arrives.
Rules tools
| Tool | What it does |
|---|---|
| listRules | Every rule on the active connection, in the order they are evaluated, with what each one does and how often it has fired. |
| getRule | One rule in full: its conditions, its actions and whether it is on. |
| createRule | Write a rule: conditions over an arriving message, and what should happen to anything matching them. The rule is created DISABLED. |
| testRule | Which of the last thirty days’ messages a rule would have caught, and what it would have done to them. Changes nothing. |
| setRuleEnabled | Turn one rule on or off, once a person has read it back. |
createRule writes the rule DISABLED, which is the one place this server deliberately differs from the REST API. POST /rules defaults to enabled. A rule that archives, trashes or forwards mail should not start doing it on the strength of a chat message: write it, call testRule to show the person you are working for which of their own messages it would have caught, and only then ask for setRuleEnabled.
There is no updateRule, no deleteRule and no reorder, for the same reason there is no template deletion: those are the operations that break somebody else’s setup from inside a chat window. A deleted rule cannot be restored, and a reorder silently changes what every future message does. All three are in Settings → Rules and on the REST API, where a person is the one clicking.
Rules belong to the CONNECTION, so these act on whichever mailbox setActiveConnection last named, and a rule a colleague wrote is one of them. A mailbox holds 100 rules, each with at most 20 conditions and 10 actions.
Nothing here is retroactive. A rule decides what happens to mail arriving after it is enabled; it does not sweep a mailbox that already exists, and testRule reports rather than files.