On 2025-05-22 17:41, dk+lists.dovecot....@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
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
