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.