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]
