postfix service run into timeout, due to redis problems

[rudiratlos63]

I had to disable antispam on my Postfix because rspamd accesses Redis on localhost (IPv4: 127.0.0.1) and ::1 (IPv6). ::1 responds extremely slowly when called multiple times in a row (redis-cli -h ::1 -p 6379 ping). This causes rspamd to time out, which in turn causes Postfix to enter a 300-second timeout. So far, I haven't found a way in the web GUI to configure Redis or rspamd to use only the IPv4 localhost address (127.0.0.1) to work around this problem. However, running `redis-cli -h 127.0.0.1 -p 6379 ping` does not experience any delay.

[Igor]

The 300s timeout is Postfix's `milter_content_timeout` default, so the chain you describe is plausible — but IPv6 loopback isn't inherently slow, so something is dropping the traffic. Could you check a few things?

1. Is Redis actually listening on `::1`? `sockstat -6 | grep 6379` — and what does `bind` say in your redis.conf?
2. If it isn't listening there, you'd expect an instant connection refused rather than a delay. A delay that grows on retries (roughly 1s, 3s, 7s) is the signature of SYN packets being silently dropped.
3. Do you have any rule blocking IPv6, or any floating rule that isn't scoped away from `lo0`? Try `pfctl -s rules | grep lo0`, and enable logging on your block rules to see whether loopback IPv6 is being dropped.
4. What does `redis-cli -h ::1 -p 6379 --latency` show versus the same on 127.0.0.1?

As a workaround you can pin rspamd to IPv4 with `servers = "127.0.0.1:6379";` in `/usr/local/etc/rspamd/local.d/redis.conf` — there's no GUI option for it. But that's masking the symptom; the firewall rule is worth finding.