Fix dovecot low-and-slow fail2ban gap; generalize findtime guidance

Same evasion pattern already fixed for sshd recurred against dovecot: a
coordinated IMAP password spray paced just outside the 30-minute findtime
window ran unbanned for days. Widened dovecot's findtime the same way,
and updated SETUP.md so future provisioning applies this to every
credential jail up front instead of waiting for it to reappear.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

SETUP.md

@@ -506,14 +506,19 @@ Enable jails for `sshd`, `postfix`, `postfix-sasl`, `postfix-rbl`,
 `/etc/fail2ban/jail.local`, all watching `/var/log/mail.log` /
 `/var/log/auth.log` / `/var/log/apache2/*.log` as appropriate.
 
-**Widen `sshd`'s `findtime` beyond the 30-minute default.** Default
-`findtime=30m`/`maxretry=3` only catches bursts — a bot that spaces login
-attempts ~33 minutes apart never accumulates 3 strikes inside any 30-minute
-window and is never banned at all (seen live on this host against
-`47.76.192.176`; check `fail2ban-client status sshd` and grep
-`/var/log/fail2ban.log` for `Found`/`Ban` counts per IP if a repeat
-offender never shows up banned). Fix in its own drop-in rather than
-editing the packaged jail file:
+**Widen `findtime` beyond the 30-minute default on every credential-auth
+jail, not just `sshd`.** Default `findtime=30m`/`maxretry=3` only catches
+bursts — a bot that spaces login attempts ~22-33 minutes apart never
+accumulates 3 strikes inside any 30-minute window and is never banned at
+all. Seen live on this host twice with the *identical* pacing trick:
+first against `sshd` (`47.76.192.176`, ~33min spacing), then — because
+only `sshd` got fixed at the time — against `dovecot`
+(`47.95.196.60`/`82.157.132.42`/`120.48.118.132`/others, ~22-25min
+spacing, coordinated multi-IP campaign, ran for days unbanned). Don't
+wait for it to recur in a third jail: apply the same override to every
+jail guarding a real credential (`sshd`, `dovecot`, `postfix-sasl`,
+`sieve`, `courier-auth` if in use) at provisioning time, each in its own
+drop-in rather than editing the packaged jail file:
 ```
 # /etc/fail2ban/jail.d/sshd-findtime.local
 [sshd]
@@ -521,10 +526,23 @@ findtime = 1d
 maxretry = 4
 bantime  = 1d
 ```
-`fail2ban-client reload sshd` applies it. Worth spot-checking the other
-jails' `Found`/`Ban` ratios the same way — a *distributed* variant (many
-different source IPs, each trying once) evades per-IP banning by design
-and needs subnet-level blocking instead, which `findtime` tuning can't fix.
+```
+# /etc/fail2ban/jail.d/dovecot-findtime.local
+[dovecot]
+findtime = 1d
+maxretry = 4
+bantime  = 1d
+```
+`fail2ban-client reload <jail>` applies each one. To check whether a jail
+still has the gap: `fail2ban-client status <jail>` for who's currently
+banned, cross-referenced against grepping the jail's own log
+(`/var/log/auth.log`, `/var/log/mail.log`, etc.) for per-IP hit counts —
+if an IP has dozens of failures spread evenly a few minutes past
+`findtime` apart and never shows up banned, that's this pattern. Also
+worth spot-checking the Apache jails' `Found`/`Ban` ratios the same way —
+a *distributed* variant (many different source IPs, each trying once)
+evades per-IP banning by design and needs subnet-level blocking instead,
+which `findtime` tuning can't fix.
 
 ### Bring it up
 
@@ -706,10 +724,11 @@ Run through this after everything above is live:
 - [ ] Disk partition actually uses the full disk (`df -h /` vs. `lsblk`/`parted ... print free` should agree)
 - [ ] `PermitRootLogin no` / `PasswordAuthentication no` — verify live with
       `sshd -T`, not just the config file (see §1)
-- [ ] `fail2ban-client status sshd` findtime is wide enough to catch
-      low-and-slow attempts, not just bursts (see §3) — spot-check
-      `/var/log/fail2ban.log` for any repeat-offender IP with several
-      `Found` entries but no `Ban`
+- [ ] `fail2ban-client status <jail>` findtime is wide enough to catch
+      low-and-slow attempts, not just bursts, for every credential jail
+      (`sshd`, `dovecot`, `postfix-sasl`, not just `sshd`) — see §3 —
+      spot-check `/var/log/fail2ban.log` for any repeat-offender IP with
+      several `Found` entries but no `Ban`
 - [ ] Any chrooted SFTP accounts (`/var/sftp/*`) no longer in active use are
       password-locked (`sudo passwd -S <user>` shows `L`), not left active