Spam bots: what the usual defences actually cost

• In moderation. Every submission that reaches a person costs attention, and the ones that reach visitors before removal cost more.
• In your mail reputation. This is the consequence that surfaces last. A contact form that sends mail on submission becomes a way to send mail through your domain, and where that mail is unwanted, the receiving side attributes it to you. Delivery problems then appear on messages that matter, disconnected in time from the form that caused them.
• In your published content. Comment sections and reviews filled with links describe your site to every visitor and to anything that reads it.

A spammer is the person or operation that wants an unsolicited message in front of your readers. A spam bot is the software that delivers it. A bot spammer is the two together: one operator, one program, and every form the program can find.

One operator, many forms

The internet spammer behind a run does not read your site. The operator picks a kind of target, such as comment forms or contact forms, and the software submits to each one it reaches. That is why the same text, with only the details rotated, turns up at unrelated sites.

Message, link, chat and text spam

The payload differs, the mechanism does not.

• A message spammer fills contact and enquiry forms. Where the form sends mail on submission, a spam email bot turns it into a way to send mail through your domain, which is the damage described above.
• A link spammer posts URLs into comments, reviews and profile fields. The target is the link and whoever follows it, not the person reading.
• A chat spammer posts the same line into live chat widgets and community channels.
• A text spammer bot targets forms that trigger a text message. A texting spam bot costs money for each message sent, if your provider bills per message.

An email spammer bot and an e mail spam bot are the same thing under two spellings: automation aimed at a form that sends mail.

Stop spambots by limiting what one submission can do

To stop spambots, remove the reward: no single check catches every spammer. A submission that is held for review publishes nothing. A form with per-domain rate limiting cannot be hammered. A form that sends nothing until the address is confirmed has no outbound effect to abuse. In Bridge WAF monitor mode, a rule records the submissions it would have caught; in block mode it refuses them.

Where a spam lookup fits

A spam lookup checks a sender's address or IP against a published blocklist. Run it in your own form handler or mail system, as one input among several. A hit says where a message came from, not who the spammer is, so treat it the way you treat a failed honeypot: lower the score, do not refuse alone. Bridge WAF does not classify requests this way.

Three, in order of reliability.

1. Interaction, not just submission. A person who filled a form touched its fields: focus moved, keys were pressed, corrections happened. A submission arriving with no evidence of any of that was assembled rather than filled. This is the strongest available signal because it describes the process that produced the submission.
2. Content patterns across submissions. Identical structure with rotated details, links in fields that have no reason to contain them, and the same text arriving at many unrelated sites. Any single one is weak; together they are strong.
3. Rate and breadth per source. Several submissions to different forms from one place, or a submission to a form nobody links to any more, which is a form that a person would not have found.

The standard technique adds a field a person will never fill and treats anything that fills it as automation.

The mechanism is sound and its limits are specific.

• Browser autofill fills it. A field that looks like a name or an email to software gets completed by the same software your customers rely on, and they receive a rejection with no explanation.
• Assistive technology can reach it. A field hidden visually may still be announced to someone using a screen reader, who will fill it in because they were asked to. Rejecting that submission excludes the visitors least able to work around it, which makes implementation an accessibility question and not only a technical one.
• It only catches automation that fills everything. Anything targeting your site specifically will submit the fields your form uses.

None of this makes honeypots useless. It means the field must be built so that neither autofill nor assistive technology treats it as real, and that failing it should lower a score rather than refuse a submission outright.

The other standard technique measures how long a form took to fill and rejects anything faster than a person could manage.

Two populations break it. Password managers and autofill complete a form instantly, which is the behaviour being penalised. And people who prepared their text elsewhere and pasted it in look identical to a script.

If you use timing at all, treat it as one weight among several rather than as a gate, and never as the sole reason to refuse.

Following the ladder on blocking, applied to submissions.

• Accept and hold rather than refuse. A submission that goes to review before publication removes the damage without telling a legitimate sender that your site is broken.
• Limit per source and per form. Especially on forms that send mail, where the cost of each submission extends beyond your site.
• Challenge on the paths that matter, which usually means the form that produces outbound mail rather than every form you have.
• Require an account for anything published. The most effective measure where it fits the product, and the least acceptable where it does not.
• Never fail silently. Whatever you do, a rejected human should see that something happened and how to reach you another way. A form that appears to submit and quietly discards the message is the worst outcome available, and it is what most naive implementations produce.

The obligatory section, and here it decides the design.

• Anyone using autofill or a password manager, which is a large share of your visitors and includes most people on phones.
• People using assistive technology, as described above.
• Anyone who wrote their message elsewhere and pasted it, which correlates with people writing carefully or in a second language.
• Your own testing. Internal submissions from a script or a monitoring check look exactly like the traffic you are filtering.

The failure mode is quiet in every one of these cases: the visitor believes they contacted you, and you never learn that they tried. That asymmetry is why the recommendations above prefer holding over refusing.

The assumption behind the question leads people to skip defences entirely.

Submissions are not sent because your site was chosen. Forms are found the way any page is found, in bulk, and the cost of submitting to one more is close to nothing. Being small changes how much spam you receive and not whether you receive it.

The second reason is that many submissions are not aimed at your visitors at all. A form that sends mail is useful to a sender regardless of whether anyone reads the comment, and a registration form that creates accounts is useful regardless of whether the site has traffic.

That is the practical argument for handling this on forms that produce outbound effects first, whatever the size of the audience.

Automation that crawls pages for content rather than for forms is described under web scraping, and networks of infected machines under botnet.

Bridge WAF inspects requests before they reach your application: submissions matching the spam-bot rules are recorded in monitor mode and refused in block, and rate limiting per domain bounds how hard a form can be hammered. Requests that never arrive cost nothing to moderate. What the platform cannot decide is your form's own design: whether a rejected sender is told, whether a suspect submission is held rather than dropped, and whether a hidden field is reachable by assistive technology are choices in your markup. See what the platform offers at Bridge CDN.