postfix--- via Postfix-users:
> 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?
In my smtpd_proxy_filter proposal there is no queue on the bastion
host.
internet -> bastion (postscreen -> smtpd)
-> hidden (smtpd -> cleanup -> queue...)
This also means no backscatter when the hidden smtpd rejects
some remote client command.
Wietse
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
