email-oauth2-proxy: "Refused connection" when using versions 2023-03-09 or 2023-05-18 in Windows

I understand, I was just confused why the emailproxy seems to be inconsistent as to when it triggers involvement of the firewall.

IMAP, POP and SMTP all use TCP.

Thank you both for following up – this is really helpful.

It does seem like switching the proxy’s default local_address value to :: would resolve this, and also in most cases avoid the need to investigate other issues that have been reported for related reasons (e.g., #152, #162, #178).

I will test this in various scenarios, and assuming all goes well, plan to integrate this change in the next release.

1. IPv4: local_address = 127.0.0.1

• Works if clients point to localhost (i.e., 127.0.0.1)
• Does not work if clients point to localhost6 (i.e., ::1)

1. IPv6: local_address = ::1

• Does not work if clients point to localhost (i.e., 127.0.0.1)
• Works if clients point to localhost6 (i.e., ::1)

1. Dual-stack: local_address = ::

• Works if clients point to localhost (i.e., 127.0.0.1)
• Works if clients point to localhost6 (i.e., ::1)

Looks coherent, but I’m not sure it was intentional to require users to add a local_address = :: setting for all servers (probably should be the new default) 😃

Regarding which of the two diffs has effect, it’s the second, on line 1925:

• Removed local_address from all servers
• Set AF_INET on line 1925
  • Clients pointed to localhost work
  • Clients pointed to localhost6 do not work
• Set AF_UNSPEC on line 1925
  • Clients pointed to localhost do not work
  • Clients pointed to localhost6 work

In the tests above I left AF_UNSPEC on line 1516 (it has no effect anyway).

BTW, I do all the testing on Fedora 38 installed on the real HW (not VM, containers, …).

I believe I have the same problem. Up to 2023-02-08 everything is fine, starting with 2023-03-09 I get connection errors.

I have boiled it down to socket_family=socket.AF_UNSPEC vs. socket_family=socket.AF_INET:

--- email-oauth2-proxy-2023-05-18/emailproxy.py      2023-05-18 21:59:31.000000000 +0200
+++ emailproxy.py       2023-06-28 12:55:56.167192118 +0200
@@ -1513,7 +1513,7 @@
         self.create_socket()
         self.connect(self.server_address)
 
-    def create_socket(self, socket_family=socket.AF_UNSPEC, socket_type=socket.SOCK_STREAM):
+    def create_socket(self, socket_family=socket.AF_INET, socket_type=socket.SOCK_STREAM):
         # connect to whichever resolved IPv4 or IPv6 address is returned first by the system
         for a in socket.getaddrinfo(self.server_address[0], self.server_address[1], socket_family, socket.SOCK_STREAM):
             super().create_socket(a[0], socket.SOCK_STREAM)
@@ -1922,7 +1922,7 @@
         self.bind(self.local_address)
         self.listen(5)
 
-    def create_socket(self, socket_family=socket.AF_UNSPEC, socket_type=socket.SOCK_STREAM):
+    def create_socket(self, socket_family=socket.AF_INET, socket_type=socket.SOCK_STREAM):
         # listen using both IPv4 and IPv6 where possible (python 3.8 and later)
         socket_family = socket.AF_INET6 if socket_family == socket.AF_UNSPEC else socket_family
         if socket_family != socket.AF_INET:

I use the proxy for:

• Sending (Gmail or O365) with mutt, which works fine with socket_family=socket.AF_UNSPEC only if I replace localhost (mapped to 127.0.0.1) with localhost6 (mapped to ::1).
• Receiving (IMAP) with fetchmail, same behavior as mutt (error when configured with localhost, fine when configured with localhost6).

Regardless, I still do not see why setting socket_family=socket.AF_UNSPEC would require the use of IPv6 addressing.