On 2025-05-22 17:41, dk+lists.dovecot.org@7ns.eu wrote:
On 2025-05-22 16:55, Aki Tuomi via dovecot wrote:
I see you a local 10.20.20.20 statement there, which changes how the inbox prefix behaves, and I'm guessing (?) you are testing from 10.20.20.20 as it's local, not remote.
Which would explain why.
Also to add a bit that the "local_ip" (not real_local_ip) gets updated with haproxy proxy protocol (when enabled), so it will remote haproxy's local IP.
Aki
Wow. Thank you. It works. I mangled a IPs little bit before I send them to mailist. All machines are in the same network. Client, Proxy, Server. All in the same subnet. This is first time I see such problem with server software and reverse proxy. Never seen similar problem. What exactly this "local" statement do? Mail client is in the same network as server, so after PROXY header is stripped, my mail client IP should be seen by dovecot exactly the same, so shouldn't dovecot treat those connections equally? oO
Thank you again for tip Aki. DK
Hmm, now I am struggling with "local_name" filtering in haproxy environment. According to dovecot docs [1] it could potentially work with "send-proxy-v2-ssl" configured on proxy backend. However my dovecot filter does not work. Have the same problem I had with "local" filter. Dovecot does not recognize this connection and does not filter config for it properly. I tried "send-proxy-v2-ssl-cn". Still the same. I even enabled ssl on dovecot globally with "ssl=required" to be sure dovecot does not disable some ssl logic when "ssl=no". Still no go. Seems like dovecot does not get or use TLS/SNI info from haproxy. Does it even work in such environment? Is it supported? Or is this a bug or maybe my error? Any clues please?
DK
[1] https://doc.dovecot.org/2.4.1/core/config/haproxy.html#tls-forwarding