@Christophe
Changing products will not solve your problem until you understand your requirements. Their are four different mail flows, each of which may create requirements for you:
- Inbound mail
- Internal-only mail
- Outbound mail
- Relayed mail (mailing lists, auto-forwarding)
As much as possible, I want to keep these flows separated, because they have different requirements. So I want my inbound filtering to occur on inbound gateways, and my outbound filtering to occur on an outbound gateway. A gateway is fully independent of the main mail server, so your options are unlimited.
For outbound mail, we require an "encryption" solution based on secure web relay, and I tend to think that every system should offer it as well. Zixmail pioneered this concept, but nobody seems to offer it as a standalone product any more, not even the current owners of Zixmail. So you pretty much have to buy an inbound filtering product to get outbound web relay. We currently use a Barracuda Email Security Gateway appliance for this purpose, and have been doing so for many years.
The purpose of inbound filtering is to deliver all of the mail that is wanted by your organization, and doing something appropriate with all of the unwanted mail. There is no vendor who knows which mail is wanted by your organization. The only want to get this result is for your organization to acquire the tools you need to define your own "wanted mail" list. The more that you are willing to put into this effort, the better the results you will get. Some very common requirements fall out of this simple principle.
Inbound message review
First, you need to be able to look at recently received mail and say, "Do I want that?" This means you need a really good message review interface. You need to be able to see every delivered message to see if it might be unwanted (or dangerous), and every undelivered message that might possibly be wanted. Can you pull up a list of the last 100 messages received to perform this analysis, and see it in list form? What information do you need to see in the list to make a correct judgement? Can you drill into any single list entry to review the full message in both raw and formatted modes?
SmarterMail has an inadequate tool for reviewing quarantine, and no tool for other messages. Declude has no message review interface at all. I am told that rSpamD has a web interface but it is not intended to meet this need. SpamFoo improves the SmarterMail review capability, but user have already complained that the subject text is not part of the messsage list. My Barracuda appliance has a pretty good message review interface, and it provides visibility to a 90-day log of every message, so it is my primary review tool But I also use custom code to capture a 90-day history of message metadata into a SQL database. I use SQL queries against that metadata to meet needs that the Barracuda does not address.
During the message audit, you will probably find messages that you do not want to ever see again. Malicious messages always come from malicious senders, and unwanted messages often come from unwanted senders. So you will generally want to respond to an unwanted message by creating a local policy rule to block the identifiers which represent the unwanted sender. Fortunately, most products offer the ability to create these rules. Figuring out which identifiers to block is your problem. I have not seen anything that simplifies converting an unwanted message to an unwanted sender rule, but I fantasize about buying or building that feature someday. Blocking all of those unwanted senders can become time consuming.
During the audit, you will also find messages should have been delivered, but were not. These need to become local policy rules that allow-list all messages from the wanted sender. This needs to be done without create a security hole that allows an impersonation of that sender to be accepted as well. This means that you unconditionally accept messages from
example.com if the identity is verified, and you quarantine the message if the identity cannot be verified. Unfortunately, I have yet to find a product that can allow-list without creating a security hole for impersonation. This is a scandal for the email filtering industry, and some day an enterprising tort lawyer will file a class action suit against them for gross negligence.
Every message has at least one verified identifier, the source IP. Most messages have a host name that can be verified by forward-confirmed DNS. If a wanted message does not produce SPF Pass, an equivalent can be achieved in local policy using verified server identity and the corresponding Mail From domain. A similar strategy can be used to authenticate From addresses that cannot be verified by the DMARC algorithm. You just need a local policy structure that allows you to define those authentication rules and a rules engine to check them.
Because I could not buy a secure solution at any price, I had to build one. My solution is currently using SmarterMail Free as the message transport, Declude Classic as the rules engine, and Python scripts called by Declude to do the heavy lifting, Over time, the Python logic may get rewritten into something else for performance, SmarterMail Free may be replaced by PostFix, and Declude Classic may be replaced by Declude Reboot or the PostFix milter for Python. Barracuda may suffer a forced migration if the vendor abandons the appliance market, but they just accepted a three-year support renewal, so I have some time. The pieces have become less important, because the design is what matters.
Once you start building a flexible custom solution, you can respond to new situations. Within the last few months, I had to scramble to add filtering rules based on the Reply-To address. But the structure was in place so the problem was quickly solved.
The recent wave of attacks are intended to overwhelm every filtering system, because:
- The messages are fully authenticated.
- The identifiers change frequently, so you have no prior reputation data on any of them.
- The content changes frequently, so you have great difficulty blocking based on regular expressions.
I have concluded that there are only two ways to solve this attack strategy:
- Find an AI solution that is smart enough to understand intent, which is why SpamFoo is important to us.
- Quarantine any message without a known reputation, and then use my quarantine review tools to identify the tiny subset of messages which represent wanted senders.
I chose the second option, and it is working acceptably for me.