MDL Spam Filter

It scans any POST submission that contains an email address — or that carries a recognised form plugin's identifier (Contact Form 7, WPForms, Gravity Forms, Ninja Forms, and similar) even without an email field — so it works with most form plugins and plain HTML forms without extra setup. AJAX and REST forms such as Contact Form 7 get a proper response, so the submit spinner does not hang.

Yes. Under Settings → Form targeting choose "Selected forms" and add each form by its id, class, or name (for example #contact-form or .wpcf7-form). A lightweight front-end script tags each form with its id, class, and name so only the forms you list are scanned.

No. Keyword detection works with no external service. An API key is only needed if you enable AI detection.

Your choice, under Settings → Protection. "Silently discard" shows the form's normal success message while the submission is dropped, so bots get no clue. "Show a blocked message" displays a clear notice that the message was flagged as spam.

No. When a submission is flagged as spam, every email it would send is suppressed, including the admin "new submission" notification and any autoresponder to the visitor. This applies to forms that send through both standard page submits and AJAX. The outgoing-email safety net (Settings → Email & logging) must be enabled, which it is by default.

Yes. Wrap a custom keyword in forward slashes to have it matched as a regular expression, for example /\bcheap +rolex\b/. Patterns are always case-insensitive, and an invalid pattern is skipped safely rather than blocking anything. Each keyword — plain or regex — also shows a hit counter on the Keywords page telling you how many submissions it has blocked, so ineffective keywords are easy to spot and prune.

Detection mode is set to "AI only" and the AI-unavailable keyword fallback is turned off, so keywords play no part. Switch to "Keywords only" or "Keywords, then AI", or turn the fallback back on in Settings → AI engine, to manage and use keywords. With the fallback on, keywords are still editable and are used only when the AI provider is unreachable.

Yes. Under Settings → AI engine, "Detection rules" offers three modes: the built-in default rules, your own custom rules, or both combined. Custom rules are plain-language lines such as "Treat requests for electrical or roofing work as spam — we only do plumbing." If you'd rather not write them yourself, the "Generate rules with AI" assistant drafts rules from a short description of your business (ready-made templates included) — review the draft, adjust it, and save.

By default, when detection mode is "AI only" and the provider cannot be reached (outage, timeout, rate limit, or a bad key), the plugin falls back to a keyword scan so spam is not silently let through. You can turn this off in Settings → AI engine. In "Keywords, then AI" mode the keyword scan always runs first, so an outage never opens the gate. A blocked submission caught this way is logged with the reason "Matched keyword (AI unavailable)". You can also be told about provider problems as they happen: turn on the AI Engine provider-error notification in Settings → Notifications and the plugin emails you when it hits a provider error — an invalid or expired API key, exhausted credit or quota, or an outage. Alerts are throttled to one email per distinct error every 10 minutes.

Your provider API keys are never included in a settings export. For maximum safety you can keep them out of the database entirely by defining them in wp-config.php: define( 'MDLSF_ANTHROPIC_API_KEY', '...' ); (or MDLSF_OPENAI_API_KEY / MDLSF_CUSTOM_API_KEY). When a constant is defined it overrides and hides the stored option, and the matching field shows a read-only note instead of an input.

Yes. Under Settings → Protection set "Submission rate limit" to the maximum number of submissions allowed per minute from one visitor. Submissions beyond that are blocked without an AI call, which throttles bursts and caps API cost. It defaults to 20 per minute; set it to 0 to disable.

Two zero-cost bot traps under Settings → Advanced protection. The honeypot adds an invisible form field that humans never see; any submission that fills it is blocked. The minimum submit time blocks forms submitted faster than a human could plausibly fill them (bots typically submit instantly). Both checks fail open: a visitor without JavaScript or on a cached page is never blocked by them.

Yes. Turn on the language guard under Settings → Advanced protection and pick a mode. Block selected languages & alphabets blocks submissions written mostly in any language or alphabet you tick (the default selection is everything except Latin). Allow only selected languages & alphabets inverts it: anything written mostly in a language or alphabet you did not tick is blocked, including ones not listed. Either way the guard also blocks words that mix Latin with look-alike Cyrillic letters — a common trick to sneak terms like "vіаgra" past keyword filters. Accented Latin languages such as French, German, or Spanish always count as Latin, and a foreign name or city in an otherwise fine message does not trip it. The check is deterministic and costs nothing — it runs before any keyword or AI work and fails open on content it cannot judge. The guard detects the alphabet, not the exact language — it cannot tell apart languages that share an alphabet, such as Russian vs Ukrainian or English vs Indonesian. For per-language policy, use AI detection instead: add a custom rule under Settings → AI engine → Detection rules such as "We only serve English-speaking customers — treat submissions written entirely in another language as spam." The AI reads every language, so it classifies foreign-language spam on meaning either way.

Yes. Under Settings → Advanced protection, add email addresses, domains, or IP addresses to the allow list (matching submissions skip every check, including AI) or the deny list (matching submissions are blocked immediately, without an AI call). You can also manage senders in one click: every Filter Log and Review row with a valid email shows a "Block sender" action that adds that address to the deny list, and Review rows additionally show an "Allow sender" action that adds it to the allow list (rows whose sender is already listed show "On deny list" or "On allow list" instead). Each change is recorded in the Activity Log, and both lists stay editable under Settings → Advanced protection.

A hold-for-review step for submissions flagged by keywords or AI, on by default — turn it off with "Hold flagged mail for review" under Settings → Email & logging. When on, a flagged submission is captured and the request is stopped before any form handler runs — so nothing is stored in your form plugin and no email is sent until you decide. The visitor still sees the form's normal success message. You can also have the plugin email you when a submission is held: turn on the review notification under Settings → Notifications. It goes to the central notification email address, or a review-specific override address if you set one; either falls back to the site admin email. For each held submission you can:

• View — see all submitted fields, the sender, source, and reason. The detail view also includes a quick "add keyword" box: paste a telltale phrase from the spam and it is added to your custom keyword list immediately, so future submissions containing it are caught without an AI call.
• Accept — email the submitted fields to the site administrator (goes out through wp_mail like any other mail). Not added to the filter log.
• Block — discard the submission (never delivered) and record it in the filter log.
• Allow sender / Block sender — add the sender to the allow or deny list in one click, so their future submissions are always let through or always blocked.

Only in this plugin's own database table, and only if you enable logging. They are never written to your form plugin's entries or email log. Entries do not pile up forever: filter-log and review-queue rows older than the retention period (Settings → Email & logging, default 90 days) are removed automatically once a day. Set the retention to 0 to keep entries indefinitely.

Only when AI detection is enabled, or when an admin uses the "Generate rules with AI" assistant. With AI detection on, the submission text is sent to the AI provider you select (Anthropic, OpenAI, or a custom OpenAI-compatible endpoint you configure) for classification. The rule assistant additionally sends the business description an admin types into it, so the provider can draft custom detection rules. See External Services below. Fields whose name indicates a secret or payment detail (passwords, API tokens, card numbers, CVV, account/routing numbers, and similar) are excluded from both the text sent to the provider and the stored log excerpt.

A plugin-level audit trail, separate from the Filter Log: settings and keyword changes (with which settings changed — never their values), imports and exports (settings and keywords), log purges and deletions, automatic retention pruning, review-queue decisions, senders blocked or allowed from the Filter Log or Review pages, keywords added from the review queue, weekly digests sent, AI connection tests, notification test emails, plugin activation, and AI provider errors (throttled, so an outage produces one entry per window). Entries record the acting user and are pruned automatically after 90 days. Setting values and API keys are never stored in the activity log.

Yes. The Filter Log page has a CSV export that honours your current search and filters. The Import/Export page has a JSON settings export/import for moving configuration between sites — API keys are never included in the export — plus a separate keywords-only export/import for sharing keyword lists without touching other settings.

Set one central address under Settings → Notifications and every alert the plugin sends — review-queue holds, AI provider errors, and the weekly digest — goes there. Leave it blank to use the site admin email. Each notification also has its own on/off toggle and an optional override field, so you can send, say, the digest to a different mailbox. Every field accepts several addresses through a tag-style picker — press Enter or type a comma after each — and anything that is not a valid email address is flagged when you save instead of being dropped silently. A "Send test email" button on the same section delivers a test message to whoever would receive the selected notification, so you can confirm delivery before a real alert depends on it.

Yes. Turn on the weekly digest under Settings → Notifications. Once a week the plugin emails a summary — how many submissions were blocked in the last 7 days, the detection-method breakdown, the top blocked senders, and how many items are waiting in the review queue — to the address you set there (the central notification email address, or a digest-specific override; defaults to the site admin email). Weeks with nothing to report send no email.

WordPress cron is not a real cron — it only fires when someone visits the site. On a quiet, staging, or local site, scheduled events sit in the queue past their due time, and the dashboard's System health card flags them as overdue rather than pretending all is well. Visit the front end once (the overdue job runs and reschedules itself), or for a reliable setup add define( 'DISABLE_WP_CRON', true ); to wp-config.php and point a real system cron at wp-cron.php every few minutes. If the card instead reports the cron entry as stale (a daily event scheduled more than a day out), deactivating and reactivating the plugin rebuilds the schedule.

Yes. These hooks are available:

• mdlsf_predefined_keywords (filter) — modify the built-in keyword list.
• mdlsf_excluded_requests (filter) — mark additional requests (by your own logic) as non-contact-form so they are never scanned.
• mdlsf_sensitive_field_keys (filter) — modify the list of field-name substrings excluded from scanning, AI, and logging (passwords, tokens, card numbers, etc.).
• mdlsf_language_guard_threshold (filter) — adjust the ratio of offending-script letters (0–1, default 0.3) above which the language guard blocks.
• mdlsf_log_max_rows / mdlsf_quarantine_max (filters) — adjust the filter-log row cap and review-queue size cap.
• mdlsf_ai_prompt (filter) — modify the classification prompt sent to the AI provider, receiving the full prompt text and the sampled submission content.
• mdlsf_allow_insecure_custom_endpoint (filter) — permit an http:// custom AI endpoint (e.g. a trusted local model).
• mdlsf_submission_blocked (action) — fires when a submission is blocked, passing the submitter email and the detector verdict.
• mdlsf_submission_quarantined (action) — fires when a flagged submission is held in the review queue, passing the submitter email and the detector verdict.