Spam, Junk and the Review Queue: Hold It, Don't Delete It

Tuesday, 09:30, at Harbourview Clinic. Amira on reception gets a message saying her mailbox storage is full and she must click a link within the hour to keep receiving appointment bookings. She does not click. She forwards it to helpdesk@example.com with one line: "Is this real?" Nothing comes back, not even the acknowledgment, and she assumes the desk is busy. At 09:50 Rowan in the pharmacy gets the same message and clicks. By 10:15 two more people have clicked. By 11:00 the clinic's mail administrator is resetting passwords. The desk is finding out, from Rowan, that there was a phishing message going round. Amira's forward never became a ticket. Four months earlier, during a wave of spam with exactly that subject line, a technician had added a screening rule: subject contains "mailbox storage is full", delete. The rule was still working perfectly.

Mail screening is the step between a message arriving in the desk's mailbox and a ticket being created. In that step, the tool decides whether the message is a request at all. Most of what it catches is harmless to lose: bulk mail, spam, delivery reports, the out-of-office replies covered in the loops article. Some of what it catches is a person, and the whole design question of screening is what happens to that person. The review queue is the answer this article argues for. It is a holding place where doubtful mail waits, not as a ticket and not deleted, until someone looks at it. This article is part of our Email-to-Ticket Done Right series. It is about the screening step: the three outcomes, the signals a rule can use, and the person who reads what was held.

It covers what arrives at a desk address that is not a request, then the three outcomes, block, allow and hold. Next come filtering on sender, subject and domain, and how each goes wrong. Then it covers why hold beats delete, why phishing reports are tickets, and who reviews the held mail and how. Next comes writing a rule that is still right next year. It ends with a short war story and the mail screening rules table to copy, in that order.

What Arrives That Is Not a Request

A mailbox accepts anything addressed to it, and a support address is on more lists than anyone at the desk knows. Four kinds of message arrive that are not requests. Automatic mail: out-of-office replies, delivery failures, read receipts, and other systems' acknowledgments, which are the raw material of loops and have their own article. Bulk mail: newsletters, vendor marketing, webinar invitations, the industry survey that found the support address on a website eight years ago and has never let go. Spam and phishing, which need no introduction and get one anyway below. And misdirected human mail: an invoice query meant for accounts, a job application meant for HR, a patient asking about an appointment because the clinic's address pattern made helpdesk@ look like a reasonable guess.

The fourth kind matters, because it is people. Nothing about an invoice query is junk. It is simply at the wrong address. The right outcome is a one-line reply pointing at the right one, not a ticket and certainly not a block. A screening design that treats everything non-request as junk will eventually treat a person as junk. The person will not know, because the one thing a blocked sender never receives is a message saying they were blocked. Junk is what nobody misses. The trouble is that the mailbox cannot tell you who would have missed it.

On a busy mailbox the four kinds together can outnumber the real requests. The triager pays for every one that gets through with a read, a decision and a close. The triage view of this, what the first touch does with an e-mailed ticket that turns out to be junk, is in Triage by Channel. The screening view is one step earlier: what should never have reached the triager at all, and what should have reached them with a note saying "a rule nearly held this".

Three Outcomes: Block, Allow, Hold

Every screening rule produces one of three outcomes, and the design of the whole thing is choosing which. Block means the message is discarded: no ticket, no acknowledgment, no record beyond perhaps a log line. Allow means the message becomes a ticket regardless of any other rule. It is the exception list, the senders who must never be held even if they look suspicious. Hold means the message is set aside, not a ticket and not discarded, in the review queue. There, a person approves it into a ticket or discards it. Most tools offer all three; some offer only block and allow; a few call hold something else, "quarantine" or "pending". Whatever the names, the three behaviours are what to look for.

The rule that keeps a desk safe is short. Block only what has never once been a person: a specific bulk-mail sender, a known spam address, the automatic-message patterns that detection recognises. Allow the senders you cannot afford to lose: your own organisation's domain, your main suppliers' support addresses, the monitoring systems that are meant to open tickets. Hold everything you are unsure about, which is most things a rule will ever match. The asymmetry is deliberate. A held message costs a person ten seconds in the review queue. A blocked message that was a person costs that person their request, and costs the desk the knowledge that it happened.

There is a fourth layer, and it is not yours. The organisation's mail server almost certainly has its own spam filter. What that filter quarantines never reaches the desk's mailbox at all. So the tool never sees it and no desk rule applies. That quarantine has a review queue too, somewhere, and somebody must own it in the same way. A requester whose message "never arrived" may be in the tool's held queue, the server's quarantine, or the processed folder. Knowing which three places to look is half of answering them. The other half is admitting there are three places.

Filters on Sender, Subject and Domain

A screening rule matches on a signal, and the signals differ in how safely they can be used. The sender address is the most precise: it matches one mailbox and nothing else, so a rule on it can only ever affect that mailbox. It is also the weakest against spam, which changes addresses faster than anyone can write rules. So a sender-address block is a good answer to a persistent newsletter and a poor answer to spam in general. The domain, everything after the @, is the most powerful signal and the most dangerous, because a domain is a whole organisation. Blocking a vendor's domain after a marketing blast blocks their engineers, their account manager and their support desk, including the one replying to your open ticket. A domain block is right for a bulk-mail service with no humans at it. It is wrong for anywhere a person might work.

Subject and body words are the signal people reach for first, and they are the one most likely to catch a person. A rule on "mailbox storage is full" caught Amira. A rule on "invoice" written during a wave of fake-invoice spam will catch the facilities manager asking why the printer-lease invoice system will not load. A rule on "unsubscribe" catches the requester asking how to unsubscribe from a mailing list. Words are what people write, and a rule that matches words will match people. If a word rule must exist, it holds. It never blocks. And it never applies to messages from inside the organisation, because a colleague forwarding spam to ask about it will carry the spam's subject line with them.

Attachment type is a quieter signal and a useful one. A message whose only content is an executable file, a script, or a compressed archive from an unknown sender is held. That is not because it is certainly malicious but because no requester has ever opened a ticket by sending an unexplained program. Images and documents are what requesters send, and they pass. Where the tool can screen on attachment type, this is the one rule that is nearly always right. Where it cannot, the mail server's filter usually does it. The attachments themselves, what the ticket does with them and what happens when they are too big, are in Attachments, Images and the Message That Is Too Big to Arrive.

One signal to resist is novelty. "Hold anything from a sender we have never seen" sounds cautious. It is a rule that holds every new employee, every new customer and every new supplier on the first day you hear from them. That is the day they most need an answer. New senders are the desk's normal business. Spam is new senders too, but so is the whole of next year's intake. A desk that holds the unfamiliar has decided its review queue is the real intake. Somebody should tell the review queue.

Hold for Review, Not Delete

The case for holding is one sentence: a wrongly deleted message is invisible, and a wrongly held one is not. When a block rule catches a person, nothing anywhere records that a person was lost. The requester gets no acknowledgment and assumes the desk is slow. The desk sees nothing and assumes the day is quiet. The rule, having done its job, is never questioned. When a hold rule catches the same person, the message sits in the review queue with the sender's name on it. The person reading the queue sees a human name among the junk and releases it, late by a few hours and alive. The cost of hold is the daily read. The cost of block is that you will never find out what it cost.

Two mechanics of holding are worth knowing in your own tool. First, find out how long held mail is kept before the tool discards it on its own. Some tools keep it for a fixed period; some indefinitely. The period should be long enough that a review missed over a holiday does not silently become a delete. Find out and write it on the setup sheet. Second, what time an approved message's ticket gets: the time the message arrived, or the time a person approved it. The first-response clock starts at the opening time. So a message held on Friday and approved on Monday either shows a weekend of waiting or hides it, depending on the tool. The desk should know which story its reports will tell.

Held mail is not a queue in the ticket sense, and it should not become one. Nothing in it has an owner, a priority or a status; it is a pile of letters waiting for a glance. Where a tool holds screened mail for a person to review, as QuerySolv does, the glance is a short list to approve or discard. The discipline is simply that someone glances every working day. The failure is not a bad rule. It is a review queue nobody has opened since the person who set it up changed jobs, holding, by now, a year of letters, some of which were requests.

Phishing Reports Are Tickets, Not Junk

A user who forwards a suspicious message to the desk and asks "is this real?" has done exactly the right thing. The desk's screening must be built so that the message reaches a person every single time. The report carries the phish inside it: the same subject line, the same words, and often the same link. Any rule written to catch the phish will catch the report. That is what happened to Amira. The desk had, with the best intentions, built a filter that deleted the early warning and let the attack through.

There are two reliable designs, and a small desk can do either in an afternoon. The first is a separate address for reports, phishing@example.com or security@example.com, feeding its own department or a queue with its own rules. There, the only rule is "everything from inside the organisation becomes a ticket". Users are told once, and reminded on the intranet, to forward suspicious mail there. The second, where a separate address is too much, is an allow rule on the desk's own mailbox. Under that rule, anything from the organisation's own domain is never held and never blocked by a word rule, whatever its subject. Either way, the forward from Amira becomes a ticket within a minute of her sending it. The desk knows about the phish before Rowan opens the pharmacy.

Treat the report as a ticket in full, because it is one. Thank the sender in the first reply, specifically, since people who are thanked report again and people who hear nothing stop. Assess the message, warn the organisation if it is a live campaign, and record what was done. And count the reports. The number of phishing reports per month is one of the few security measures a small desk can produce from its own data. A rising count is good news, because it means people are reporting rather than clicking. Everything about handling the phish itself, resetting credentials, checking what was clicked, belongs to the organisation's security practice rather than to this article. The desk's job is to make sure the report arrives. Deleting it is the one outcome that helps the attacker.

Who Reviews the Held Mail

The review queue is read by a named person, on a rota, at a fixed time every working day. It takes about ten minutes. Not "the team", because the team is the name of nobody in particular. The reviewer opens the held list, sorts it by sender, and makes one decision per message: approve it into a ticket, discard it, or approve it and note which rule held it. The last is the valuable one, because every approved message is a rule that was wrong about a person. A rule that is wrong often enough should change. The routine fits on a card:

• Open the held queue at the same time each day; sort by sender name.
• Approve anything from a person, inside or outside the organisation, into a ticket.
• Approve anything from a supplier or system that should have been allowed, and add the sender to the allow list.
• Discard bulk mail and spam; add the sender address, not the domain, to the block list only if it has recurred.
• For each approved message, write down which rule held it.
• Check the mail server's own quarantine, if the desk has access, for anything addressed to the desk.
• Post one line in the team chat: held, approved, discarded, and any rule flagged.

Weekly, the lead reads the flags. A rule that held twelve messages and had ten approved is a rule that is wrong about people ten times out of twelve. It is either narrowed, changed from block to hold if it was blocking, or removed. A rule that held thirty and had none approved is doing its job. The arithmetic is the rule's false-positive rate. It is the only honest measure of a screening rule. That is because the rule's author will always remember the spam wave that justified it and never the receptionist it caught. Monthly, the rule list is pruned: any rule nobody can explain, in one sentence, goes. The rule nobody can explain is usually the one holding payroll's mail, and has been for some time.

Writing a Rule That Is Still Right Next Year

Every screening rule carries the context it was written in, and the context leaves before the rule does. The spam wave that justified a subject rule ends in a week. The rule stays for years, matching whatever innocent message happens to use the same words. So a rule is written narrowly, on the most specific signal that will do the job, preferring a sender address over a domain and either over a word. It holds unless there is a specific reason it should block. It carries a one-line reason and a date beside it, in whatever place the tool allows or in the desk's own notes if it does not. And it has a review date, after which it is either renewed with a reason or removed.

Changing a screening rule is a change to a shared system that decides what the desk hears. That puts it in the same class as a mail-flow rule or a firewall rule: small, quick, and worth a line of record. A note in the team chat saying "added hold rule on sender X, reason Y, review in three months" is enough record for a small desk. That change is exactly the kind that What Needs Review and What Does Not would put in the "tell someone, do not convene a meeting" column. The rule that caught Amira had no reason, no date and no reviewer. It had been right for one week and wrong for four months, and nobody had been given the job of noticing.

Keep the list short. A desk with sixty screening rules has a screening policy nobody understands. The sixty-first rule will interact with the fourth in a way nobody predicts. Most small desks need a dozen: the allow list of domains and systems, a handful of recurring bulk senders, the automatic-mail detection, the attachment-type hold, and a phishing route. If the list grows past twenty, the question is not which rule to add but which problem the rules are failing to solve. The answer is usually that the mail server's own filter needs attention, or that an address has been published somewhere it should not have been. Rules are a response to a mailbox's history. They are not a plan.

A Short War Story: The Blocked Domain at Meridian Parts

At Meridian Parts, a technician called Owen grew tired of a label-printer vendor's marketing messages arriving at the desk address three times a week. Finding no unsubscribe link that worked, he added a screening rule that blocked the vendor's entire domain. Six weeks later the warehouse's label printers began misprinting barcodes. A technician called Sana raised a ticket with the vendor's support desk from the ticket. The vendor's engineer replied the same afternoon with a firmware file and a procedure. The reply came from the vendor's domain and was blocked, silently, with no ticket, no held message and no log anyone looked at. Sana chased the vendor four times over nine working days. The vendor replied four times. The warehouse hand-wrote pallet labels for the whole of that fortnight, with two mislabelled shipments returned by customers at Meridian's cost. Then the vendor's account manager telephoned to ask why nobody was answering his engineer. The block rule was found in eleven minutes once anyone thought to look. The fix was to replace it with a hold rule on the one marketing address. A domain is an organisation, and blocking one to stop a newsletter is a decision to stop hearing from everybody who works there.

The Mail Screening Rules Table

The table below is a starting rule set for a department mailbox, one row per signal, with the outcome, the reason, and when the rule is reviewed. Copy it, replace the examples with your own senders and domains, and delete any row you cannot justify in a sentence. The outcome column is the point: notice how few rows say block. Every row that says hold is a row that assumes the rule will one day be wrong about a person, and plans for it. Fill in the review column with real dates, and the reviewer's name at the bottom. A rule set with no reviewer is the one Owen left behind.

Harbourview rebuilt its rules from a table like this one the week after the phishing campaign. The subject rule that caught Amira was replaced with an allow rule on the clinic's own domain and a phishing address that feeds the IT queue. The address has its own acknowledgment thanking the reporter by name. Three weeks later a different campaign arrived. The first report reached the desk at 08:52 from a nurse called Esther. That was four minutes after she received the message and some time before anyone clicked. The desk warned the clinic by 09:10. Nobody clicked. Amira was the second person to report it.

Frequently Asked Questions