"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.
