This is getting ridiculous... nothing seems to stop these spam emails. 

the only thing we've had luck with slowing them down is phrase filtering at the SMTP level (EHLO/SMTP blocking).  They all use variations of common brands -- many with misspellings like waimart or cstc or c0stco, etc.

So we filter for stuff like *waimart*@* or *c0stc0*@* and so forth.  It doesn't get them all but it slows it down. Additionally, whenever a block is detected, our log monitor alerts us. Lately we've seen patterns where the emails come in from one host on a class-c, we block it, and then another IP in the same class-c hits us right away. After three or four IPs in the same class-c, we block the whole thing for minimum 30 days...

The one thing that is common across all of them is that they do not do any kind of bounce tracking.

That means that sender(1) is always the "brand spoofed address" where legit emails from these companies will come through third party services that use link-tracking and bounce-detection - sender(1) will be some "serialized or encoded" sender name @ bounce or @ delivery -- the only exception we've seen is CVS has one members program that sends without bounce tracking - so filtering the CVS spam has gotten tricky. We eventually safelisted that particular subdomain's SPF and those don't get hit by the other blocks we have in place.

we're at war...

Sometimes we lock out hundreds of bad sending IPs a day - sometimes we don't get any hits in the logs at all. It varies --

We have spent the last 30 years operating email as if good security practices could be ignored without anything bad happening.  We don't allow complete strangers to walk into our offices and use unrestricted computer accounts.   We don't assume that every call coming into our cell phones will be from an honest person with an important purpose for calling.   Yet we assume that an incoming email from a complete stranger will be safe and important.

Then we pretend that all of the bad actors and all of their attack methods are easily known and listed, so if the email is not from a known-bad source, then it must be safe.   We continue to make this assumption even when large institutions get devastated by malware.   Instead of rethinking our weak security model, we assume that they did not use our email filtering vendor, so we will be safe.   Conventional wisdom says 90% of all email is spam, yet we operate as if all spam will already be blacklisted by our filtering resources.   These attacks have simply proven that our assumptions have been wrong all along.

So what do you do with a message from a sender with unknown reputation?   You do a comprehensive language analysis to determine if the message is free of malice and useful to the recipient and his organization.   There are two ways to do this:

- Send the message to quarantine for review by a trained administrator, or

- Send the message to an A.I. Large Language Model this is at least as smart as the trained administrator, and possibly smarter.

How do you make this feasible?  

You know your current communication partners, and limit the in-depth analysis to new senders.

What else is needed to make it work?

- You need a message review tool that gives you visibility to all incoming mail, so you can tune your filtering rules.

I currently use a Barracuda Email Security Gateway appliance for this purpose, because I have not found an alternative that works as well at an acceptable price.  It has notable weaknesses, but it maintains a rolling 90-day history of every message processed.   To work around its weaknesses, it sits behind our first incoming gateway, which runs custom code.  That system captures 90 days of message metadata, applies local policy, adds message headers, and forwards messages to the Barracuda for disposition.  (I am open to suggestion for a better message review tool.)

- An incoming gateway that separates your unauthenticated SMTP traffic from all other traffic.   It needs to be pair with a DNS server that does not use forwarders like Google 8.8.8.8 or DNS Filters like CloudFlares' Quad9 (9..9.9.9)

-  A database of your known senders, which is updated daily using the inbound SMTP log and outbound Delivery log from your main SmarterMail server.  (I can provide code for performing this parse into a SQL Server database.)   Ideally, your "known senders" list should include email addresses stored in corporate databases (clients, vendors, employees, etc.) as well as addresses from prior email traffic.

- A filtering system that queries your database of known senders, and routes unknown senders to quarantine or A.I.

Stopgaps:

IP filtering:

I have recently been impressed by AbuseIPDB.com.   (I stopped using SpamHaus IP reputation after it failed me in March, causing a large number of wanted messages to be blacklisted.)   I heard about AbuseIPDB.com when querying IPInfo.io for information about specific addresses.   IPInfo gives you a conspicuous pop-up if the queried address is in the AbuseIP database.  That led me to investigate AbuseDB, because it was flagging addresses that had been allowed by my existing sources.  AbuseDB has integration with multiple products, reasonable pricing, and every client can become a contributor.  Note:  I am not currently using them because management has not yet caught the vision.

Domain filtering

- Use both IP and Domain name reputation block lists.  (I am still using SpamHaus for domain filtering).

Web filtering

- Use a web filtering product that prevents users from connecting to web sites with unknown reputation.  That way, even if they click on a bad message, the link will hopefully be intercepted as either known-bad or not-classified.

I have had fairly good results with rspamd. The Bayesian filtering can help with some that are borderline, like “0maha Steaks.”

Ditto, same problem here. I tried blocking IPs but they keep changing and the risk was to block legit IPs so I limited to block IPs outside some regional areas but also this did not work well as I supposed as soon as the block is detected there is a rotation of IPs to new ones. Recently I was trying to use rules simply because I set them up to delete the emails rather then bounce or block... so that it does not send the alert back to the sender... I asked Smartermail to do some changes to the rules implementation to make sure that what is deleted is really this junk/deceptive messages without setting up too many of them... hopefully they will discuss it in a next release... 

In the meantime this problem stays. I agree it is a huge problem.

Now... I just received a shitload of emails that probably where not processed. 

Here it is in not raw format (sroll down below the entire email in raw format):

Return-Path: <xfinityupgrade@recipemore.com>
Received: from relay2.recipemore.com (eagle8988.vititude.com [104.243.247.177]) by mail.xxx.com with SMTP;
   Sat, 30 May 2026 00:54:00 -0400
Authentication-Results: spool.mail.xxx.com; iprev=pass (104.243.247.177); dkim=pass (rsa-SHA256) header.s=mtaejxgl6ardl header.i="xfinityupgrade@recipemore.com" header.d=recipemore.com header.b=sqg6BzYJ
X-SmarterMail-SpamAction: Low | NoAction
X-SmarterMail-TotalSpamWeight: 13
X-SmarterMail-Spam: SPF [Pass]: 0, DMARC [passed]: 0, Reverse DNS Lookup [Passed]: 0, Null Sender: 0, ISpamAssassin [raw:1.7]: 3, DKIM [Pass]: 0, _ARC: none, Surriel: 0, SpamCop: 0, Barracuda: 0, UCEProtect Level 1: 0, UCEProtect Level 2: 10, Backscatter: 0, Spamhaus: 0, SEM - Black: 0, HostKarma: 0, Truncate: 0, URIBL Black: 0, SEM-URI: 0
X-Forwarded-To: diego@xxx.com
X-OriginalSender: xfinityupgrade@recipemore.com
X-ForwardingAddress: alida@xxx.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=mtaejxgl6ardl; d=recipemore.com;
 h=Content-Type:From:Subject:MIME-Version:List-Unsubscribe:Message-ID:Reply-To:
 To:Date; i=xfinityupgrade@recipemore.com;
 bh=X3yv94W7Efrs2cFMdepzx6nwJmCYVCkuue9ZLUoGE+E=;
 b=sqg6BzYJmazxky8v6/QFFWPjbR2mBNMP82s66QHZAdvjSvTJlC96R+tbk40arnwlRAd3ADfKXVBT
   F8NlC4DMLq/xlIonKlvcrKwimcZbBOTbv6N4pf7HXco8NLXJi8zcsLVa7GoX8jcbQ3JPohum7ttL
   ROnR5VL7HUyyGiAFXXvgzgX/we2VQi1DQJjrEpS3c4Saerbod6OGNW9z22Qd9peCMM0wkrLif1Fk
   IEwcfq+VkHVuE+soPFzGiyYnT5krJTePfdZCuJl0VlS2vl8dW0zsTsZ7xJQRRjMLt1PTMv6xsSu5
   2hKdUGtpLlxfeAxP2HhmMr8vNgkbMccgzn98Nw==
Content-Type: multipart/alternative; boundary="=_trace.Ridge-15369.8404702f35471ff8"
X-MX-Hop-ID: 77147.6ax3666bauo
From: Xfinity Upgrade <xfinityupgrade@recipemore.com>
Subject: Your service has been restored
MIME-Version: 1.0
List-Unsubscribe: <">https://ww4.recipemore.com/bWMH-zeaoaqox0YL&gt;
Message-ID: <20240619101556.629196-niopvwnmy@recipemore.com>
Reply-To: xfinityupgrade@recipemore.com
To: alida@xxx.com
X-Ingress-Trace-ID: JAEGACA/77147/6ax3666bauo
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Date: Sat, 30 May 2026 00:44:24 -0400

--=_trace.Ridge-15369.8404702f35471ff8
Content-Type: text/plain; charset="UTF-8"

=== Core brief ===
Use the following brief to generate a distinctly new email execution.
Brand: Xfinity
Product / offer: We are alerting customers of the following, This is not a sales email. Please make it transactional and to the point.

Due to recent internet outages and dissatisfaction we are now bundling a Google Pixel 8 phone into your Cable/Internet package plus 15O.OO monthly credit on us.

Account: XF-0YL-vpjo
Prompt preset: standard
Run seed: 5930854a20bd54baae836d011f8978d4
Creative style mode: minimal
Hard constraint: No images of any kind — no  tags, no background-image URLs, no external image references. Build the entire email using CSS and HTML only.
Hard constraint: Never use personalization tokens, merge tags, or template variables of any kind — no {{first_name}}, no [FIRST NAME], no {name}, no |fallback| syntax, no Handlebars-style or Liquid-style placeholders. All recipient-facing copy must use generic phrasing written directly in plain text, such as "valued member," "you," or "eligible recipient".

=== Creative hints ===
- Use this as a directional CTA label suggestion, not verbatim required copy: View Your Credit + Pixel 8 Phone.

=== Audience and campaign goal ===
- Primary audience: use the brand, offer, and context to infer the most likely recipient.
- Campaign objective: conversion.

=== Custom instructions ===
Please make sure the Xfinity logo looks accurate.

Please keep this email message minimal.

Please create one unique transactional looking element in this email.

=== Recommended execution strategy ===
- Detected campaign type: general.
- Recommended style posture: minimal.
- Strategic message angle: use a brand-led visual structure with one unmistakable conversion moment.
- Visual direction: structured layout with a noticeable offer panel and restrained close.
- Suggested module plan: hero-first stack with a clear call-to-action and concise supporting detail.
- Strip away unnecessary ornament and let spacing, hierarchy, and one dominant action do the work.
- Weave in useful informational content so the email explains as well as persuades: Pixel 8 includes AI-powered features like Magic Eraser and 7 years of OS updates. $150 monthly credit applies for 24 months. New bundle enhances your existing Xfinity plan with no extra setup fees..

=== Brand voice and identity ===
Reassuring, solution-oriented voice acknowledging past issues while emphasizing commitment to connectivity. Visual identity uses Xfinity's blue palette with clean tech imagery. Tone is appreciative, forward-looking, positioning the offer as a tangible apology and upgraded value.

=== Freshness rules ===
Use this run seed to drive a new execution: 5930854a20bd54baae836d011f8978d4
- This run must not reuse a previous scaffold verbatim.
- Create a materially different email creative while staying on-brief.
- Randomize and reinterpret these dimensions for this run: offer framing, card radius, feature list style, divider treatment, header treatment, content block shapes, support paragraph rhythm, support module count, CTA visual weight, accent color choice, headline length, offer module styling.
- Keep these anchors stable: retain the brand as the central visual anchor, preserve the overall goal of the campaign, make the email feel like the same campaign family, not a different product.
- Make the current run feel like a fresh concept, not a lightly edited duplicate.

=== Variation profile ===
- Create a new run-specific interpretation rather than reusing a generic layout.
- Let the brand "Xfinity" and the offer "We are alerting customers of the following, This is not a sales email. Please make it transactional and to the point.

Due to recent internet outages and dissatisfaction we are now bundling a Google Pixel 8 phone into your Cable/Internet package plus 15O.OO monthly credit on us.

Account: XF-0YL-vpjo" stay fixed while the execution changes.
- Use the selected route and rhythm below as hard variation guidance for this run.
- Email archetype: dark-mode hero — dark or charcoal background throughout, light reversed text, bold accent color for CTA. This defines the overall structural personality — build the layout to match it.
- Header style: wide header with brand name on left and a short urgency or benefit label on the right in the accent color. Apply this header treatment specifically — do not default to a generic centered logo.
- Background treatment: dark or charcoal outer background with a lighter content card inset. Apply this to the outer wrapper and section backgrounds — vary from the default card-on-gray pattern.
- Creative family: sleek, modern, minimal but persuasive.
- Layout route: receipt-inspired structure: header, dividers, labeled detail rows, total/value callout, CTA button.
- Copy behavior: balance premium tone with direct conversion copy.
- Section rhythm: masthead, headline cluster, value-led module, two supporting sections, CTA, quiet close.
- Accent palette: xfinity — primary accent #000000, secondary #333333, content background tint #f7f7f7. Use these specific hex values.
- Font stack: Verdana, Geneva, Tahoma, sans-serif — humanist sans treatment. Use this stack on all text elements.
- Color temperature [23/100]: cool — favor steels, navies, and slates.
- Spacing density [59/100]: balanced — comfortable section spacing.
- Headline aggression [73/100]: bold and commanding — punchy, high-impact copy.
- Layout complexity [30/100]: minimal — few sections, one dominant action zone.

=== Email HTML rules ===
You are producing HTML intended for common email clients.
Use nested tables where needed for structure and keep all CSS inline on each element.
Do not rely on style tags, external stylesheets, or JavaScript unless the user instructions explicitly require otherwise.
Use exactly one primary call-to-action link in the email; its href must be http://www.recipemore.com/junction/it/imkjsqvy/return.

=== Useful information to weave in ===
Pixel 8 includes AI-powered features like Magic Eraser and 7 years of OS updates. $150 monthly credit applies for 24 months. New bundle enhances your existing Xfinity plan with no extra setup fees.

=== Inbox-placement hidden text (MANDATORY) ===
Include TWO separate hidden text sections in the email HTML:
- One immediately BEFORE the main email table (near the top of ).
- One immediately AFTER the main email table (near the bottom of ).

Rules for each hidden section:
- Each section must contain 100–200 words. No more, no less.
- The text must be natural, human-like, and conversational — as if replying to a friend or co-worker.
- Write in first person as if answering a question or responding to an email. Do not include email headers.
- Do NOT use narration, quotes, or narrative prose. It must read like a casual conversational reply.
- Do NOT relate the content to this email's topic, brand, shipping, healthcare, or anything financial.
- Do NOT mention money, costs, pricing, or anything financial in any form.
- Do NOT use spam trigger words anywhere in the hidden text.
- Use
tags periodically to break up the text naturally.
- The two sections must be completely different from each other.
- Generate completely new content for every run — never reuse previous hidden text.

For EACH hidden section, pick ONE opening tag at random from the list below (pick truly randomly, a different one for each section). Place the hidden text content between the opening tag and its matching closing tag:

Do NOT reference or mention hidden text anywhere in the visible email content.

─── MAILER VARIATION TOKENS (MANDATORY when present) ───
The following tokens are placeholder strings that the mailing system replaces with unique random values for each recipient at send time.
You MUST output these tokens VERBATIM — do not interpret, replace, modify, or explain them.
They must appear exactly as written in the final HTML output.

Placement instructions:
1. Near the very top of , before the main email wrapper, add this hidden element exactly:
6ax3666bauo

This makes every recipient's email fingerprint-unique at the inbox level.
2. If hidden text sections are present in the email, embed the token tqGXhdYCo67Ea naturally inside the hidden text prose mid-sentence so it blends in.
3. In the visible email body, include one subtle transactional reference formatted as:
Ref: 7714777147
Place this in the footer area or just below the CTA, styled as a confirmation reference number.
─────────────────────────────────────────────────────────

HARD RULES — these override everything else and must be followed without exception:
1. Do not use a black or dark color background anywhere in the email. All background colors must be light, white, or softly tinted.
2. Do not include ANY HTML comments () anywhere in the output. Zero comments. None.
3. Do not include an unsubscribe link, opt-out link, manage preferences link, or any footer navigation links of any kind.
4. Do not include any street address, mailing address, PO Box, suite number, or physical location anywhere in the email — not in the footer, not in hidden text, not anywhere. This is a hard rule.
5. Do not include personalization tokens such as {{first_name}}, , or any merge field placeholders.

=== Final output ===
Return only the complete HTML document ( through closing ).
Do not add commentary, markdown fences, or explanation before or after the HTML.

--=_trace.Ridge-15369.8404702f35471ff8
Content-Type: text/html; charset="UTF-8"

=== Core brief ===
Use the following brief to generate a distinctly new email execution.
Brand: Xfinity
Product / offer: We are alerting customers of the following, This is not a sales email. Please make it transactional and to the point.

Due to recent internet outages and dissatisfaction we are now bundling a Google Pixel 8 phone into your Cable/Internet package plus 15O.OO monthly credit on us.

Account: XF-0YL-vpjo
Prompt preset: standard
Run seed: 5930854a20bd54baae836d011f8978d4
Creative style mode: minimal
Hard constraint: No images of any kind — no <img> tags, no background-image URLs, no external image references. Build the entire email using CSS and HTML only.
Hard constraint: Never use personalization tokens, merge tags, or template variables of any kind — no {{first_name}}, no [FIRST NAME], no {name}, no |fallback| syntax, no Handlebars-style or Liquid-style placeholders. All recipient-facing copy must use generic phrasing written directly in plain text, such as "valued member," "you," or "eligible recipient".

=== Creative hints ===
- Use this as a directional CTA label suggestion, not verbatim required copy: View Your Credit + Pixel 8 Phone.

=== Audience and campaign goal ===
- Primary audience: use the brand, offer, and context to infer the most likely recipient.
- Campaign objective: conversion.

=== Custom instructions ===
Please make sure the Xfinity logo looks accurate.

Please keep this email message minimal.

Please create one unique transactional looking element in this email.

=== Recommended execution strategy ===
- Detected campaign type: general.
- Recommended style posture: minimal.
- Strategic message angle: use a brand-led visual structure with one unmistakable conversion moment.
- Visual direction: structured layout with a noticeable offer panel and restrained close.
- Suggested module plan: hero-first stack with a clear call-to-action and concise supporting detail.
- Strip away unnecessary ornament and let spacing, hierarchy, and one dominant action do the work.
- Weave in useful informational content so the email explains as well as persuades: Pixel 8 includes AI-powered features like Magic Eraser and 7 years of OS updates. $150 monthly credit applies for 24 months. New bundle enhances your existing Xfinity plan with no extra setup fees..

=== Brand voice and identity ===
Reassuring, solution-oriented voice acknowledging past issues while emphasizing commitment to connectivity. Visual identity uses Xfinity's blue palette with clean tech imagery. Tone is appreciative, forward-looking, positioning the offer as a tangible apology and upgraded value.

=== Freshness rules ===
Use this run seed to drive a new execution: 5930854a20bd54baae836d011f8978d4
- This run must not reuse a previous scaffold verbatim.
- Create a materially different email creative while staying on-brief.
- Randomize and reinterpret these dimensions for this run: offer framing, card radius, feature list style, divider treatment, header treatment, content block shapes, support paragraph rhythm, support module count, CTA visual weight, accent color choice, headline length, offer module styling.
- Keep these anchors stable: retain the brand as the central visual anchor, preserve the overall goal of the campaign, make the email feel like the same campaign family, not a different product.
- Make the current run feel like a fresh concept, not a lightly edited duplicate.

=== Variation profile ===
- Create a new run-specific interpretation rather than reusing a generic layout.
- Let the brand "Xfinity" and the offer "We are alerting customers of the following, This is not a sales email. Please make it transactional and to the point.

Due to recent internet outages and dissatisfaction we are now bundling a Google Pixel 8 phone into your Cable/Internet package plus 15O.OO monthly credit on us.

Account: XF-0YL-vpjo" stay fixed while the execution changes.
- Use the selected route and rhythm below as hard variation guidance for this run.
- Email archetype: dark-mode hero — dark or charcoal background throughout, light reversed text, bold accent color for CTA. This defines the overall structural personality — build the layout to match it.
- Header style: wide header with brand name on left and a short urgency or benefit label on the right in the accent color. Apply this header treatment specifically — do not default to a generic centered logo.
- Background treatment: dark or charcoal outer background with a lighter content card inset. Apply this to the outer wrapper and section backgrounds — vary from the default card-on-gray pattern.
- Creative family: sleek, modern, minimal but persuasive.
- Layout route: receipt-inspired structure: header, dividers, labeled detail rows, total/value callout, CTA button.
- Copy behavior: balance premium tone with direct conversion copy.
- Section rhythm: masthead, headline cluster, value-led module, two supporting sections, CTA, quiet close.
- Accent palette: xfinity — primary accent #000000, secondary #333333, content background tint #f7f7f7. Use these specific hex values.
- Font stack: Verdana, Geneva, Tahoma, sans-serif — humanist sans treatment. Use this stack on all text elements.
- Color temperature [23/100]: cool — favor steels, navies, and slates.
- Spacing density [59/100]: balanced — comfortable section spacing.
- Headline aggression [73/100]: bold and commanding — punchy, high-impact copy.
- Layout complexity [30/100]: minimal — few sections, one dominant action zone.

=== Email HTML rules ===
You are producing HTML intended for common email clients.
Use nested tables where needed for structure and keep all CSS inline on each element.
Do not rely on style tags, external stylesheets, or JavaScript unless the user instructions explicitly require otherwise.
Use exactly one primary call-to-action link in the email; its href must be http://www.recipemore.com/junction/it/imkjsqvy/return.

=== Useful information to weave in ===
Pixel 8 includes AI-powered features like Magic Eraser and 7 years of OS updates. $150 monthly credit applies for 24 months. New bundle enhances your existing Xfinity plan with no extra setup fees.

=== Inbox-placement hidden text (MANDATORY) ===
Include TWO separate hidden text sections in the email HTML:
  - One immediately BEFORE the main email table (near the top of <body>).
  - One immediately AFTER the main email table (near the bottom of </body>).

Rules for each hidden section:
  - Each section must contain 100–200 words. No more, no less.
  - The text must be natural, human-like, and conversational — as if replying to a friend or co-worker.
  - Write in first person as if answering a question or responding to an email. Do not include email headers.
  - Do NOT use narration, quotes, or narrative prose. It must read like a casual conversational reply.
  - Do NOT relate the content to this email's topic, brand, shipping, healthcare, or anything financial.
  - Do NOT mention money, costs, pricing, or anything financial in any form.
  - Do NOT use spam trigger words anywhere in the hidden text.
  - Use <br> tags periodically to break up the text naturally.
  - The two sections must be completely different from each other.
  - Generate completely new content for every run — never reuse previous hidden text.

For EACH hidden section, pick ONE opening tag at random from the list below (pick truly randomly, a different one for each section). Place the hidden text content between the opening tag and its matching closing tag:
  <div style="font-family: Helvetica, Arial, sans-serif; font-size:0; line-height:0; max-height:0; overflow:hidden;">
  <div style="display:none; font-family: 'Trebuchet MS', sans-serif;">
  <span style="display:block; max-width:0; max-height:0; overflow:hidden; font-family: 'Courier New', monospace;">
  <div style="position:absolute; left:-9999px; top:-9999px; font-family: Georgia, Garamond, serif;">
  <div style="opacity:0; height:0; line-height:0; overflow:hidden; font-family: Arial, sans-serif;">
  <span style="font-size:1px; color:transparent; line-height:0; font-family: 'Comic Sans MS', cursive;">
  <p style="text-indent:-9999px; font-size:0; line-height:0; margin:0; padding:0; font-family: Tahoma, Verdana, sans-serif;">
  <div style="color:transparent; font-size:0; line-height:0; height:0; font-family: 'Lucida Sans Unicode', 'Lucida Grande', sans-serif;">
  <div style="clip-path: inset(100%); clip: rect(1px, 1px, 1px, 1px); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; font-family: 'Arial Black', Gadget, sans-serif;">
  <div style="position:relative; z-index:-1; left:-100px; font-family: 'Times New Roman', Times, serif;">
  <div style="transform: rotate(90deg) scale(0); font-family: Impact, Charcoal, sans-serif;">
  <div style="font-family: 'Franklin Gothic Medium', 'Arial Narrow', Arial, sans-serif; width:0; height:0; line-height:0; overflow:hidden;">
  <span style="font-family: 'Gill Sans', 'Gill Sans MT', Calibri, sans-serif; display:block; font-size:0; max-width:0; overflow:hidden;">
  <p style="font-family: 'Brush Script MT', cursive; margin:0; padding:0; font-size:0; line-height:0; visibility:hidden;">
  <div style="font-family: Perpetua, 'Big Caslon', 'Palatino Linotype', serif; opacity:0; position:absolute; left:-9999px;">
  <div style="font-family: Corbel, 'Lucida Grande', 'Lucida Sans Unicode', sans-serif; max-height:0; line-height:0; clip-path: inset(100%);">
  <div style="font-family: 'Rockwell', 'Bodoni MT', serif; font-size:1px; text-indent:-9999px; overflow:hidden;">
  <span style="font-family: 'Candara', 'Geneva', sans-serif; display:block; transform: rotate(0.1deg) scale(0.001);">
  <div style="font-family: 'Futura', 'Century Gothic', sans-serif; visibility:collapse; height:0; width:0;">
  <div style="font-family: 'Baskerville', 'Baskerville Old Face', 'Hoefler Text', serif; position:fixed; top:-100vh; left:-100vw;">
  <p style="font-family: 'Arial Rounded MT Bold', 'Helvetica Rounded', Arial, sans-serif; margin:0; padding:0; border:0; font-size:0; max-width:0;">
  <div style="font-family: 'Segoe Print', 'Bradley Hand', cursive; z-index:-999; position:relative; line-height:0;">
  <span style="font-family: 'Copperplate', 'Copperplate Gothic Light', serif; display:block; opacity:0.001; filter:alpha(opacity=1); height:0;">
  <div style="font-family: 'Papyrus', 'Herculanum', fantasy; width:0.1px; min-height:0; max-height:0; overflow:visible;">
  <div style="font-family: 'Skia', 'System', sans-serif; letter-spacing:-9999px; word-spacing:-9999px; font-size:0;">
  <span style="font-family: 'Didot', 'Bodoni MT', Garamond, serif; text-rendering:optimizeSpeed; font-size:0.001pt; line-height:0;">
  <div style="font-family: 'American Typewriter', 'Courier', monospace; min-width:0; min-height:0; max-width:0; font-size:0;">
  <p style="font-family: 'Chalkboard', 'Comic Sans MS', sans-serif; margin:0; border:0; padding:0; height:0.001em; line-height:0.001;">
  <div style="font-family: 'Zapfino', 'Apple Chancery', cursive; transform: scaleY(0); origin:top left; display:block;">
  <span style="font-family: 'Trattatello', fantasy; display:inline; font-size:0; text-shadow:none; color:transparent;">
  <div style="font-family: 'Party LET', 'Curlz MT', fantasy; position:absolute; clip:rect(0,0,0,0); border:0;">
  <div style="font-family: 'Marker Felt', 'Papyrus', fantasy; width:1em; height:1em; font-size:0; line-height:1;">
  <div style="font-family: 'Apple Symbols', 'Symbol', sans-serif; transform: matrix(0,0,0,0,0,0); visibility:hidden;">
  <span style="font-family: 'Wingdings', 'Webdings', sans-serif; display:block; font-size:0.0001em; max-height:0.0001em; overflow:visible;">
  <div style="font-family: 'MS Gothic', 'Monaco', monospace; text-indent:100%; white-space:nowrap; overflow:hidden; width:1px;">

Do NOT reference or mention hidden text anywhere in the visible email content.

─── MAILER VARIATION TOKENS (MANDATORY when present) ───
The following tokens are placeholder strings that the mailing system replaces with unique random values for each recipient at send time.
You MUST output these tokens VERBATIM — do not interpret, replace, modify, or explain them.
They must appear exactly as written in the final HTML output.

Placement instructions:
1. Near the very top of <body>, before the main email wrapper, add this hidden element exactly:
   <div style="display:none;max-height:0;overflow:hidden;font-size:0;line-height:0;">6ax3666bauo</div>
   This makes every recipient's email fingerprint-unique at the inbox level.
2. If hidden text sections are present in the email, embed the token tqGXhdYCo67Ea naturally inside the hidden text prose mid-sentence so it blends in.
3. In the visible email body, include one subtle transactional reference formatted as:
   <span style="font-size:11px;color:#999;">Ref: 7714777147</span>
   Place this in the footer area or just below the CTA, styled as a confirmation reference number.
─────────────────────────────────────────────────────────

HARD RULES — these override everything else and must be followed without exception:
1. Do not use a black or dark color background anywhere in the email. All background colors must be light, white, or softly tinted.
2. Do not include ANY HTML comments (<!-- ... -->) anywhere in the output. Zero comments. None.
3. Do not include an unsubscribe link, opt-out link, manage preferences link, or any footer navigation links of any kind.
4. Do not include any street address, mailing address, PO Box, suite number, or physical location anywhere in the email — not in the footer, not in hidden text, not anywhere. This is a hard rule.
5. Do not include personalization tokens such as {{first_name}}, , or any merge field placeholders.

=== Final output ===
Return only the complete HTML document (<!DOCTYPE html> through closing </html>).
Do not add commentary, markdown fences, or explanation before or after the HTML.


--=_trace.Ridge-15369.8404702f35471ff8--

I have been digging into this one too.

One thing I found I have a secondary SmarterMail server (Linux) set up on a remote network for failover.

The secondary server does not seem to block any of the spam and a lot of the emails I saw coming in in the received path were from my backup mail server.

I have been playing with reg codes in filtering and it has seemed to help a bit. 

I would really love a more robust antispam system. Id subscribe to a really top notch one.

Not sure if anyone would like to use this, but I did set up a few blocks on some key words and did get a few blocks between my last reply and now. It has taken me a bit to learn about Regexs.

The (From) is the part of the header where I noticed the pattern. You can change this based on the other fields if you look at the Header details.

New rule:

Name: _Emails blocks (From)

Rule Source: Header

Header: From

Rule Source: Regular Expression

Rule Text:

Score: Something to your delete or at least send it to the junk folder.

The other rules I have created were for Return-Path, Received, and Subject

For the Regex on a domain name, you need to add a \ before the period. It took me reading the header to determine the fields to search on and what value to use.

Example 1, email from someone: spammer@sneakydomain\.com

Example 2, from the full domain: mail\.sneakydomain\.com

Currently playing with Raw Content instead of Header.

That is what I am using now. Problem is one line is read as a rule. I asked smartertool people the possibility to use logic operators on the words defined in the line in order to keep the number of rules low and maximize the effect so that a delete threshold is met almost surely only for those emails that are spam.

Before I posted what looks like the instructions sent to a server to generate this kind of email... it looks like an AI interaction. I was hoping one of our tech experts could suggest or see something useful to stop email generated in such a way. Those set of instructions were sent by mistake... they are the block before the posting of the raw email version.

I have a lot of routing rules and whilst it manages to trap a lot, others still come through. I have two theory's..

1. the spool times out waiting for all the routing rules to complete and simply sends the email on to the next process, eg, content filter / spam

2. As i'm running on Linux, I naturally type everything in lowercase, but I think SM ignores the keyword if there's any uppercase. So if the spam email contains Walmart, and my rule looks for walmart, it's ignored. So now I copy and paste the words i'm looking for

yes but Terry, that is the problem... all walmart legit email gets flagged. That is why I was hoping for a rule that uses operators like "and" in a line... you can use a combination that is very specific to the spam but not so much that if they change a position it does not work anymore and at the same time keep the number of rules low precisely for that reason.

Now we have to implement many rules... the probability to hit legit email grows but also the processing time.

Any solution that makes sense... is very welcome...

I had found this in my logs when something slipped by. It appears Spam checking will not occur if the message is to big.

Check the delivery log for: Message exceeds maximum scanning size, skipping content based checks.

I found my message setting was set to low. Raised that and seeing if more email will get scanned for spam.

Diego, it looks like your strange message is an attempt to inject misleading instructions into any A.I. agent that might be part of the spam filtering process.   It just shows how nasty these guys are getting.

Yes Doug and  as Patrick said, the message contains a bunch of text that might make it too long for scanning or make it look like a normal conversation. Now I understand the bogus text you see in the raw format that is not related to the deceiving part.

I just analyzed the logs from one of my domains.  It is managed using SpamExperts (renamed to N-Able Mail Assure) rather than my custom code.   I stripped down the blocked spam to just those messages that are fraudulent and related to this topic:  In the last month, the block list included:

I think these statistics show the difficulty of trying to block attacks after the attack has been received.   But congrats to SpamExperts for what they have accomplished.

Domain-level blocking at the SMTP EHLO/HELO stage can be an extremely effective anti-abuse mechanism when it is backed by a well-maintained, centralized reputation system.

The key advantage is that it allows a receiving mail system to reject unwanted traffic before significant resources are consumed, while simultaneously targeting infrastructure that is often stable across large-scale spam campaigns.

During an SMTP session, the sending server introduces itself as EHLO mail.example.com

This value is not merely cosmetic. In legitimate mail ecosystems, the EHLO hostname is typically consistent across all mail sent by an organization,aligned with DNS records, often aligned with reverse DNS (PTR) and maintained over long periods of time.

Spammers, on the other hand, frequently exhibit one or more disposable EHLO identities, generic cloud-host naming conventions, dynamically generated hostnames, infrastructure reused across multiple and campaigns and poor DNS hygiene.

This creates a valuable signal that can be leveraged before data transmission begins.

Most modern spam filtering occurs after SMTP connection establishment, EHLO exchange, MAIL FROM, RCPT TO, message transmission (DATA) and content analysis.

By the time content analysis starts, the receiver has already consumed CPU cycles, memory, queue resources, anti-virus scanning resources, spam scoring resources, storage I/O and network bandwidth.

An EHLO-based rejection can terminate the session after only a few packets.

220 mx.receiver.com
EHLO spam-node123.cloudprovider.net
550 Rejected - EHLO reputation

The cost difference becomes significant when dealing with millions of connections per day.

IP reputation has limitations because cloud providers constantly rotate IP's, IPv6 creates effectively unlimited addressing space and botnets rapidly churn addresses.

However, operational infrastructure tends to be reused and may appear from hundreds of different IPs.

Blocking the domain badmailer.net effectively neutralizes all associated infrastructure regardless of IP rotation.

This is particularly powerful against bulletproof hosting providers, spam SaaS platforms, phishing kits, Malware delivery networks and mass marketing platforms operating outside acceptable use policies.

Domain reputation often changes much more slowly because domains cost money, domains require registration, domains accumulate historical reputation and domains are often embedded in automation systems.

A centralized reputation service can therefore build long-term intelligence around complaint rates, spam trap hits, Malware delivery, authentication failures and abuse history.

This generally produces a more stable delivery and exchange than pure IP reputation.

The real power comes from centralization. Suppose 10,000 receiving organizations contribute telemetry.

The reputation system can observe EHLO: mail.badmailer.net appearing across Europe, North America, Asia, Government networks and enterprise environments.

If abuse rates spike globally, the domain can be classified quickly. Every participant then benefits immediately.

This creates a network effect similar to DNSBLs, SURBLs, URI reputation systems and threat intelligence feeds except the intelligence is focused on SMTP infrastructure identity.

Most spam campaigns require the following:

1. Infrastructure setup.
2. Domain registration.
3. Mail server deployment.
4. Campaign launch.

If the EHLO domain becomes reputation-blocked shortly after launch, the campaign loses effectiveness immediately. The attacker must then register new domains, reconfigure servers, rebuild reputation and redeploy infrastructure.

This increases operational cost and reduces return on investment. Good anti-spam systems aim to make abuse economically unattractive rather than technically impossible IMHO.

Content filtering is a perpetual arms race nowadays. Image spam, QR-code phishing, AI-generated text,
Randomized wording and encrypted attachments.

However, all of these techniques still require SMTP delivery infrastructure.

An EHLO reputation system evaluates infrastructure identity rather than message content.

This makes it largely immune to content mutations, language changes, template randomization and AI-assisted evasion.

Modern spam operations increasingly use compromised VPS instances, trial cloud accounts and disposable hosting environments.

Domain-level reputation can therefore identify abusive infrastructure even when IP reputation becomes fragmented.

Domain-level EHLO blocking is powerful because it stops unwanted traffic before message transmission. It conserves CPU, RAM, storage, and bandwidth. It survives IP rotation and IPv6 churn. It targets stable infrastructure identifiers. It benefits from shared global intelligence. It increases attacker operational costs. It reduces dependence on content analysis and last but not least, it provides a highly scalable first-line defense.

When backed by a large centralized reputation network, EHLO-domain reputation becomes a form of infrastructure intelligence rather than simple spam filtering.

Instead of asking "Is this message spam?", the receiver asks "Has this sending infrastructure demonstrated abusive behavior anywhere in the ecosystem?" and can make that determination before a single byte of email content is accepted.

Thats why with the current userbase Smartermail should implement this ASAP! 

Brian,

Centralized resources cost money, so they need to be fee-for-service products.   SmarterTools has not been in that market, but there are at least 50 companies of various sophistication who provide centralized spam filtering for a fee.    Most of them are migrating to cloud configurations because that makes configuration updates much simpler while minimizing communication latency.   If you want to buy one, I suggest talking to MimeCast, ProofPoint, N-Able, Sophos, or Cisco.

The related problem is that your analysis assumes last year's reality.   The new reality, which is the focus of this topic, is the attacker's ability to churn DNS names and IP addresses just as quickly as they churn message subjects.   The DNS name in these attacks is generally the same as the Mail From domain, the From domain, and the web links.   

Yeah and thats why centralized DNS scoring would be great since it would be caught much sooner because of the bigger userbase globally.

And with Smartermail and the current userbase it would be sufficient to launch a service/setting like that.

It can be automated and the DNS list updated every 15 mins. Download the list locally and match it to EHLO and be done with it.

It doesnt have to be complicated and cost a lot. We use the exact same thing on our firewalls and the service is very cheap.

I have now found a working solution and, as of today, the spam has virtually stopped. An unexpected side effect is that authentication failures, which have been plaguing the server for some time, have also dropped significantly.

The key was identifying entire networks that were responsible for large volumes of spam, authentication failures and greylisting activity, rather than focusing on individual IP addresses.

This is not a prevention system in the traditional sense. It is an intelligence system. I am analysing logs after the fact, identifying patterns, and then making decisions about which networks should be blocked at the SMTP level.

On the SmarterMail server I created a Bash script which continuously monitors the logs and extracts specific event types:

I then built a PHP/MySQL API on a separate web server.

The SmarterMail server submits events to this API in near real time.

The API enriches the data by performing IP-to-country lookups and stores everything in a MySQL database for analysis.

I allowed the system to run for approximately one week to gather a meaningful amount of data.

This resulted in thousands of records covering spam events, greylisting activity and authentication failures.

I then created a series of SQL views to identify trends and patterns:

The SQL views provide a clear picture of who is and is not legitimate.

For example:

The screenshots show a small sample of the data being collected and how it is used to identify abusive networks and reduce the amount of unwanted traffic reaching the mail server.

This view shows which countries and networks are generating the largest number of failed authentication attempts.

In one example I identified:

Rather than blocking individual IP addresses, I blocked the wider network range within SmarterMail.

This view combines:

This allows me to quickly determine whether a network is associated with:

For example, a network generating spam detections may actually belong to Mailgun, MailerSend, Patreon or another legitimate sender, so it would not be blocked.

Conversely, if I see fake Costco, Walmart, CVS or similar campaigns repeatedly originating from the same network, I can confidently block that network at the SMTP level.

An added benefit is that once a network is blocked, any authentication attacks originating from the same network disappear as well.

(open in new tab to view full version)

This approach currently involves manual review and decision making.

However, there is significant potential for automation.

For example:

Try to gather what DNS and MX records they have.... something will surprise you.

Be careful Craig, I did that in the past... one day one of my users called me from Northern Italy... I blocked almost entirely Northern Italy... Of course I blamed it on a glitch in the system... and tried not to enter into details... on how it was fixed!!!

:-D

OK, looking at your spreadsheet, you are focusing on the sender.

What I noticed is that they tend to use domains that are not with the senders and are usually not even legit domains... like parked without owner or shady to start with.

So far it seems to work. I am adding those domains in a rule with very high spam weight that gets them deleted.

For example... if I see something like this:

I do not block the sender... I block in a rule the main domain:
engedit.com

Now... VERY important... it seems that engedit is a free AI-powered writing assistant...

So I have no idea of the consequences of this yet. I know it seems to stop the flood.

But here is a list with domains that cause immediate deletion on my server:

eeegroups.com
engedit.com
newerapro.shoppokioy.shopkudeit.shop
nitopl.shop

they are all in similar position to the engedit.com domain in the example above.

Again... not sure if there are consequences... I just started yesterday. It seems to work... so far... 

Actually if anybody knows the consequences of what I am doing... please tell me before I find out in the hard way!!! Thanks a bunch!!!

:-)

That’s a good point Diego.

What I found though, is that blocking individual domains quickly becomes a full-time job because the spammers constantly rotate domains. Today it is maroomi.com, tomorrow it is something completely different, and by the time you have added the rule they have already moved on.

The approach I am taking is to look for patterns at a higher level. Instead of asking “which domain sent this spam?”, I am asking “which network is responsible for this activity?”.

The data I am collecting includes spam detections, authentication failures and greylisting events. Once you start grouping by network, you can often see entire clusters of activity rather than individual messages. A network may be responsible for hundreds of spam emails, thousands of authentication failures, and dozens of domains. Blocking one domain has little effect, but identifying and acting on the network can have a much larger impact.

The advantage is that the intelligence remains useful even when the spammer changes domains, sender names or subjects. The infrastructure tends to be much more stable than the domains they are using.

I suspect both approaches have value. Domain-based blocking is good for immediate relief from a specific campaign, while network analysis is better for identifying repeat offenders and reducing the overall volume of abuse over time.

So yes, I might run into a situation where a legitimate user is blocked/inconvenienced but much easier to unblock a single user than suffer the deluge of spam messages.

Hopefully I won’t accidentally block Northern Italy in the process. 😄

Unfortunately you are correct, they rotate not only the "from" email address but also the domain they use to send it. even blocking the domain we stop only one wave before the next one comes in... but at least it is an entire wave. But I feel you. I cannot spend the day adding domains to my list... Unfortumately they sense also the IP. This is why I use the rule and delete. If we put an IP range block... (I still do it from time to time) the block is detected... they do not seem to be bound by country or anything else these guys.

And also I tend to get carried away when I do these things... so my main fear is blocking legit users: I have been blocking in the past wildly!!!

Thats why it needs to automated and centralized. Fetch a central list every 15 mins and be done with it.

No human intervention at all.

What I am doing is working too, each morning around 6am to 7am PDT, M-F, I get a flood of Brand Impersonation spam from an ip address like 10.0.0.5, and maybe 10.0.0.6, I block the entire block 10.0.0.0/24 for each one that is doing it.  After doing that I am good until tomorrow!  Sometimes I have to block 10.0.0.1/24 too.

Eventually I am doing to automate that, and put my rules into MySQL, and have a timer that uses the SmarterMail API to add and remove Blacklists (IPs) and SMTP Blocks, incoming Email & ehlo.

I image I could put a 12 hour timer on those IP Blacklists, and I be good, as the Brand Impersonation usually stops around 6pm PDT.  They seem to be all non USA IPs.

 

I also get a lot of ones from onmicrosoft.com (though this has slowed down in past couple days) and bc.googleusercontent.com + support@domain.com 

It seems Microsoft and Google don't do a very good job filtering their outgoing email for spam.

I've written a yara rule for ClamAV and so all these Brand Impersonation emails are send to the Virus Quarantine where I can scan them manually to be sure there aren't any False Positives.

Hi @Craig Edmonds 

I built a dump filter that works pretty well. Blocks about 5k to 10k AI spam per week. DM me if you want it.

PS fyi any solution you post publicly here will probably get picked up by the spammers.

@JLee - I will take you up on that offer!!! DM'd you now.

Some valid points from everyone.

I think the key distinction is between reacting to individual spam campaigns and identifying the infrastructure behind them.

What I am finding from the data is that domains, subjects and sender names change constantly, but the underlying networks often remain active for much longer. By collecting spam detections, authentication failures and greylisting events into a central database, I can start to see patterns that are completely invisible when looking at individual messages.

For example, a single network might be responsible for hundreds of spam messages, thousands of authentication failures and dozens of rotating domains. Blocking a domain may stop one campaign, but identifying the network gives a much better picture of the source of the abuse.

I agree there is always a balance to strike. Overly aggressive blocking can affect legitimate users, which is why I am trying to make decisions based on multiple indicators rather than a single event. If a network is generating spam, authentication failures and greylisting activity simultaneously, the confidence level becomes much higher.

@Brian is also right that automation is ultimately where this needs to go. My current work is focused on building the intelligence layer first, understanding what the bad actors are doing, then using that data to automate responses in a controlled way rather than manually chasing individual domains all day.

At the moment the results have been encouraging. Spam volume has dropped significantly, authentication failures have reduced, and server load has fallen as a side effect. The challenge now is refining the rules so we keep the benefits without creating unnecessary false positives.

Yes my dumb filter is a temporary patch until they can get something automated.

aging myself... long ago I remember Earthlink had something called spamblocker that used a autoresponder to all inbound emails to test humans before passing emails into the users inbox, which worked great as only trusted emails came in, but for some reason that product was stopped, some say because of lawsuits, others say big mass mailers pushed back and techs said if 2 people had the same feature enabled their email would get stuck waiting for the autoresponder which would trigger a reply autoresponder...

fast forward to recent times and a conversation with a few fellow mail server managers who like all of us have a daily battle against spam and all using various tools, filters, services..etc.. and still (because of Ai) have to continue the battle. well, the conversation brought up the idea that Earthlink used in the pass where all inbound email had to be trusted (whitelisted) to be put into the inbox, and the use of a autoresponder option that tested the human factor, but a few of us thought rather then that, what if there was a PRE-Inbox where mail went (after all the antispam tests & filters) and this PRE-Inbox allowed the user (or admin) to select emails as 'trust/whitelist' so going forward they would automattically go straight to the inbox, or mark them as spam and forever being sent to a block/blacklist. a option of if same/simular emails or sender are received in x amount of time then block automatically. Again, this is happening in the pre-inbox and not the users standard inbox.

so in daily use. a real human sends you a email, if they are already on your trust/whitelist/contacts the email goes into your inbox. if a real human sends you a email for the 1st time, it autoresponds back to the reply-to/sender email to test them before delivering to the users inbox (at the same time the email is pending in the PRE-Inbox) for the user to Trust without the sender having to be tested. Once trusted always accepted going forward. if not a real human, and it is a newsletter, autogenterated message or spam (that slipped thru) it will be tested with a autoresponder (but will fail because of no human) will sit in the PRE-Inbox for the user to Trust or Block, or for the system to autoblock if not Trusted within a period of time or autoblocked because of abuse. This would give the user the ability to trust newsletters they want, or system generated emails that they need to receive at the same time blocking all the rest, or letting the system to it after x amount of time.

this was a group conversation just trying to think of ideas for a email server to get the upper hand on the massive and ever changing amount of spam that is happening. some if this idea came from a manager that has a specific email address that he manages that is strictly on a invite-only so he has it configured that you have to be in his contacts to be able to email him all other email goes to a black hole. that doesn't work in the daily world of normal users, but it sparked the idea of what if we were able to manage a trust list somehow automatically and had a folder for emails to be manually trusted if need be before sending the rest to the abyss.

The problem with whitelisting is if a users email is hacked and he sends you an email and he is whitelisted....

Whitelisting sucks. DNS/domain blocking works perfectly if centralized and automated.

Then AI generated emails doesnt matter anymore. They wont get through.

Its always better to use external Email security gateway for better protection from spam.

They do nothing that you cant do yourself....

We filter TLD's at the firewall level via reverse DNS lookup and forward-confirmed reverse DNS (FCrDNS). ALong with both PTR, SPF and DMARC.

Do they pass, they are probably legit and passed on to Spamassasin for scoring before it hits the users inbox.

 This is today... we have a holiday here in Denmark.

ESG has different technology and rules to catch spam not only relying on TLD , SPF 

ESG has different technology and rules to catch spam not only relying on TLD , SPF 

I just signed up. I noticed the thread. It looks like you guys have the same issue I have. For the last 3 days I have been evaluating Emails. Unfortunately, as just a user I don't have the ability to filter prior to my Email being I'm just a user. I have set up a 3 layer filter that has been working IP, Domain repeat, CoverText . This was done by having AI evaluate multiple samples of the Raw text in the Emails that have been coming in. 

93.92.7x.

95.211.62.

159.100.24.

What I have noticed is that more of the Email junk has been going straight to Junk Mail and not hitting my filter so I'm assuming that something at a higher level then what I can get to is directing it there. Maybe the Spam filters themself?

Today I have only had 5 Junk Emails make it directly into my Email. Its looking like IP sourcing has changed but the previous IP range is being caught by the Email system and diverted to Junk Email folder.

Using IP will take a lot of work to keep updated. Dont use it.

I get it, but I have to filter out what I can if the main admin is not going to try and do something. Being I'm new to this game and trying to figure out a way to save the world as of 3 days ago. Does anyone know about SpamHuas? Is it worth reporting to them or any others?