On 2026-07-17 19:35, Dmytro Alieksieiev via Postfix-users wrote:
Golden rule: antispam checks, as any other security checks, should be done on the edge.
Maybe. I am not convinced. My general rule is to do security checks everywhere the benefit outweighs the cost. This can lead to checks at the edge, checks within, redundant checks, checks, checks, and more checks until it is no longer beneficial to check. And because my cost at the edge are different than my cost on-prem, sometimes that golden rule has an exception.
without such a thing you become a backscatter - who accept mail but then have to issue DSN bounce-back about reject
Really? I am not an email expert, but if my *receiving* cloud bastion has port 25 outgoing blocked, what backscatter does it cause? starting from port 25 out blocked, one way street, convince me in what case my system should send a message back to the sender.
You need to reject as much as possible in scope of edge SMTP session (your cloud server)
As much as economically reasonable. not as much as possible. Ends up being similar but not the same.
If you really want to have high availability - better just build one instead - 2+ MTA's in cloud + antispam, 2+ MTA's on-prem.
Define "high availability." What I try to achieve is: take ownership of the incoming message as early as possible and don't lose any message until you decide that you want to lose it. Fault tolerance.
Your antispam can have postfilter that runs mentioned AI stuff only when it "uncertain" (know it not bad and not too good)
This is indeed the design: block what can be blocked at the bastion. Quarantine the "uncertain" on-prem and run as much analysis as the altered cost/benefit enable.
Spining up 2 Rspamds + Redis Master/Replica should not be hard.
The drivers are security and cost, not difficulty. Spinning 2x = 2x cost. Unless it is >2x security, it is not desirable. I want to process as much traffic as possible with as little a vulnerable footprint as possible and as low a cost as possible in the cloud. On-prem, the economics change. The security does not. And please, Valkey, not Redis.
It's tbh question of antispam solution, not MTA one's.
TBH you're probably right. kindly point me to where antispam is properly discussed? I find the documentation of antispam solutions frustratingly sparse.
On one point of principle I disagree with above statement: in 2026 security (and antispam) should not be an afterthought. It was acceptable and understandable in the 70ies and 80ies when the paradigm on which the internet was designed was the resilience of a network of friendly nodes. It could be a justifiable second-thought when unfriendly nodes were added to the mix and there was still a somewhat defensible perimeter. Today, every line of code (supply chain attacks!) and every part of content can be hostile. The paradigm has shifted and security and anti-spam should be a major if not the primary consideration, and threfore relevant also to MTA. Golden sunset rule.
Best, Yuv _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
