Hardening a Webuzo Mail Server Against Sextortion Spoofing & Fixing Email Deliverability

The Attack — What Happened

Every email account across every domain on a Webuzo-managed dedicated server was being flooded with sextortion spam. The same message — "YOU PERVERT, I RECORDED YOU!" — was hitting every mailbox, hundreds of times. The attacker was spoofing the sender address so it appeared the emails came from the victim's own address.

The email demanded $800 in Bitcoin, claiming to have recorded the recipient through their webcam. The attack was automated and hit all domains hosted on the server.

Root Cause Analysis

Examining the email headers revealed the full attack chain. The attacker at IP 203.0.113.50 was sending email as info@charity-example.org to info@charity-example.org. The server accepted it because of five compounding failures:

• SPF failed but mail delivered anyway
• DKIM verification disabled in Exim
• DMARC policy set to p=none
• No RBL rejection rules configured
• SpamAssassin tagged but didn't reject

SpamAssassin did detect the spam (score 6.0, threshold 5.0), but the server was configured to tag spam rather than reject it. The attacker's IP was already listed on Spamhaus PBL and XBL, but no RBL rejection rules existed.

Fix 1 — Webuzo ACLs Tab

The ACLs tab controls the core access control rules for incoming SMTP connections. This is where the biggest misconfigurations were hiding.

Fix 2 — Webuzo Filters Tab (Anti-Spoofing Rule)

The Custom Filter box accepts Exim system filter syntax. This anti-spoofing rule rejects any unauthenticated external email that claims to be from a local domain:

if "$authenticated_id" is "" and "$sender_host_address" is not "" and "$sender_host_address" is not "127.0.0.1" and "${if match_domain{${domain:$h_from:}}{+local_domains}{yes}{no}}" is "yes"
then
  fail text "Rejected: you are not authorized to send from this domain"
endif

Fix 3 — Webuzo Mail Tab

Fix 4 — Webuzo RBLs Tab

The Exim configuration had # BEGIN RBL and # END of RBL markers but nothing between them. SpamAssassin was scoring against RBLs (headers showed Spamhaus PBL/XBL hits), but the server wasn't rejecting at the SMTP level.

Fix 5 — Webuzo SpamAssassin Tab

Fix 6 — DNS Authentication (SPF, DKIM, DMARC)

SPF — Sender Policy Framework

SPF tells receiving servers which IPs are authorized to send email for your domain. Use -all (hard fail), not ~all (soft fail):

v=spf1 a mx ip4:198.51.100.25 -all

DMARC — The most important fix

DMARC tells receiving servers what to do when SPF and DKIM both fail. Most domains had p=none — which literally means "do nothing when someone spoofs this domain."

# TXT record at _dmarc.yourdomain.org
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.org; fo=1

Fix 7 — PTR / Reverse DNS

The server hostname was mail.example.com, but reverse DNS returned 198-51-100-25.rev.example-isp.net — Scaleway's generic hostname. Gmail penalizes this mismatch. Fixed via Scaleway console to point PTR to mail.example.com.

Fix 8 — Cloudflare Proxy & Email Client Connectivity

Users couldn't connect Outlook, Gmail, or Thunderbird to their email accounts. The reason: the mail subdomain on every domain was proxied through Cloudflare's orange cloud. Cloudflare can only proxy HTTP/HTTPS — not IMAP (993), POP3 (995), or SMTP (465/587).

The rule: Grey cloud (DNS only) for anything email-related: mail, autodiscover, autoconfig, hostname. Orange cloud (proxied) for web: root, www.

Email client connection settings (after fix)

Incoming Server:  mail.example.com
Protocol:         IMAP
Port:             993 (SSL/TLS)

Outgoing Server:  mail.example.com
Port:             465 (SSL/TLS)

Username:         full email address

Fix 9 — SSL Certificate Issues

ZeroSSL certificates were failing to issue for several domains. Two causes:

Verification & Results

After applying all fixes:

=== PTR (Reverse DNS) ===
198.51.100.25 → mail.example.com ✅

=== SPF ===
All domains: v=spf1 a mx ip4:198.51.100.25 -all ✅

=== DKIM ===
All domains: key present, selector x ✅

=== DMARC ===
All domains: p=reject ✅

Verification tools

TL;DR

A Webuzo-managed server was under mass sextortion spoofing. Five compounding failures allowed it: disabled DKIM verification in Exim, DMARC set to p=none, no RBL rejection rules, SPF softfail or missing, and SpamAssassin configured to tag rather than reject. The fix involved hardening the Webuzo Exim Configuration Manager across six tabs, adding anti-spoofing system filters, correcting DMARC to p=reject for all domains, fixing the PTR record, and switching all mail. subdomains from Cloudflare's orange cloud proxy to grey cloud DNS-only — since Cloudflare cannot proxy IMAP/SMTP traffic.