Re: NAMESPACE empty when logging via haproxy but populated properly when logging directly
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
On 23/05/2025 13:53 EEST via dovecot <dovecot@dovecot.org> wrote:
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
It should work if you send cn, that should be supported. Are you sure you are sending SNI in your testing? e.g. with openssl you need to use -servername foobar to actually send SNI.
Aki
On 2025-05-23 12:57, Aki Tuomi via dovecot wrote:
It should work if you send cn, that should be supported. Are you sure you are sending SNI in your testing? e.g. with openssl you need to use -servername foobar to actually send SNI.
Aki
Thanks. Yeah I am sure. I am filtering by SNI on haproxy. My mail client is properly using SNI in TLS. Just confirmed it with wireshark:
Extension: server_name (len=17) Type: server_name (0) Length: 17 Server Name Indication extension Server Name list length: 15 Server Name Type: host_name (0) Server Name length: 12 Server Name: secret
Also on server I see PROXY V2 packets. I set haproxy to send authority TLV (which contains SNI value used by client) and it seems dovecot still does not make use of it.
TLV: (t=2,l=12) AUTHORITY Type: AUTHORITY (0x02) Length: 12 Value: secret
So it seems it is not supported by dovecot or it is a bug. What you think? Could you confirm that TLV AUTHORITY is supported by dovecot and this should work for sure? If this is a bug where should I report it?
DK
On 23/05/2025 18:01 EEST Damian via dovecot <dovecot@dovecot.org> wrote:
On 2025-05-23 12:57, Aki Tuomi via dovecot wrote:
It should work if you send cn, that should be supported. Are you sure you are sending SNI in your testing? e.g. with openssl you need to use -servername foobar to actually send SNI.
Aki
Thanks. Yeah I am sure. I am filtering by SNI on haproxy. My mail client is properly using SNI in TLS. Just confirmed it with wireshark:
Extension: server_name (len=17) Type: server_name (0) Length: 17 Server Name Indication extension Server Name list length: 15 Server Name Type: host_name (0) Server Name length: 12 Server Name: secret
Also on server I see PROXY V2 packets. I set haproxy to send authority TLV (which contains SNI value used by client) and it seems dovecot still does not make use of it.
TLV: (t=2,l=12) AUTHORITY Type: AUTHORITY (0x02) Length: 12 Value: secret
So it seems it is not supported by dovecot or it is a bug. What you think? Could you confirm that TLV AUTHORITY is supported by dovecot and this should work for sure? If this is a bug where should I report it?
DK
Hi!
It should work, I'll open a ticket about this.
Aki
On 23/05/2025 18:31 EEST DK via dovecot <dovecot@dovecot.org> wrote:
On 2025-05-23 17:15, Aki Tuomi via dovecot wrote:
Hi!
It should work, I'll open a ticket about this.
Aki
Thank you Aki a lot. Good day.
DK
Hi!
This has now been fixed, see https://github.com/dovecot/core/compare/df48cb8c8ce8c53f48072fc34afd26b20ebe...
Aki
On 2025-05-27 11:37, Aki Tuomi via dovecot wrote:
Hi!
This has now been fixed, see https://github.com/dovecot/core/compare/df48cb8c8ce8c53f48072fc34afd26b20ebe...
Hi. Thank you Aki! Greets.
On 2025-05-27 11:37, Aki Tuomi via dovecot wrote:
This has now been fixed, see https://github.com/dovecot/core/compare/df48cb8c8ce8c53f48072fc34afd26b20ebe...
Hello again.
While waiting for dovecot 2.4 fixed deb package I tested "local" and "local_name" behind haproxy on dovecot 2.3.21.1+dfsg1-1~bpo12+1
Seems there is different kind of bug. Please look into it.
Here are findings:
Log:
auth: Debug: client in: AUTH#0111#011CRAM-MD5#011service=imap#011secured=tls#011session=/njT1h42s2YKFhNk#011lip=Z.Z.Z.Z#011rip=Y.Y.Y.Y#011lport=993#011rport=26291#011real_lip=A.A.A.A#011real_rip=B.B.B.B#011real_lport=143#011real_rport=51062#011local_name=imap.fqdn.com
Result:
- "local" behind reverse proxy is properly passed to dovecot and seen by
dovecot and works
- "local_name" behind reverse proxy is properly passed to dovecot and seen by dovecot but does not work.
Tested configs and results:
WORKS:
- local Z.Z.Z.Z { ... }
DOES NOT WORK:
local_name imap.fqdn.com { ... }
local_name "imap.fqdn.com imap2.fqdn.com imap3.fqdn.com" { ... }
local Z.Z.Z.Z { local_name imap.fqdn.com { ... } }
local Z.Z.Z.Z { local_name "imap.fqdn.com imap2.fqdn.com imap3.fqdn.com" { ... } }
Greets. DK
On 27/05/2025 17:43 EEST DK via dovecot <dovecot@dovecot.org> wrote: On 2025-05-27 11:37, Aki Tuomi via dovecot wrote: This has now been fixed, see https://github.com/dovecot/ core/compare/ df48cb8c8ce8c53f48072fc34afd26b20ebe94cf%5E...34642ffa6b9eeea7b7a1d16e3325059937c8186b.patch Hello again. While waiting for dovecot 2.4 fixed deb package I tested "local" and "local_name" behind haproxy on dovecot 2.3.21.1+dfsg1-1~bpo12+1 Seems there is different kind of bug. Please look into it. Here are findings: Log: auth: Debug: client in: AUTH#0111#011CRAM-MD5#011service=imap#011secured=tls#011session=/ njT1h42s2YKFhNk#011lip=Z.Z.Z.Z#011rip=Y.Y.Y.Y#011lport=993#011rport=26291#011real_lip=A.A.A.A#011real_rip=B.B.B.B#011real_lport=143#011real_rport=51062#011local_name=imap.fqdn.com Result: - "local" behind reverse proxy is properly passed to dovecot and seen by dovecot and works - "local_name" behind reverse proxy is properly passed to dovecot and seen by dovecot but does not work. Tested configs and results: WORKS: - local Z.Z.Z.Z { ... } DOES NOT WORK: - local_name imap.fqdn.com { ... } - local_name "imap.fqdn.com imap2.fqdn.com imap3.fqdn.com" { ... } - local Z.Z.Z.Z { local_name imap.fqdn.com { ... } } - local Z.Z.Z.Z { local_name "imap.fqdn.com imap2.fqdn.com imap3.fqdn.com" { ... } } Greets. DK _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org Unfortunately we no longer look into 2.3 bugs as it's no longer under development. Aki
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
Proper link: [1] https://doc.dovecot.org/2.4.0/core/config/haproxy.html#tls-forwarding
participants (4)
-
Aki Tuomi
-
Damian
-
DK
-
dk+lists.dovecot.org＠7ns.eu