This is just a review comment for better git blame tracking (at least via Github Web UI if viewing this PR).

No change necessary.

Migrated from debugging.md and revised version of:

## Testing Connection

I spent HOURS trying to debug "Connection Refused" and "Connection closed by foreign host" errors when trying to use telnet to troubleshoot my connection. I was also trying to connect from my email client (macOS mail) around the same time. Telnet had also worked earlier, so I was extremely confused as to why it suddenly stopped working. I stumbled upon `fail2ban.log` in my container. In short, when trying to get my macOS client working, I exceeded the number of failed login attempts and fail2ban put dovecot and postfix in jail! I got around it by whitelisting my ipaddresses (my ec2 instance and my local computer)

```sh
sudo su
docker exec -it mailserver bash
cd /var/log
cat fail2ban.log | grep dovecot
# Whitelist IP addresses:
fail2ban-client set dovecot addignoreip <server ip>  # Server
fail2ban-client set postfix addignoreip <server ip>
fail2ban-client set dovecot addignoreip <client ip>  # Client
fail2ban-client set postfix addignoreip <client ip>
# This will delete the jails entirely - nuclear option
fail2ban-client stop dovecot
fail2ban-client stop postfix
```

We could (in the future) think about adding the ignoreip automatically with our scripts if that somehow makes sense (but I see no obvious reason to do so at the moment).

If you get more users needing it, sure. This was contributed by one this year I think and I noticed that we don't document it, so users will need to hunt it down like this contributor did.

Your revised version moved into the FAQ instead instructs how to unban, which is helpful, I don't use F2B and assume the ignore is mostly useful when troubleshooting or working around an issue where unban would be tedious..

If you get more users needing it, sure. This was contributed by one this year I think and I noticed that we don't document it, so users will need to hunt it down like this contributor did.

Your revised version moved into the FAQ instead instructs how to unban, which is helpful, I don't use F2B and assume the ignore is mostly useful when troubleshooting or working around an issue where unban would be tedious..

Likewise, it looks like the usage.md docs jump straight to using setup only indirectly mentioning up / down vs start / stop gotcha and "On first start".

I suppose the single line here is a bit more direct of an instruction to the reader 😅 (the advice to check output for errors is probably good to communicate too, and could link to the debugging page)

The numbered steps is probably a bit more helpful in structure / flow, as that seems to get a bit messy when looking at the actual rendering of the docs pages like usage.md.

For example we have "Get Up and Running" with two paragraphs and some admonitions interleaved, and then a larger heading "Further Miscellaneous Steps", but the "That's it! It really is that easy." doesn't feel like the guide finishes a running setup here.

The main docker-compose.yaml example we advise to start with omits these, deferring to mailserver.env. That file is not here keeping config simple, you can just copy/paste the wget approach.

Focuses on the most common SSL_TYPE value, and I assume DMS is popular for having other containers send mail through it. The SPOOF_PROTECTION doesn't matter too much here, but for the guide we get a nice comment about it.

This section can be dropped in a future release. The change detection service can support LDAP for updating certs without needing a community script, just needs to conditionally avoid the other config change handling.

👍🏼