validation-rules.md

Validation Rules

Purpose

This document explains how qualification rules are modeled and enforced in the custom-code implementation tracked by this repository. It describes the behavior that is actually implemented in snippets/elementor-form-hardening.php, not aspirational behavior.

Rule model

The implementation enforces the following:

• exact blocked domains (efh_blocked_domains)
• blocked domain prefixes matched as the first DNS label (efh_blocked_prefixes)
• an optional explicit allowlist (efh_allowed_domains)
• email field presence requirement
• valid email format requirement (is_email)
• form targeting requirement (form-name prefix)

All four lists are filterable, so policy can be adjusted without editing core logic.

Prefix matching: first DNS label only

Blocked prefixes are matched against the first DNS label of the submitted domain, not as a raw leading substring.

• The prefix gmx. blocks gmx.de, gmx.net, gmx.fr, and any other domain whose first label is exactly gmx.
• The prefix gmx. does NOT block gmx-solutions.com, because that domain's first label is gmx-solutions, not gmx.

Prefix entries may be configured with or without a trailing dot. gmx and gmx. are treated identically. This avoids the false-positive class of bug where a substring match would reject legitimate business domains that merely begin with the same characters as a consumer provider.

Precedence

The implemented order is:

1. The form must be targeted (its name starts with the configured prefix). Untargeted forms are ignored entirely.
2. The configured email field must exist on the submission.
3. The value must pass sanitize_email plus is_email format validation.
4. The denylist is evaluated. A domain matching an exact blocked domain or a blocked first-label prefix is rejected.
5. The allowlist is evaluated only for domains that are not denied.

Allowlist behavior and its limits

The denylist wins. A domain that appears on both the denylist and the allowlist is rejected. The allowlist cannot override a block.

Because enforcement is denylist-based (a domain is accepted unless it is denied), a populated allowlist has limited functional effect in the current policy model: a domain that is not denied is already accepted, with or without an allowlist entry. The allowlist therefore serves two practical purposes today:

• documenting intentional exceptions for future policy changes
• providing a filter hook (efh_allowed_domains) that downstream code can read

This repository does not implement an allowlist-only ("block everything not explicitly allowed") mode. If that mode is added later, it must be documented here as a behavioral change with its own precedence rules.

Business-policy framing

Consumer mailbox blocking is not universal guidance. It is a configurable qualification choice. Use it where the business accepts the tradeoff between stricter filtering and potential loss of valid leads.

This is a lead-quality filter, not a security control. It does not stop bots, spam, or abuse, and it should not be described as doing so. A determined submitter can register a domain that is not on the denylist. Use this alongside honeypots, CAPTCHA, and WAF controls where abuse prevention is the goal.

Messaging guidance

User-facing rejection messages should be:

• clear
• concise
• non-deceptive
• not revealing about internal rule structure

The same generic message is returned for format failures and policy rejections, so the rule structure is not leaked to submitters.

Deployment guidance

Validation behavior is documented together with the snippet deployment model:

• the tracked source lives in snippets/elementor-form-hardening.php
• it is loaded through Code Snippets or an equivalent reviewed custom-code loader
• it runs server-side on the elementor_pro/forms/validation hook
• rollback is performed by deactivating the snippet
• staging validation should be performed before production use