At EncodeDotHost, we occasionally see sophisticated spam campaigns that manage to bypass standard server-level filters. One of the most persistent methods is Google Groups List-Bombing (also known as subscription bombing or backscatter spam).
This article explains how this attack works, why standard spam filters miss it, and how to implement a custom SpamAssassin rule on your WHM/cPanel server to stop it in its tracks.
Understanding the Attack
In a list-bombing attack, a spammer purchases a custom domain (e.g., spammerdomain.com), sets up a Google Workspace tenant, and creates dozens of randomly named Google Groups (like [email protected] or [email protected]).
The spammer then forcefully adds hundreds of scraped email addresses—including your users—to these groups. From there, the spammer sends an email to a legitimate company's automated ticketing system (like a customer support desk) using the Google Group address.
The legitimate company's ticketing system sends an automated "We received your ticket" auto-reply back to the Google Group. Google then dutifully blasts that legitimate auto-reply out to every user the spammer added to the group.
Why Standard Spam Filters Miss It
This attack is highly effective at bypassing spam filters for three reasons:
- Perfect Authentication: The emails are routed through Google's official infrastructure, meaning SPF, DKIM, and DMARC checks pass flawlessly.
- Legitimate Content: The actual body of the email is usually a standard auto-reply from a real, reputable company.
- Mailing List Modifiers: SpamAssassin typically lowers the spam score for emails that appear to come from legitimate mailing list managers.
Because of this, these spam emails often arrive with negative or remarkably low spam scores (e.g., -1.2 to 3.7), landing directly in the user's inbox.
The Solution: A Custom SpamAssassin Meta-Rule
To stop this, we need to penalize emails that exhibit the structural footprint of a custom-domain Google Group, while ignoring standard public Google Groups and whitelisting our own internal domains.
We do this by creating a custom SpamAssassin configuration file via the WHM command line.
Step 1: Create the Custom Configuration File
Log into your server via SSH or the WHM Terminal as the root user. Create a new, descriptively named configuration file inside the SpamAssassin directory:
touch /etc/mail/spamassassin/googlegroup.cf
Step 2: Add the Custom Rule
Open the file in your preferred text editor (like nano):
nano /etc/mail/spamassassin/googlegroup.cf
Paste the following code block into the file. Note: Be sure to change "encode\.host" in the whitelist section to your own company's domain if you use Google Workspace internally.
# 1. Check for Google Group Headers (Scored at 0.01 to prevent default 1.0 penalty)
header LOCAL_GG_GROUP_ID exists:X-Google-Group-Id
score LOCAL_GG_GROUP_ID 0.01
header LOCAL_GG_LIST_POST List-Post =~ /groups\.google\.com/i
score LOCAL_GG_LIST_POST 0.01
header LOCAL_GG_UNSUB List-Unsubscribe =~ /googlegroups\.com/i
score LOCAL_GG_UNSUB 0.01
# 2. Check if it's a Custom Domain (Not a public @googlegroups.com list)
header LOCAL_GG_CUSTOM_DOMAIN List-Id !~ /\.googlegroups\.com>/i
score LOCAL_GG_CUSTOM_DOMAIN 0.01
# 3. Whitelist your own domains (Add multiple rules if needed)
header LOCAL_GG_WHITELIST List-Id =~ /encode\.host/i
score LOCAL_GG_WHITELIST 0.01
# 4. The Meta Rule that actually applies the penalty
meta LOCAL_GOOGLE_GROUP (LOCAL_GG_GROUP_ID && (LOCAL_GG_LIST_POST || LOCAL_GG_UNSUB) && LOCAL_GG_CUSTOM_DOMAIN && !LOCAL_GG_WHITELIST)
describe LOCAL_GOOGLE_GROUP Message sent via Google Groups (custom domain)
score LOCAL_GOOGLE_GROUP 3.5
Save the file and exit the text editor.
Step 3: Check Syntax and Restart
Before applying the changes, it is critical to lint the SpamAssassin configuration to ensure there are no syntax errors.
/usr/local/cpanel/3rdparty/bin/spamassassin --lint
If the command returns nothing, your syntax is perfect. Finally, restart the SpamAssassin service to load the new rules:
/usr/local/cpanel/scripts/restartsrv_spamd
Verifying the Fix
The next time an email matches this pattern, SpamAssassin will apply a +3.5 penalty. Because typical mailing lists receive a minor score reduction, this net penalty ensures the list-bombing spam is pushed comfortably over the standard 5.0 spam threshold.
You can verify the rule is working by checking the X-Spam-Report header in a caught email. You should see 3.5 LOCAL_GOOGLE_GROUP listed in the analysis details.