The junk you see is the junk that got stored
Automated submissions through a chat widget are a steady background nuisance: captcha-cracking adverts, crypto phishing, the same few templates arriving at roughly one a second when a bot finds you. There are several ways to deal with volume, and they are not equivalent.
A rate limit caps how fast the junk arrives. A keyword filter in the mail sender stops the notification email. Neither of those stops the message being stored. It still becomes a record, still lands in your agent console, still sits in the list of visitor messages somebody has to look through. From the business’s point of view that is the part they actually experience, so the two obvious defences leave the visible problem untouched.
Refusing the submission outright is the only version that is a complete fix: no chat record, no database row, no email. That is what a submission-time filter does, and the design decisions behind it are more interesting than the matching.
It rejects visibly instead of silently dropping
The tempting design is to accept the message, throw it away, and say nothing. It hides the filter from bots and it feels tidy. It is the wrong trade, and it is worth understanding why, because the same reasoning applies to any filter you build anywhere.
A filter that silently discards has one failure mode that cannot be detected: a false positive destroys a real customer’s enquiry and nobody ever finds out. Not the customer, who believes they contacted you. Not you, because there is no record of a message you never received. The business loses a sale and the evidence at the same time.
Telling the sender their message was not accepted changes that completely. A real person rephrases and tries again, and you have a customer instead of a silence. A bot ignores the response either way, so the supposed benefit of hiding the filter costs you nothing to give up. When the two failure modes are “a bot learns something it does not act on” and “a real enquiry vanishes without trace”, the choice is not close.
Off until somebody deliberately turns it on
The filter does nothing until a keyword list exists. No list, no filtering, no behaviour change at all. That default is deliberate: a careless keyword silently rejects real customer enquiries, so switching this on has to be an act somebody performs on purpose rather than something that happens to be enabled.
The list itself is plain: one phrase per line, blank lines ignored, and lines starting with a hash treated as comments so you can record why an entry is there. Comments matter more than they look on a list like this, because in six months nobody remembers whether an odd-looking phrase was a real attack or an experiment.
There is a minimum length on each keyword, so a stray short line cannot accidentally match everything you receive. That single rule is what stops a mistyped list from turning into a total outage of your contact form. Matching is case-insensitive and works across the whole submission joined together — name, address, subject and message — because bots do not reliably put their payload in the field you expect.
Narrow on purpose, and the captcha example
The guidance for this list is to match phrases specific enough that a genuine support request would never contain them, and the instructive case is the word “captcha”. It appears in a great deal of this particular junk, so it looks like an excellent keyword.
It is a trap. MyLiveChat has a captcha feature, and customers legitimately ask about it. Filtering on the bare word would reject real enquiries from real customers asking a real question about a real feature. So the bare word is specifically excluded, and the entries are the longer phrases that only appear in the adverts.
The general rule is worth taking away even if you never touch a keyword list: the words that best identify spam are often words your customers also use. Match on phrases, not on vocabulary, and when you are tempted by a single strong word, ask what a confused customer might type.
Blocked senders are a separate, blunter list
Alongside keyword matching there is a list of addresses refused regardless of what they write. It is deliberately a different mechanism: keywords judge content, this judges the sender, and conflating the two makes both harder to reason about.
It exists as a list because it replaced something worse. Two of the older widget endpoints each carried a single hardcoded email address that was rejected with a generic internal-error response. Anyone at that address could not contact any customer on either endpoint, nothing recorded that we were the cause, and it presented as a server fault rather than a block. Every part of that is bad: invisible, unlogged, undiagnosable, and changeable only by deploying code.
Replacing it with a configured list changed the properties rather than the behaviour. Blocks are now logged, the list is editable without a deploy, and it can be emptied entirely. The lesson generalises to any block you are tempted to hardcode: if it is not logged and not configurable, you have built something nobody will be able to explain later.
It fails open, and that is the right way round
Any error reading the keyword list results in no filtering. A missing file, an unreadable file, a permissions problem, anything unexpected — the outcome is that everything gets through, not that everything gets blocked.
This is the same judgement as rejecting visibly, applied to infrastructure. The worst outcome for a business is not receiving some spam; it is a broken filter quietly standing between them and every customer trying to reach them. A spam filter that fails closed is an outage of your contact channel, caused by the thing that was supposed to be protecting it.
It is worth checking that whatever protective machinery you run elsewhere fails the same way. Filters, allowlists and validation rules all tend to be written assuming they work, and the interesting question is what they do when they do not.
How MyLiveChat fits
Submission-time keyword filtering and the blocked-sender list are server-side controls, operated as part of the hosted service rather than switches in your dashboard. If junk is reaching you and you want this looked at for your account, that is a support conversation, and the useful thing to bring is a couple of the actual messages so the phrases can be matched precisely.
The controls that are yours to operate work at different points in the same chain. IP rules refuse a source outright, and are worth reading carefully before you use them because a badly scoped rule affects more people than expected. Visitor filters decide who is offered chat in the first place. The offline form’s own validation is what rejects a malformed submission when nobody is available.
And for the junk that arrives from actual humans rather than scripts, no filter helps: that is a matter of agent latitude and team norms, which handling spam and time wasters covers.