On 9/4/23 8:11 AM, Jochen Bern wrote:

Define "disabled", please. I don't have many Ubuntu systems around, but on the RHEL/CentOS/Fedora ones, even if they have IPv6 set to "Ignore", the interfaces get link-local IPv6 addresses assigned - at which point IPv6 LISTENs will work, too.

Of course, if you "disabled" IPv6 by compiling a kernel without the code relevant to it (is it still possible to do that?), various things might break *hard* ...

Both NetworkManager and netplan(5) allow one to disable IPv6 without a kernel recompile. All my servers have IPv6 completely turned off.

root@smtp:~# ifconfig enp1s0: flags=4163 mtu 1500 inet redacted netmask 255.255.255.248 broadcast redacted ether 00:e0:67:1f:3a:62 txqueuelen 1000 (Ethernet) RX packets 1052492 bytes 194759633 (194.7 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 85054 bytes 7717020 (7.7 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 memory 0xd0700000-d0720000

enp2s0: flags=4163 mtu 1500 inet redacted netmask 255.255.255.0 broadcast redacted ether 00:e0:67:1f:3a:63 txqueuelen 1000 (Ethernet) RX packets 176303 bytes 15169693 (15.1 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 158574 bytes 93040074 (93.0 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 17 memory 0xd0600000-d0620000

enp2s0.2: flags=4163 mtu 1500 inet redacted netmask 255.255.255.0 broadcast redacted ether 00:e0:67:1f:3a:63 txqueuelen 1000 (Ethernet) RX packets 8 bytes 368 (368.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3 bytes 126 (126.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1000 (Local Loopback) RX packets 6673 bytes 598867 (598.8 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 6673 bytes 598867 (598.8 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

My instance of dovecot works because I specified IPv4 only in the configuration file, specifically /etc/dovecot/conf.d/10-master.conf -- and here is what I wrote to the original poster:

On 9/4/23 7:12 AM, TWHG Technical via dovecot wrote:

I have a parallel problem to yours, in that my upstream has an incomplete implementation of IPv6 and, more importantly, no support for mail servers with IPv6 addresses. Yes, it's unfortunate that Dovecot does not deal properly with missing dual stack. But, there it is.

So you are submitting a feature request that Dovecot work with single-stack configurations out-of-the-box -- but I wouldn't hold my breath.

Proper and secure administration of servers cannot be done blindly. In the decades I've been doing this, I've never trusted any solution to be perfect right out of the box -- it's unreasonable. You *have* to configure some things on servers; we aren't talking about consumer-grade equipment or software here. You HAVE to examine your logs, and take action when told something is broken. To do otherwise is a recipe for disaster.

You need to learn the structure of the dovecot configuration system. It a commonly-used layered configuration system, so that you don't have to mess with the master configuration file. For example, here are the first few lines of /etc/dovecot/10-master.conf on my mail system (default values are in comments):

...

listen = *

#default_process_limit = 100 #default_client_limit = 1000

# Default VSZ (virtual memory size) limit for service processes. This is mainly # intended to catch and kill processes that leak memory before they eat up # everything. #default_vsz_limit = 256M

# Login user is internally used by login processes. This is the most untrusted # user in Dovecot system. It shouldn't have access to anything at all. #default_login_user = dovenull

# Internal user is used by unprivileged processes. It should be separate from # login user, so that login processes can't disturb other processes. #default_internal_user = dovecot

service imap-login { inet_listener imap { address = 127.0.0.1 <redacted> port = 143 } inet_listener imaps { address = 127.0.0.1 <redacted> port = 993 ssl = yes }

# Number of connections to handle before starting a new process. Typically # the only useful values are 0 (unlimited) or 1. 1 is more secure, but 0 # is faster. #service_count = 1

# Number of processes to always keep waiting for more connections. #process_min_avail = 0

# If you set service_count=0, you probably need to grow this. #vsz_limit = $default_vsz_limit }

There is more, but you get the idea.