[pfx] Re: dual server configuration

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]