Filters and Rules That Hold Up

Time: about an hour to write five rules. Repeat: ten minutes every few months.

A rule written against the subject line breaks the first time the sender redesigns a template, which for a marketing team is a normal Tuesday. A rule written against the sending address survives, because the address is infrastructure and changing it costs the sender real money. That single difference explains most of the rules people abandon.

Match on the sender, not on the subject

Build every rule you can on the address the mail comes from. Subject lines are copy: they get rewritten by whoever is running the campaign this quarter, they get localised, they get A/B tested, and each of those events silently kills your rule. Nothing tells you the rule stopped matching. The mail simply reappears in the inbox and you assume you never wrote the rule at all.

Sending addresses change too, but rarely, and usually at a visible moment such as a company moving mail platforms. Where the sender is not stable enough, go one level lower and match on a header rather than on visible text: bulk mail carries a List-Id header that identifies the mailing rather than the wording. Most providers will also match on the sending domain when the part before the at sign rotates, which catches every address a large sender uses.

Learn the four parts of a rule

Every rule engine, whatever it calls things, is built from the same four pieces, and understanding them removes most of the surprises.

The condition. What is being compared, and how: contains, is exactly, matches the domain. Vague conditions catch too much, and you find out months later.

The action. Label, move, mark read, forward, delete. Several can apply at once, and the combination of "mark read" with "move" is how mail disappears without you ever having seen it.

The position in the queue. Rules run in order, top to bottom, and the order is part of the logic even when the interface hides it.

The stop flag. Usually worded as "do not apply further rules". It ends processing for that message. Without understanding this flag you cannot reason about anything below it.

Write the five rules that pay for themselves

Five rules cover the traffic almost everyone has, and each is worth writing out with its exact condition.

Anything carrying a List-Id header goes to the reading folder. That header is added by the software that sends bulk mail, so one rule covers every list you are on, including the ones you have not met yet, and it names no companies at all.

Mail from your bank, your registrar and your employer skips everything and stays in the inbox, marked important. This one is defensive: it stops a broader rule below from swallowing something urgent.

Receipts and order confirmations go to your keep folder. Match on the sending domains of the shops and payment services you actually use, not on the word "receipt", which appears in marketing constantly.

Automated notifications from one system go to their own folder. Ticket systems, build servers, monitoring, calendar invitations from software. High volume, low individual value, read in batches.

Everything from a sender you have blocked once goes to the folder for that decision. Not the inbox, and not silently deleted either, which matters when a sender keeps mailing after you asked them to stop.

Where each of these lands is a question about how your folders are laid out, and the rules should be written after that decision, not before.

No rule is cheaper than mail that never reaches you. A one-off code for a file you are downloading once needs neither a rule nor a folder if it goes to a mailbox that deletes itself instead of into the account you keep.

Put the catch-all rule last

Any rule that acts on a broad condition belongs at the bottom of the list, below every specific rule you have. Rules are evaluated in order, so a broad rule placed high will grab messages that a later, more precise rule was written to handle, and the precise rule will never fire.

The stop flag is what makes ordering usable. On a specific rule it means "this message is dealt with, do not let anything below touch it", which is what you want on the rule protecting your bank mail. Set carelessly on a broad rule, it makes half your other rules stop working, and nothing in the interface points this out. Read your list top to bottom once and ask, of each rule, what it would do to a message intended for the rule beneath it.

Test a rule with a label before it moves anything

Apply a new rule as a label only, leave it running for a week, then add the move. This is the cheapest safety measure in mail and hardly anyone uses it.

A rule with a move action fails invisibly: if the condition is wider than you thought, mail leaves the inbox and you find out when somebody asks why you never replied. A label leaves everything in place, so after a week you can see what got tagged wrongly and fix the condition with nothing lost.

The same care applies to delete actions, which deserve a stronger rule: do not write them at all. Move to a folder that you empty on purpose. A rule that deletes is a rule you cannot audit.

Build rules on the server, not in one program

Put rules in your provider's web interface, not in a desktop mail program, because server rules apply on every device and desktop rules apply only while that computer is running. The symptom is familiar: a tidy inbox on the laptop and a chaotic one on the phone. That is not a sync problem, it is two sets of rules, one of which was only ever running on one machine.

A rule that appeared in your account and that you did not write is a different matter entirely. An unexplained forwarding rule is the classic sign that somebody else has been in the mailbox, and it is the first place to look when you suspect an account has been broken into.

Retire the rules that stopped earning

Once every few months, look at what each rule has caught. A rule that has matched nothing since you wrote it is either broken or aimed at a sender who has gone away, and either way it is noise in a list you need to be able to read. Delete it.

A rule that caught something you were waiting for gets fixed the same day, not added to a list. That failure will repeat, and the next message it eats may be one you cannot ask the sender to resend, which is often how wanted mail ends up somewhere you never look.

Rules do not travel between providers. Before any move, write yours down as plain text, because there is no export and rebuilding them from memory takes an evening. The same file is worth having if you run a shared household mailbox, where more than one person needs to know why mail moved.

The checklist

• Write conditions against the sending address or a header, never against the subject line.
• Add the five standard rules, and place the protective ones above the broad ones.
• Set the stop flag deliberately, and read the whole list top to bottom once.
• Run every new rule as a label for a week before letting it move anything.
• Never write a rule that deletes; move to a folder you empty yourself.
• Create rules in the provider's interface so they apply on every device.
• Every few months, delete rules that caught nothing and fix any rule that caught the wrong thing.