SpamFoo rollout planning
Problem reported by Douglas Foster - 6/27/2026 at 1:18 PM
Submitted
1) Do you really want spam filtering of internal-only and outbound mail?
My analysis:  No
Internal threats can come from angry employees throwing bombs on their way out the door, or by compromised accounts being controlled by bad actors.    I suspect that angry employees have much more effective attack strategies than email, so email is the least of my worries.   Similarly, a rouge actor or compromised account is a zero-day attack, meaning that i am trying to defend against something that 
I have never seen.   Even with AI intent analysis, I am doubtful that such attempts will succeed when needed.   On the other hand, I am certain that filtering of outbound and internal-only mail will consume a lot of CPU cycles while producing a steady stream of false positives.   Authenticated users expect to be held accountable for their actions, potentially including criminal liability.   That seems like sufficient deterrence to me.   

Prove me wrong:   Can anyone provide success stories about using filtering of internal-only and outbound mail to block such attacks when they occur?

2) Do you want inbound spam filtering to occur on your main mail server?
My analysis: No
This answer is closely related to the previous one.   Since I only need to evaluate unauthenticated SMTP traffic arriving from the Internet, I want to filter that traffic before it becomes commingled with authenticated traffic.   Additionally, there are appropriate differences in DNS configuration between a spam filtering server and a primary mail server, which I have documented here:
Ergo, the best place to filter incoming traffic is on a dedicated inbound gateway.

3) Should I worry about resource contention?
My analysis:  Yes
If filtering is on your main server, spam filtering competes with interactive usage, internal message flow, and outbound message flow.  Since there is no free lunch in life, I have to assume that SpamFoo's AI modules will become compute intensive whenever the inbound traffic spikes.   If that workload is isolated and limited to incoming traffic, the bottleneck only affects incoming messages.   If that workload is on your mail server, all interactive and background activity will be affected.

Which brings up a licensing question:   How will they license SpamFoo on an inbound gateway running SmarterMail Free?  I am sure they will have a solution for that when the time comes.

Note:   SpamFoo seems to be a very new company, as it lacks any presence in Wikipedia or Google search results, and their web page has no corporate history section.    Given that it is based around A.I., this should not be a huge surprise.    Venture capital startups have given us some very successful companies, such as Facebook and SpaceX.   The partnership between SpamFoo and SmarterMail should be very good for both companies.
J. LaDow Replied
Respectfully submitted:

We are all thankful that effort is going into this system.

The only problem many administrators have here is the constant BETA testing of "production release software" - not necessarily with SpamFoo but in general. In the case of SpamFoo, we are the beta testers with our paid licenses, so that in the future, we'll have to pay for the service. This isn't fair. We understand the "add on beta test is free" but honestly, there should be something more for that than just telling us all that we'll have to pay for it once it's production ready.

If you want meaningful testing - offer a year of SpamFoo to anyone willing to spin it up on a production server and keep it running. Give us some reward for our multitudes of hours spent reporting, testing, fixing, diagnosing, dealing with our customers, etc. These testing periods are not harmless to us - they cause us great issues with our clients over and over.

In general:

Quality control in regards to testing - whether it be multi-lingual environments or whatever - has not been the best.  Is it a mountain you're trying to climb?  YES - but for a company that claims to have the resources ST does, being beta testers for software we pay for, with the risk of downtime is unacceptable.  Too many of us lose customers every time another bug appears - or another regression.  Too many of us spend MANY hours diagnosing and beta testing software that is released as "enterprise ready" and that simply is not acceptable.

I haven't mentioned this in quite some time, and will leave it alone for a while after this, but I am detailing my frustrations with how things are going. We thank you all for your time and efforts with the software. It's understood that some progress has growing pains, but the rate of regressions and other issues appearing each release is unacceptable for production environments. 

As you all well know - there is no profit margin for email service. Many of us run it at a break even (and some of us at a loss) in order to keep clients with us for other reasons. The resources to keep multiple VMs online with "testing and production" versions is not sustainable, let alone the nightmares of trying to convince clients to be guinea pigs on our "test servers" -- they are NOT interested in that. They pay for a service they expect to work. Discounting them is not in the cards when we get no discount for being the testers.
MailEnable survivor / convert --
Tim Uzzanti Replied
Employee Post
SpamFoo is currently in beta. It is not enabled by default and is only available if you choose to try it. Yes, an installation issue has been identified. Its been offered FREE during the beta.  

It's important to keep things in perspective.
Tim Uzzanti
CEO
SmarterTools Inc.
Gabriele Maoret - SERSIS Replied
Tim, I like the idea, and I know it's in beta. I'd love to test it and give you some suggestions.

I can't wait to see it work in the next version (there's a bug that's blocking me in the current one).

The only thing that worries me is false positives.
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS
Currently manages 7 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 6 on-premise for customers who prefer to have their mail server in-house)
Tim Uzzanti Replied
Employee Post

Gabriele,

Once we fix the service not working for certain installations, a good way to handle it is to assign SpamFoo a lower weight. For example, when we first started, we gave it little to no weight in our overall spam scoring. As we became more comfortable and started removing other spam checks, we gradually increased its weight.

Now, it's essentially the only thing we use, aside from some built-in spam checks included with SmarterMail.

Tim Uzzanti
CEO
SmarterTools Inc.

Reply to Thread

Enter the verification text