On 2021-06-01, Cameron Simpson <c...@cskk.id.au> wrote: > If I had TCP keep alive turned on, both ends might tidy themselves up. > I can't enable that on the clients (various mail readers) or, > apparently, on the server configuration. I can't do it in PF because PF > just copies packets. I can't seem to do it in relayd either, though that > seems the obvious way to intercept the connection for this purpose.
It looks like courier-imap does enable SO_KEEPALIVE if available. By default, keepalive timers are long; on a random Linux I had handy: $ grep . /proc/sys/net/ipv4/tcp_keepalive_* /proc/sys/net/ipv4/tcp_keepalive_intvl:75 /proc/sys/net/ipv4/tcp_keepalive_probes:9 /proc/sys/net/ipv4/tcp_keepalive_time:7200 7200s (2h) initially, then every 75 seconds. (OpenBSD default times are long too; 14400 "slowhz" intervals = also 2h). > Plan B is to build the latest courier-imap from source if I find the > time, but there may be no build option for this. I guess a single > setsockopt() call in the source would be enough, _if_ that can be done > on the accept end, which I haven't checked. https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/addsupport.html but I don't think you'll need it. So you probably just need to lower tcp_keepalive_time, and perhaps adjust tcp_keepalive_intvl. Note there is a tradeoff especially with mobile clients; they will need to wake and transmit more often, so faster keepalives will result in more battery/data use. > Plan B0 might be to disable IMAP IDLE support. Hmm. Depends on timings whether that will help; think it's a last ditch effort though, I think it will make things noticably worse for clients.
