Email Flood Defense: Real-World Guide to Discovery, Containment & Prevention Print

  • 0

🧠 A Technical Deep‑Dive into Discovery, Triage & Prevention


📌 1. Executive Summary

A lone mailbox breach resulted in a large-scale email flood from the cPanel server, crossing the one-lakh mark in just hours.

📉 Google grey‑listed the IP, causing 25–30 s SMTP time‑outs and thousands of deferred messages across hosted domains.

🔧 This article reconstructs the exact shell commands and cPanel/WHM configuration changes used to:

  • Trace the issue

  • Contain the abuse

  • Prevent recurrence — all without third-party tools


🚨 2. Early Warning Signs

⚠️ Indicator Normal Impacted
Exim Queue (exim -bpc) < 1,000 25,000+ messages
Gmail Port 25 Response < 3s 30s (SMTP timeout)
CSF AUTHRELAY Alerts 0 Spikes from IP 192.0.2.27
User Complaints Occasional “Mail delivery failed” tickets flooding

🕵️‍♂️ 3. Discovery: Pinpointing the Offending Source

🧾 How to Identify Which cPanel User and Addon Domain is Sending a Large Volume of Emails

When your server is flagged for spam or excessive email usage, the first step is to find the offending cPanel user, and then drill down to identify which addon domain or script within that user is responsible.


🔧 Step 1: Identify the Top Sending Users

📍 WHM Path:

WHM » Email » View Sent Summary

This tool provides a quick overview of:

  • Emails sent per cPanel user

  • Volume over specific time ranges

  • Source type (SMTP auth, scripts, etc.)

✅ Use this to pinpoint which cPanel account is sending the highest number of emails.


🛠️ Step 2: Analyze Which Addon Domain Within the User is Sending Mail

Once you've identified the user (e.g., exampleCPanelUser), run the following SSH command to see which sender domains are responsible from within that account:

🔍 3.1 Identify Top Sending Domains (last 7 days)

# How many days back?
DAYS=7

zgrep -h ' U=exampleCPanelUser ' /var/log/exim_mainlog* |
awk -v wnd=$(date -d "$DAYS days ago" +%s) '
{
  ts=$1" "$2; gsub(/[-:]/," ",ts); split(ts,t)
  if (mktime(t[1]" "t[2]" "t[3]" "t[4]" "t[5]" "t[6]) < wnd) next
  match($0,/S=([^[:space:]]+)/,m); split(m[1],a,"@"); cnt[a[2]]++
}
END {
  for (d in cnt) printf "%8d %s\n", cnt[d], d | "sort -nr"
}'

✅ Output:

426  examplehenna.com
226  subsite.com
130  krtkarnish.com

👉 examplehenna.com accounted for over 60% of email traffic.

🧾 3.2 Determine Method of Injection

grep -h ' U=exampleCPanelUser ' /var/log/exim_mainlog* \
| egrep -m10 'A=dovecot_login|cwd='

➡️ Sample output:

A=dovecot_login:sales@examplehenna.com H=(malicious.host) [192.0.2.27]:54294

🔐 Conclusion: Compromised mailbox credentials were used (not PHP scripts).

📨 3.3 Analyze Subject Lines to Confirm Spam Type

zgrep -h 'sales@examplehenna.com' /var/log/exim_mainlog* |
awk 'match($0,/T=\"([^\"]+)\"/,m){s[m[1]]++}
     END{for(i in s) printf"%8d %s\n",s[i],i| "sort -nr"}' | head

Sample result:

553602  RFQ GS‑0550540 – Supply Of Power Supply
   18   RFQ# 2508

📧 A single forged RFQ subject line was responsible for the spam burst.


🛡️ 4. Triage: Stopping the Bleed in <10 Minutes

🧰 Action 🖥️ Command/Tool
🔒 Freeze Outbound SMTP csf -d 0.0.0.0/0 "SMTP lockdown" -p 25
🔑 Reset Mailbox Password whmapi1 passwdpop domain=examplehenna.com email=sales password='Temp!P@ss123'
📉 Apply Rate Limit echo 'sales@examplehenna.com 0' >> /etc/exim/sender_rate_limit
🧹 Delete Queued Spam `exiqgrep -i -f sales@examplehenna.com
🔁 Restart Exim & Unfreeze systemctl restart exim && csf -dr 0.0.0.0/0 25

✅ Within 30 minutes: queue dropped from 25,000 → 42, and no new spam was logged.


🔐 5. Prevention Hardening

🔧 Area ⚙️ Setting / Tool
SMTP AUTH Throttling WHM → Exim Configuration → Enable
Domain-Specific Send Caps /etc/exim/domain-sending-limits: examplehenna.com 400 1d
reCAPTCHA on Forms v2 checkbox + server-side token validation
Shadow File Clean-up rm -v /home/*/etc/*/shadow.*roottn* + chmod 640 shadow
Google Postmaster Tools Use to monitor IP & domain reputation
Daily Spam Audit Report cron task: `perl msp.pl --auth

🔁 6. IP Reputation Recovery: Warm-Up Phase

✅ Key actions:

  • Restrict Gmail recipients to <200/hr for first 48 hours

  • Monitor banner delays with:

while true; do time printf 'quit\r\n' | nc -4 gmail-smtp-in.l.google.com 25; sleep 3600; done

📉 Banner delay dropped to <3s on day 4. Rate limits lifted by day 7.


📌 7. Key Takeaways

  1. 🧠 One leaked credential can risk your entire IP reputation.

  2. 🧰 Simple tools like grep, awk, and exiqgrep solve 90% of mass-mailing issues.

  3. 🛡️ Implement CAPTCHA + SMTP rate limits now — they're fast and effective.

  4. 🧹 Delete old shadow.bak or .roottn files — attackers still target them.

  5. 🔁 Gmail automatically removes greylisting after days of clean traffic — no manual delist required.


🔗 Related Resource

📖 Fixing Google Greylisting: Stop Email Delays and Restore IP Reputation
A concise, step-by-step recovery guide covering:

  • 🔍 Greylisting detection methods

  • ⚙️ Email authentication setup (SPF, DKIM, DMARC, PTR)

  • 🚫 Spam source quarantine and queue cleanup

  • 🔁 Gmail warm-up strategies

  • 🧩 FAQ and checklist for rapid recovery

🔗 Read Full Article →

📊 Analyzing Outbound Email by Domain Using Exim Logs (Look‑Back Window)
Gain expert insight into identifying high-volume email senders with this powerful walkthrough. You’ll learn to:

  • 🔍 Use grep, awk, and zgrep to sift through Exim logs

  • 📆 Set a configurable look-back window (e.g., last 7 days)

  • 📈 Generate domain-based sending volume reports

  • ⚠️ Quickly detect suspicious or spam-generating domains

🔗 Explore the Guide →


Final Result: Mail queues healthy. Gmail delays resolved. Stronger anti-spam controls in place — achieved entirely via WHM/cPanel and native Linux tools.

📌 Use this blueprint for any email flooding or greylisting event across Gmail, Yahoo, or Outlook.


Was this answer helpful?

« Back