postfix--- via Postfix-users:
> Hello list!
>
> I have set up a dual postfix configuration: one cloud server and one
> server on-premises. The split:
>
> cloud-instance (metered):
> - exposed to the hostile environment
> - does quick/basic/low-effort filtering (blocks at the firewall IP
> ranges from which I do not expect anything of value; and does basic
> sanity checks)
> - tunnels the messages to the on-premises instance
>
> on-premises (unmetered):
> - check for existence of alias / mailbox
> - fancy anti-spam filtering (local AI)
> - delivery to mailbox (hosted within the trusted perimeter)
>
> It works well. Almost all spam goes to /dev/null or equivalent.
> HOWEVER, it could do better on a specific use case:
>
> some large senders commingle spam with ham. the message passes the
> cloud-instance because I cannot hard-block google, microsoft,
> salesforce, etc. and they only get qualified as spam on the on-premises
> instance. so my cloud instance gives them a 2yz while I would like to
> give them a 5yz to inform big tech that they are being abused.
>
> 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).
- 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.
Wietse
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
