Golden rule: antispam checks, as any other security checks, should be
done on the edge.
This is important for any protocol, but for SMTP it's important even
more: without such a thing you become a backscatter - who accept mail
but then have to issue DSN bounce-back about reject - especially bad
when sender was spoofed which is common due to fact of many users not
have strict DMARC, etc.
You need to reject as much as possible in scope of edge SMTP session
(your cloud server), not on second hop. If you really want to have high
availability - better just build one instead - 2+ MTA's in cloud +
antispam, 2+ MTA's on-prem.
Your antispam can have postfilter that runs mentioned AI stuff only when
it "uncertain" (know it not bad and not too good), and send exact HTTP
payload to on-prem, as I understand that where you have compute power,
but all other checks done right in the cloud.
Spining up 2 Rspamds + Redis Master/Replica should not be hard.
Depending on how often you get your system down - you may consider
Sentinel, but it would be mean 3 servers (quorum).
It's tbh question of antispam solution, not MTA one's.
Regards,
Dmytro Alieksieiev
DevOps Engineer
On 17/07/2026 22:43, postfix--- via Postfix-users wrote:
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.
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
