Posteio and rootless container, how can I view the true IP addresses that are coming in?

Here are the basics: I am running Poste.io via a Quadlet, hosted on a VPS, with all the proper ports exposed for email. Email works fine—I am able to send and receive—but the problem is that since the ports are exposed to the internet, bots scan them and then launch an all-out attack on the server, trying different combinations of usernames and passwords in an attempt to gain access. To mitigate this, I originally had Fail2Ban running, but I switched to CrowdSec. I then created a shell script to grab the failed addresses from Haraka and feed them into CrowdSec. However, that does not work because it is running rootless, and the only IP address that is shown is the container’s address, not the individual bot’s. I have tried everything I can think of, but I keep running into the same problem: there is no method for intercepting the IP addresses of the bots, since they are coming through as normal traffic and Haraka does not receive the real IP address. I found Haraka’s actual real-time connection log inside the Poste.io container—an s6-supervised log, separate from the stale /var/log/mail.log (last modified August 26th) and from podman logs posteio (which is empty; Poste.io routes service output through s6, not container stdout). At level=protocol in log.ini, Haraka emits one structured [NOTICE] ... disconnect ip=... errors=... txns=... lr="..." summary line per connection—a good target for a future CrowdSec parser, if one is ever built.Root cause: rootless Podman masks all real client IPsEvery single sampled disconnect ip= line showed 10.89.4.50—Poste.io’s own container IP on the mailnet bridge network—regardless of the real external sender. This was confirmed via a frequency count: 49 out of 49 sampled connections showed this same internal IP.Rootless Podman’s default port-forwarder (rootlessport) is a userspace proxy that does not preserve real client source IPs. Every external connection to a published port appears internally as coming from the container’s own bridge/gateway address.This means no CrowdSec parser or scenario built against Haraka’s logs can ever work correctly today—every external attacker is indistinguishable from internal traffic, and would either be silently whitelisted (CrowdSec’s private-IP suppression) or, if that suppression were disabled, risk banning the container’s own gateway address.Does anyone know of a way to overcome this problem? I briefly tried HAProxy, but ran into the same situation (Podman instances are created on the fly, so it could not bind to one specific location).