NAS Mail Guard — Spam & Outbound Mail Firewall

An outbound mail firewall and spam investigation toolkit for WordPress.

NAS Mail Guard helps site owners control email sent through WordPress, identify the plugin or file generating unwanted messages, and reduce the comment and registration abuse that triggers notification floods. It brings mail rules, source tracing, security diagnostics, and a conservative file scanner into one administration interface, with English and Arabic translations.

Developed by NAS Solutions.

Requirement	Value
Plugin version	1.1.0
WordPress	6.0 or later
PHP	7.4 or later
Interface	English and Arabic
License declaration	GPL-2.0-or-later

Why use it?

A WordPress site can generate unwanted mail through an abused contact form, a compromised plugin, bot registrations, or comment spam. Finding the source can be difficult when the mail server only identifies the hosting account.

NAS Mail Guard addresses three practical questions:

1. What is sending email? Record the originating file, line, source label, and call stack for intercepted WordPress mail.
2. Should that message be allowed? Apply recipient rules, sending limits, header checks, and content rules before normal WordPress delivery proceeds.
3. What needs attention on the site? Review configuration diagnostics and suspicious files, then apply available fixes or quarantine a reviewed finding.

Typical users include WordPress administrators, agencies maintaining client sites, and hosting teams investigating unexpected outbound traffic.

Scope of protection

The mail firewall hooks into wp_mail() through WordPress's pre_wp_mail filter. It does not act as a server-wide mail gateway or an SMTP service.

Direct PHP mail() calls, independently created mail clients, external email APIs, and direct network connections can bypass this WordPress-level protection. Code executing before the firewall loads can also escape inspection. The optional early loader improves coverage for ordinary plugins; it is not a boundary against arbitrary malicious PHP.

Use hosting-level mail controls and an authenticated SMTP configuration alongside the plugin where appropriate. The plugin does not automatically remove a server from Spamhaus or other blocklists, repair every compromise, or guarantee email delivery.

Features

Outbound mail rules

The firewall evaluates normalized message details before allowing normal delivery:

• Site-wide hourly and daily message limits.
• A daily limit per recipient.
• A maximum recipient count per message, including recognized To, Cc, and Bcc addresses.
• An allowlist for individual addresses and domains.
• Checks for carriage-return/line-feed header injection in recipient and subject input, and suspicious embedded headers.
• A sender-domain check using the site domain, administrator email domain, and configured extra domains.
• Subject and message-content blocking with regular-expression patterns; invalid expressions fall back to literal matching.
• An emergency kill-switch setting, subject to the mode and bypass behavior described below.
• Optional administrator alerts when blocked messages reach a configured threshold.

Limits use fixed UTC hour/day buckets stored in WordPress transients. These are practical application-level limits, not atomic server-level quotas under concurrent load.

Mail source tracing and logs

The log records the firewall decision and reason, sender, recipients, subject, headers, originating file and line, call stack, user ID, client IP, and request URI. The dashboard summarizes activity and groups mail by source.

Message-body logging is disabled by default. It can be enabled in settings when the additional detail is needed. A CSV export provides up to the latest 10,000 mail log rows.

A sent log entry means the firewall allowed the message to continue. It is recorded before final transport completes, so it is not proof of delivery. Check your SMTP provider or mail-server logs for transport and recipient-delivery results.

Comment, pingback, and registration shields

The comment shield offers honeypot fields, signed submission timing, link limits, per-IP rate limits, referrer and user-agent checks, and an optional keyword blocklist. Comments on older posts can also be closed through configuration.

Pingback and trackback blocking are enabled by default. Full XML-RPC disabling is optional; test integrations that depend on XML-RPC before enabling it.

The registration shield supports honeypot checks, a built-in disposable-email domain list, and registration-domain allow/block lists. It hooks standard WordPress registration and WooCommerce registration validation. Custom registration implementations should be checked separately.

Diagnostics and corrective actions

The Diagnostics screen checks conditions such as PHP mail availability, recognized SMTP configuration, XML-RPC exposure, open registration, administrator accounts, comment moderation, the dashboard file editor, the mail mode, the allowlist, and PHP execution protection in uploads.

Available actions include closing registration, changing the default registration role, enabling comment moderation, blocking pingbacks, disabling the dashboard file editor, switching to Enforce mode, and writing an uploads .htaccess guard. Server settings that WordPress cannot change are explained with host-facing guidance.

The uploads guard relies on a web server honoring .htaccess, such as appropriately configured Apache or LiteSpeed. Nginx needs an equivalent server rule; the Diagnostics screen supplies an example. A configuration check is not a substitute for testing the actual server behavior.

Suspicious-file scanning

The scanner looks for PHP-related signatures associated with web shells, obfuscation, remote includes, and bulk mailers. It also highlights executable files in uploads and recently modified files.

Default scan roots cover uploads, plugins, themes, must-use plugins, wp-content, and files directly in the WordPress root. This is not a full recursive WordPress core integrity check.

To keep scans bounded, version 1.1.0 uses:

Scan limit	Value
Maximum candidate files	25,000
Maximum file size for content inspection	3 MiB
Time budget	60 seconds

Unreadable files, size limits, exclusions, and the time budget can leave content uninspected. A clean result does not establish that the site is malware-free.

The plugin excludes its own directory and selected security-plugin directories from signature matching to reduce self-matches. Some lower-confidence signatures require corroboration outside uploads. Administrators can configure additional exclusions.

Quarantine and false-positive handling

A finding is a reason to investigate, not a definitive malware verdict. Review the file, its source, and the explanation before taking action.

• Quarantine moves a selected file into wp-content/nmg-quarantine with a non-PHP extension and records its original location.
• Restore returns a quarantined file to its original location when possible.
• Ignore records a finding against its content hash, allowing changed content to be reported again.
• Purge permanently removes a quarantined copy.

Removing a file from its original location can break the component that uses it. Keep a backup and check site behavior after quarantine. The quarantine directory includes an .htaccess access restriction; on servers that ignore it, configure equivalent access protection for that directory.

Installation

1. Download this repository using Code → Download ZIP, or clone it.
2. Ensure the plugin directory is named nas-mail-guard and contains nas-mail-guard.php directly inside it.
3. Upload that folder to wp-content/plugins/. Alternatively, ZIP the nas-mail-guard folder and install it through Plugins → Add New → Upload Plugin.
4. Activate NAS Mail Guard — Spam & Outbound Mail Firewall.
5. Open Mail Guard → Settings immediately and configure the recipients, sending limits, and mode for your site.
6. Review Mail Guard → Diagnostics and install the optional early loader if appropriate.
7. Test legitimate contact-form submissions, password resets, registrations, and customer notifications.

No Composer or JavaScript build step is required to install the files in this repository.

First-activation behavior

The default mode is Enforce, and the recipient allowlist is enabled. Activation seeds an empty allowlist with the site's administrator email address and uses that address for alerts when no alert address is configured.

Consequently, legitimate customer or staff mail to other addresses can be blocked immediately after activation. Configure the allowlist before relying on production email, or use Monitor mode while assessing traffic.

Default sending limits are:

Setting	Default
Messages per UTC hour	50
Messages per UTC day	200
Messages per recipient per UTC day	10
Unique recipients per message	5
Mail log retention	30 days
Alert threshold	10 blocks in an hourly bucket

Choosing a firewall mode

Mode	Behavior
Enforce	Blocks messages that fail enabled rules, including the allowlist when enabled.
Monitor	Logs failing messages as flagged and allows them to continue.
Lockdown	Applies the checks and requires allowlist matching even if the allowlist toggle is off.
Off	Does not block mail; logging, counters, and the PHPMailer hook remain active.

An empty allowlist is treated as unconfigured, even in Lockdown. Populate it before relying on recipient restrictions.

The kill switch produces a blocking decision in Enforce and Lockdown. Monitor still permits flagged messages, and Off clears the blocking decision. Internal alert messages and explicit integration bypasses can also bypass firewall checks. Do not treat this switch as a server-wide guarantee that absolutely no mail can leave.

Allowlist examples

Enter one address or domain rule per line:

support@example.com
@example.com
*.example.org

• support@example.com permits that exact address.
• @example.com permits addresses at that exact domain.
• *.example.org permits the base domain and its subdomains.

A bare domain such as example.com is also accepted. Domain rules permit every mailbox matching that domain; use exact addresses when tighter restrictions are needed.

For a store sending to arbitrary customer addresses, consider Enforce mode with the recipient allowlist disabled and limits sized for real order traffic. Enforce mode alone does not turn off allowlist restrictions. Test WooCommerce emails and password resets after configuration.

Early loader

The Diagnostics screen can install wp-content/mu-plugins/nas-mail-guard-loader.php. It loads the plugin before ordinary plugins so its mail filter is available earlier during WordPress startup.

WordPress needs filesystem access to create it. The loader stores the plugin's path, so check or reinstall it after moving the installation. Normal deactivation and uninstall attempt to remove the loader.

Investigating unwanted mail

1. Open the dashboard and identify unusual send volumes or source labels.
2. Inspect matching mail-log entries for the originating file, call stack, and block reason.
3. Choose Enforce or Lockdown and suitable recipient rules to contain unwanted WordPress mail.
4. Run Diagnostics and review suspicious-file findings alongside your hosting logs.
5. Quarantine only reviewed files, verify site functionality, and restore legitimate files if needed.
6. Fix the vulnerable component or compromised account that caused the activity.
7. Test normal mail delivery and work with the hosting provider on server controls and any blocklist remediation.

Common reason codes include recipient-not-allowlisted, hourly-limit, daily-limit, recipient-daily-limit, too-many-recipients, header-injection, from-domain-mismatch, content-blocklist, and kill-switch.

Privacy and stored data

Logs are stored in the WordPress database using the site's table prefix with nmg_mail_log and nmg_events. They may contain personal information in addresses, subjects, headers, IPs, and request URLs even when body logging is disabled.

Restrict access to administrative logs and redact exports before sharing them. Daily maintenance purges old log entries according to the retention setting and depends on WordPress scheduled tasks running.

Deactivation preserves stored data. Uninstall removes the early loader and scheduled maintenance; when delete data on uninstall is enabled, it also removes the main log/event tables, settings, database-version option, and matching transients. The current uninstall routine does not remove all scanner/remediation options or quarantine files. Review those separately when retiring the plugin.

Arabic interface | الواجهة العربية

The plugin includes Arabic translations and a setting to force Arabic for this plugin independently of the site's language.

NAS Mail Guard إضافة لووردبريس تساعد على ضبط الرسائل الصادرة عبر wp_mail()، ومعرفة الملف المسؤول عن إرسالها، وتقليل إساءة استخدام التعليقات والتسجيل. تتضمن حدودًا للإرسال، وقائمة بالمستلمين المسموح لهم، وسجلًا للرسائل، وفحوصات للإعدادات والملفات المشبوهة، مع إمكانية العزل والاستعادة.

بعد التفعيل، افتح إعدادات الإضافة واضبط قائمة المستلمين وحدود الإرسال. وضع الإنفاذ وقائمة السماح مفعّلان افتراضيًا، لذلك اختبر رسائل العملاء واستعادة كلمات المرور. لا تمنع الإضافة الرسائل المرسلة مباشرة عبر PHP أو اتصالات الشبكة خارج نظام بريد ووردبريس.

Version history

1.1.0

• Added diagnostic corrective actions, file quarantine/restore, and content-hash-based finding suppression.
• Fixed scanner self-matches against its own signature definitions and selected security plugins.
• Fixed false positives in preg_replace /e detection, including ordinary patterns using /i.
• Recognized harmless “Silence is golden” index.php placeholders in uploads.
• Expanded upload-path handling for multisite scans.
• Required corroboration for selected noisy signatures outside uploads.
• Added allowlist and uploads-execution checks and clearer finding explanations.

1.0.0

• Initial release of the outbound mail firewall, logging, shields, and diagnostics.

The WordPress-format description and changelog are also available in readme.txt.

Feedback and contributions

Report reproducible bugs and scanner false positives through GitHub Issues. Include the plugin, WordPress, and PHP versions; the steps to reproduce; and expected versus actual behavior. For scanner false positives, include the finding label and a minimal, sanitized example of the legitimate pattern.

False positives should be treated as bugs. Avoid posting live credentials, customer mail, private paths, or complete production logs. For a security vulnerability, contact NAS Solutions through its website to arrange private disclosure rather than publishing exploit details in an issue.

License

The plugin headers declare GNU General Public License version 2 or later (GPL-2.0-or-later). See the GNU GPL version 2 license text.