[pfx] Re: dual server configuration

Thank you, Wietse!

On 2026-07-16 11:21, Wietse Venema via Postfix-users wrote:
> postfix--- via Postfix-users:
>> Hello list!
>> 
>> I have set up a dual postfix configuration:  one cloud server and one 
>> server on-premises.

[SNIP]

>> Is there a way to configure the cloud instance:
>> - to wait for the receipt of a return code from the on-premises instance
>> - and to return that code to the sender?
> 
> You could configure "smtpd_proxy_filter = your-hidden-mta" on the
> (cloud) bastion host. Then, the hidden MTA can veto mail that arrives
> at the bastion MTA, and block it before the bastion replies to
> end-of-data. You need to have "smtpd_proxy_options =" i.e. empty.
> 
> smtpd_proxy_filter has limitations:
> 
> - The bastion MTA can't inspect or modify message content
>    (header/body_checks, milters).

I'll have to study smtpd_proxy_filter and its consequences/changes.

the first big consequence: bandwidth.  the only filtering remaining at 
the bastion will be a binary firewall.  it will transfer more (all) 
messages for on-premise processing.  there will also be more load on the 
network and delays while on-premise processing happens.

The fault-tolerance of the bastion will be gone.  Right now, if the 
network to the premises fails or the on-premises node is unavailable, 
the bastion is the buffering queue.  If the bastion has to synchronously 
wait for an on-premise verdict/veto, the nature of the queue and its 
fault tolerance will change?

I need to understand/quantify these consequences and whether they are 
tolerable in my circumstances; and if the hassle is worth the return 
feedback to tone-deaf senders that should already be aware of the 
negative consequences of commingling spam with ham at their nodes.

Digression:  Lawyer-me says that the right solution is to block the mass 
mailers until they fix the situation; and sue them for the damage that 
their decision to commingle traffic and/or not properly police/separate 
their customers causes to me and other inbox operators like me.  Then, 
MBA-me reminds me that being smart is often less expensive than being 
right; tech-me tells me that I can sink the spam into oblivion and move 
on; and economist-me reminds me that the design of the internet is prone 
to such externalities, and until functioning governance is updated to 
deal with the changed paradigm there is very little that a small peanut 
like me can do to effect change.

The consequence on compute would actually be positive.  The current 
setup has two instances of rspamd, with some duplication:  rspamd at the 
bastion checks SPF/DKIM/DMARC and other low-compute signals. 
Compute-intense rspamd content filters are on premises.  The resources 
on-premises are more than sufficient to take all of the miltering tasks.

Maybe there is a way to configure the bastion's postfix instance to 
issue the 5xy spam feedback to the sender only on some of the milter 
signals?

Right now, the bastion is configured to pass on the milter's signals on, 
as headers, to the on-premises node.

Ideally:
- most spam is rejected silently
- select identified spam, from the commingling servers -- legit 
hyperscale servers who are not policing their tenants strictly enough -- 
is sent a 5xy, with the message and its scoring headers passed on to the 
on-premises host, quarantined, for further analysis and possible 
contribution to that body of knowledge/intelligence that is anti-abuse.


> - The hidden MTA does not know the SMTP client IP address/hostname.
>    Fixing that would require changes to smtpd_proxy_filter so that it
>    can send XCLIENT commands to impersonate the SMTP client.

if I understand correctly, this may be a show-stopper.  "SMTP client IP 
address/hostname" is the one of the external party trying to send me an 
email?

currently, I use a simple Lua script in rspamd milter_headers.conf to 
add headers with tostring(task:get_from_ip()) / 
tostring(task:get_helo()) and that is an important part of the 
intelligence collection of information about that hostile and dynamic 
world out there.  In the work in progress, the IP address is logged, 
processed on-premises, and added to a body of knowledge about the 
outside world that informs updates of the firewall that is fed back to 
the bastion (and other nodes).  The value of this information is 
definitely higher than the value of giving finer grained feedback to 
mass mailers who don't deserve anything more than a hard block.

-- 
Yuv

_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]