Known Senders as Antispam

Problem reported by Douglas Foster - 5/2/2026 at 6:01 AM

Submitted

I have sputtered about the limitations of spam filtering several times recently. Blocking bad actors and blocking bad content is a losing process because the problem is infinite. The only way to block spam is to focus on the wanted mail, which is a finite question.

We started building a dataset of known senders awhile back, using a nightly batch script that parses yesterday's delivery log of accepted messages. That allowed us to run daily reports of messages from unknown senders, and it showed that malicious traffic was getting through every day. It also showed that our incoming volume was 98% known senders, 2% unknown senders. Essentially all of our risk is in that 2%. Then, we were able to classify the unknown sender traffic into three groups, based on spam risk:

- Group 1: Messages from mailbox providers like Gmail and Yahoo. Currently, these have a relatively low spam rate, spam tends to be phishing content rather than direct attacks, and existing tools are catching the spam pretty well. This group also includes a volume of important messages from clients, which are incorrectly quarantined because our commercial spam filter does not like photos sent from cell phones.

- Group 2: Messages from email service providers (ESPs) like SendGrid.net and ConstantContact.com, where the SMTP From domain is the ESP and the message From address indicates the client. Some of these sources are wholly unwanted advertising and can be blocked based on the SMTP From address. Others have a mix of important messages and unimportant advertising.

- Group 3: Messages sent directly, so that the SMTP domain and the message domain are the same. This includes most of our current spam, including the attacks using free gifts from major brands and confirmations of fake payment transactions.

After contemplating this problem for a long time, I have begun moving to a security model that quarantines messages from unknown senders, starting with the last group. I am already seeing the benefit -- attacks that were getting through are now getting quarantined, and the volume of incorrect quarantine has increased very little.

9 Replies

Reply to Thread

YS Tech Replied

5/5/2026 at 2:22 AM

How do you deal with possible new clients sending your clients emails for work, as these would be unknown senders (possible new clients)?

Douglas Foster Replied

5/5/2026 at 3:52 AM

Unknown senders do not get blocked, they get sent to quarantine. Wanted messages are delayed until they are released from quarantine, but they are not lost and the sender is not notified.

To minimize delays, check quarantine more often. Right now, I usually check in once per day, in the morning. Of course, I also check if someone asks about a missing message.

This is the product of a 7 years of experimenting and custom development. I have occasionally ranted about my frustration and disappointment with commercial filtering products. Custom development was not something that I intended to undertake, but I felt forced into it.

Based on just a few days of data, it is working very well. The volume of messages which get quarantined for Unknown Sender is low, a small part of all quarantine, and the wanted message subset is tiny, less than 1 in 10.

My Toolkit

I am currently using SmarterMail as my MX and first inbound gateway. It calls Declude, which calls Python scripts, to do the filtering work. The Python code queries a SQL database to make filtering decisions and to check known or unknown sender status. Python also stores message metadata in that database. Then Declude adds an X-Declude-Tests header with test results, and hands off the message to a Barracuda Email Secure Gateway appliance.

Unlike SmarterMail, the Barracuda appliance has a pretty good user interface for message review, and it maintains a running 90-day history of every message that it sees. I have configured the Barracuda to examine the X-Declude-Tests header and quarantine based on keywords in that header. The Unknown Sender indicator is one of them.

Douglas Foster Replied

5/5/2026 at 2:10 PM

Today's results for the unknown sender test:

Stopped 8 unique fraud attacks (8 recipients)
Stopped 17 unwanted ads (27 recipients)
Delayed 6 acceptable messages (7 recipients)

I am very willing to risk the 6 delayed messages to prevent the 8 fraud attacks from getting delivered.

Stopping the unwanted ads is a bonus (assuming that the ads are legitimate companies and not just a different variety of fraud.)

Tim Uzzanti Replied

5/5/2026 at 3:26 PM

Employee Post

Intrusion attempts and spam have picked up significantly.

In response, we have some exciting new features and announcements coming that will help our customers even more.

First, we will be introducing an Adaptive Intrusion Detection system designed to help you protect your mail server better than ever before. This is scheduled for release in early June.

In addition, around the same time, we will be announcing (not yet releasing) something pretty amazing related to spam. Unfortunately, that is all we can share for now.

Tim Uzzanti

CEO

SmarterTools Inc.

www.smartertools.com

BMark Replied

5/6/2026 at 5:15 AM

Tim Uzzi, Thanks you!
Let's hope so because in my opinion there is a need to strengthen the tools integrated into SM in view of the exponential changes in spam and security, we await with bated breath!

terry fairbrother Replied

5/6/2026 at 5:46 AM

What SM needs is a section where I can add (or is added automatically) a list of email accounts that bad actors used to log on, for example

ftp@

web@

backup@

etc

These don't exist yet are constantly been attempted. I have tried IDS, it doesn't work well enough and blocks genuine attempts. Ideally they send a username and password but the server doesn't respond in any way, thus they get no acknowledgement or it tarpits them

At one point I had over 200 blocked email addresses, but soon as the timer expires, it's tried again.

J. LaDow Replied

5/6/2026 at 6:11 AM

We use IPBan and log scanning for those -- "known bad" email addresses - first try is a 90 day ban --

MailEnable survivor / convert --

Sabatino Replied

5/6/2026 at 11:40 PM

Can I ask you a few more details about IPBAN?

I'm curious.

1) Are you installing it on the same server where Smartermail is running?

2) The fact that it says: 1 attempt from "known bad" email addresses -> IP block for 90 days leaves me perplexed.

Let me explain. Spammers often use public SMTP servers or services like smtp2go.com, or compromised SMTP accounts.

How can I block this IP? I would also block legitimate traffic.

Sabatino Traini
Chief Information Officer

Genial s.r.l.
Martinsicuro - Italy

J. LaDow Replied

5/7/2026 at 6:03 AM

Users are not logging in from SMTP2GO, SendGrid, or other provider IPs - those only send mail in (or out if you use their services, like we do for a couple domains).

The brute force login attempts come from either residential IPs, data-centers hosting VPNs or script-kiddies sitting on a server launching attacks. Either way, those IPs have no business talking to our servers, so they get an insta-ban. In the case of a VPN we don't worry about client connectivity because we know how our clients connect. If one decides to use a VPN and has connectivity problems because that VPN has been "attacking" then we go the static IP route with that provider/client.

We filter against sender(1) for many obvious spam/phishing attacks and ban known bad stuff. Those are rarely ever sent through "providers" other than Microsoft's own server farms. In addition, all the providers use bounce tracking on messages - which leaves sender(2) as the actual "email" sending the mail. Sender(2) is filtered at SM level. We filter sender(1) at the log level and that's what's used in any insta-banning.

We filter EHLO, sender(1), and bad login attempts with log scanning that kills the majority of offending IPs.

With greylisting enabled, many offenders never even get a chance to send the mail in because it's caught in the first attempt and banned before the second.

In all cases, any traffic presented by IPs that fall into the insta-ban category gets blocked - and if it causes problems for a client (which we haven't had yet) - then we have a sit-down with that client to find out why they are using the same infrastructure as those attacking or spamming the server. We also go after the provider.

In the end, we dealt with the hassles of DNSBLs, spam lists and the likes early on in the game years ago - and we got the same treatment if our server acted up. It's no different in my opinion to be one blocking and holding other hosts accountable as we have been in the past.

Currently, we have 1300 entries in the EHLO/SMTP Blocking lists on our server. Any entry in that list that gets caught up in the logs gets insta-banned. We haven't lost any legitimate traffic this way. The one exception is we safe-listed Google's GMAIL servers via their SPF record because they are the one host that we see that doesn't use bounce-tracking on their outgoing if it's a hosted domain.

MailEnable survivor / convert --

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text