I had a strange problem today. Due to an administrative error (still big hole in the foot) I lost my mailcow volumes and had to set up the docker containers again to apply a restore of one of my mailcow backups. This caused the mailcow setup to run for some time (between docker compose and the mailcow restore) without the valid configuration for the given domain/host. After some minutes my SSH/putty session, which I used to do the administration, got kicked and I was unable to SSH into the host anymore. I then logged in via the host’s remote console and after some searching I found out, that mailcow had set some firewall rules:
Chain MAILCOW (2 references)
target prot opt source destination
REJECT all -- myclient.dip0.t-connect.de anywhere reject-with icmp-port-unreachable
REJECT all -- otherclient.dip0.t-connect.de anywhere reject-with icmp-port-unreachable
After I stopped the mailcow containers, the rules disappeared in iptables and I was able to log in again on my host.
My idea what happened: On my client (and on the other client) already running mail clients (Outlook, whatever) were repeatedly trying to poll the mail server via IMAP. Because of the missing config, this failed. Some watch guard process in the mailcow setup monitored the failed poll requests, counted them up and after some attempts decided that this client is “attacking” the IMAP server. The watch guard set a firewall rule to block further requests from this client. Sorry if I’m completely wrong, but my knowledge about what’s going on inside the mailcow containers is limited.
- Did someone else run into such a problem?
- Why is mailcow blocking all ports for the respective client (even PING), and not only the ports which it is servicing? Pretty pretentious, isnt’t it?
- Is there any workaround to temporarily disable this protection? I want to stay logged in via SSH and complete my work, and not perform some digression in using the rescue tools of my hosting provider…