[pfx] Re: dual server configuration

This is a multi-part message in MIME format.
--===============6431087798193355998==
Content-Type: multipart/alternative;
 boundary="------------atmq1Lb9w5cpDgYXAeehMFzS"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------atmq1Lb9w5cpDgYXAeehMFzS
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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.
>
--------------atmq1Lb9w5cpDgYXAeehMFzS
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Golden rule: antispam checks, as any other security checks,
      should be done on the edge.</p>
    <p>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.</p>
    <p>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.</p>
    <p>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.</p>
    <p>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).</p>
    <p>It's tbh question of antispam solution, not MTA one's.</p>
    <pre class="moz-signature" cols="72">Regards,
Dmytro Alieksieiev
DevOps Engineer</pre>
    <div class="moz-cite-prefix">On 17/07/2026 22:43, postfix--- via
      Postfix-users wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:[email protected]">Thank
      you, Wietse!
      <br>
      <br>
      On 2026-07-16 11:21, Wietse Venema via Postfix-users wrote:
      <br>
      <blockquote type="cite">postfix--- via Postfix-users:
        <br>
        <blockquote type="cite">Hello list!
          <br>
          <br>
          I have set up a dual postfix configuration:  one cloud server
          and one server on-premises.
          <br>
        </blockquote>
      </blockquote>
      <br>
      [SNIP]
      <br>
      <br>
      <blockquote type="cite">
        <blockquote type="cite">Is there a way to configure the cloud
          instance:
          <br>
          - to wait for the receipt of a return code from the
          on-premises instance
          <br>
          - and to return that code to the sender?
          <br>
        </blockquote>
        <br>
        You could configure "smtpd_proxy_filter = your-hidden-mta" on
        the
        <br>
        (cloud) bastion host. Then, the hidden MTA can veto mail that
        arrives
        <br>
        at the bastion MTA, and block it before the bastion replies to
        <br>
        end-of-data. You need to have "smtpd_proxy_options =" i.e.
        empty.
        <br>
        <br>
        smtpd_proxy_filter has limitations:
        <br>
        <br>
        - The bastion MTA can't inspect or modify message content
        <br>
           (header/body_checks, milters).
        <br>
      </blockquote>
      <br>
      I'll have to study smtpd_proxy_filter and its
      consequences/changes.
      <br>
      <br>
      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.
      <br>
      <br>
      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?
      <br>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      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?
      <br>
      <br>
      Right now, the bastion is configured to pass on the milter's
      signals on, as headers, to the on-premises node.
      <br>
      <br>
      Ideally:
      <br>
      - most spam is rejected silently
      <br>
      - 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.
      <br>
      <br>
      <br>
      <blockquote type="cite">- The hidden MTA does not know the SMTP
        client IP address/hostname.
        <br>
           Fixing that would require changes to smtpd_proxy_filter so
        that it
        <br>
           can send XCLIENT commands to impersonate the SMTP client.
        <br>
      </blockquote>
      <br>
      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?
      <br>
      <br>
      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.
      <br>
      <br>
    </blockquote>
  </body>
</html>

--------------atmq1Lb9w5cpDgYXAeehMFzS--

--===============6431087798193355998==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============6431087798193355998==--