Miscellaneous first checks

• I checked that all ports are open and not blocked by my ISP / hosting provider.
• I know that SSL errors are likely the result of a wrong setup on the user side and not caused by DMS itself. I'm confident my setup is correct.

Affected Component(s)

fail2ban and setup.sh

What happened and when does this occur?

In the current state of my deployment, fail2ban eats all of the host's CPUs constantly when I enable it. If I disable it and restart the container, CPU load is around 2% on the machine. When it's enabled, it's at a steady 100%. There are also a good 30 fail2ban processes running in parallel.

I believe this occurred after I manually banned some IPs using setup.sh. Previously to banning them, fail2ban wasn't very effective (I also am facing #3178) but at least it didn't eat all CPU.

Sadly, I can't even try to rollback my changes, because now setup.sh is unable to unban these IPs (the output is: [ ERROR ] Fail2ban not running [ ERROR ] Aborting I suppose because it can't reach the fail2ban socket due to the high CPU load.)

What did you expect to happen?

I expected:

• fail2ban not to take all of the machine's CPU
• setup.sh to be able to unban the IPs I banned

How do we replicate the issue?

I'm really unsure if this can be reproduced, but here what I did:

1. Use setup.sh to ban around 8 IP addresses from the same subnet
2. Restart container

DMS version

v11.3.1

What operating system is DMS running on?

Linux

Which operating system version?

ArchLinux

What instruction set architecture is DMS running on?

AMD64 / x86_64

What container orchestration tool are you using?

Docker Compose

docker-compose.yml

services:
  mailserver:
    image: docker.io/mailserver/docker-mailserver:latest
    container_name: mailserver
    # If the FQDN for your mail-server is only two labels (eg: example.com),
    # you can assign this entirely to `hostname` and remove `domainname`.
    hostname: mail
    domainname: mydomain.com
    env_file: mailserver.env
    environment:
      - VIRTUAL_HOST=mail.mydomain.com
      - LETSENCRYPT_HOST=mail.mydomain.com
    # More information about the mail-server ports:
    # https://docker-mailserver.github.io/docker-mailserver/latest/config/security/understanding-the-ports/
    # To avoid conflicts with yaml base-60 float, DO NOT remove the quotation marks.
    ports:
      - "25:25"    # SMTP  (explicit TLS => STARTTLS)
      - "143:143"  # IMAP4 (explicit TLS => STARTTLS)
      - "465:465"  # ESMTP (implicit TLS)
      - "587:587"  # ESMTP (explicit TLS => STARTTLS)
      - "993:993"  # IMAP4 (implicit TLS)
      - "110:110"  # POP3
      - "995:995"  # POP3 (with TLS)
    volumes:
      - ./docker-data/dms/mail-data/:/var/mail/
      - ./docker-data/dms/mail-state/:/var/mail-state/
      - ./docker-data/dms/mail-logs/:/var/log/mail/
      - ./docker-data/dms/config/:/tmp/docker-mailserver/
      - /etc/localtime:/etc/localtime:ro
      - ../../reverse_proxy/docker-data/nginx-proxy/certs/:/etc/letsencrypt/live/:ro
    restart: always
    stop_grace_period: 1m
    cap_add:
      - NET_ADMIN
    healthcheck:
      test: "ss --listening --tcp | grep -P 'LISTEN.+:smtp' || exit 1"
      timeout: 3s
      retries: 0

Relevant log output

No response

Other relevant information

No response

What level of experience do you have with Docker and mail servers?

• I am inexperienced with docker
• I am rather experienced with docker
• I am inexperienced with mail servers
• I am rather experienced with mail servers
• I am uncomfortable with the CLI
• I am rather comfortable with the CLI

Code of conduct

• I have read this project's Code of Conduct and I agree
• I have read the README and the documentation and I searched the issue tracker but could not find a solution

Improvements to this form?

No response