Added post_installation Section + Translated it to German

2022-01-29 23:04:38 +01:00 · 2022-01-29 23:04:38 +01:00 · 5412524807
Commit 5412524807
--- a/docs/i_u_m/i_u_m_migration.de.md
+++ b/docs/i_u_m/i_u_m_migration.de.md
@ -5,7 +5,7 @@
    Alternativ können Sie das Skript `./helper-scripts/backup_and_restore.sh` verwenden, um ein vollständiges Backup auf der Quellmaschine zu erstellen, dann installieren Sie mailcow auf der Zielmaschine wie gewohnt, kopieren Sie Ihre `mailcow.conf` und verwenden Sie das gleiche Skript, um Ihr Backup auf der Zielmaschine wiederherzustellen.
 **1\.** 
-Installieren Sie [Docker] (https://docs.docker.com/engine/installation/linux/) und [Docker Compose] (https://docs.docker.com/compose/install/) auf Ihrem neuen Server.
+Installieren Sie [Docker](https://docs.docker.com/engine/installation/linux/) und [Docker Compose](https://docs.docker.com/compose/install/) auf Ihrem neuen Server.
 Schnelle Installation für die meisten Betriebssysteme:
--- a/docs/index.de.md
+++ b/docs/index.de.md
@ -2,9 +2,9 @@
 ## Hilf dem mailcow Projekt
-Bitte erwägen Sie einen Supportvertrag gegen eine geringe monatliche Gebühr unter [Servercow EN](https://www.servercow.de/mailcow?lang=en#support)/[Servercow DE](https://www.servercow.de/mailcow?#support), um die weitere Entwicklung zu unterstützen. _Wir_ unterstützen _Dich_, während _Du_ _uns_ unterstützt. :)
+Bitte erwägen Sie einen Supportvertrag gegen eine geringe monatliche Gebühr unter [Servercow DE](https://www.servercow.de/mailcow?#support), um die weitere Entwicklung zu unterstützen. _Wir_ unterstützen _Dich_, während _Du_ _uns_ unterstützt. :)
-Wenn du super toll bist und ohne Vertrag unterstützen möchtest, kannst du eine SAL-Lizenz bekommen, die deine Tollheit bestätigt (eine flexible Einmalzahlung) bei [Servercow EN](https://www.servercow.de/mailcow?lang=en#sal)/[Servercow DE](https://www.servercow.de/mailcow#sal).
+Wenn du super toll bist und ohne Vertrag unterstützen möchtest, kannst du eine SAL-Lizenz bekommen, die deine Tollheit bestätigt (eine flexible Einmalzahlung) bei [Servercow DE](https://www.servercow.de/mailcow#sal).
 ## Support erhalten
@ -12,7 +12,7 @@ Es gibt zwei Möglichkeiten, Support für Ihre mailcow-Installation zu erhalten.
 ### Kommerzieller Support
-Für professionellen und priorisierten kommerziellen Support können Sie ein Basis-Support-Abonnement unter [Servercow EN](https://www.servercow.de/mailcow?lang=en#support)/[Servercow DE](https://www.servercow.de/mailcow#support) abschließen. Für kundenspezifische Anfragen oder Fragen kontaktieren Sie uns stattdessen bitte unter [info@servercow.de](mailto:info@servercow.de).
+Für professionellen und priorisierten kommerziellen Support können Sie ein Basis-Support-Abonnement unter [Servercow DE](https://www.servercow.de/mailcow#support) abschließen. Für kundenspezifische Anfragen oder Fragen kontaktieren Sie uns stattdessen bitte unter [info@servercow.de](mailto:info@servercow.de).
 Darüber hinaus bieten wir auch eine voll ausgestattete und verwaltete Mailcow [hier](https://www.servercow.de/mailcow#managed) an. Auf diese Weise kümmern wir uns um die technische Magie darunter und Sie können Ihr ganzes Mail-Erlebnis auf eine problemlose Weise genießen.
@ -37,7 +37,7 @@ Nur für **Fehlerverfolgung, Feature Requests und Codebeiträge**:
 Sie können eine Demo unter [demo.mailcow.email](https://demo.mailcow.email) finden, benutzen Sie die folgenden Anmeldedaten zum Login:
 - **Administrator**: admin / moohoo
- **Domänen-Administrator**: Abteilung / moohoo
+- **Domänen-Administrator**: department / moohoo
 - **Postfach**: demo@440044.xyz / moohoo
 ## Überblick
--- a/docs/post_installation/firststeps-disable_ipv6.de.md
+++ b/docs/post_installation/firststeps-disable_ipv6.de.md
@ -0,0 +1,83 @@
 Dies wird **NUR** empfohlen, wenn Sie kein IPv6-fähiges Netzwerk auf Ihrem Host haben!
 Wenn Sie es wirklich brauchen, können Sie die Verwendung von IPv6 in der Compose-Datei deaktivieren.
 Zusätzlich können Sie auch den Start des Containers "ipv6nat-mailcow" deaktivieren, da er nicht benötigt wird, wenn Sie IPv6 nicht verwenden.
 Anstatt die Datei docker-compose.yml direkt zu bearbeiten, ist es besser, eine Override-Datei zu erstellen 
 zu erstellen und Ihre Änderungen am Dienst dort zu implementieren. Leider scheint dies im Moment nur für Dienste zu funktionieren, nicht für Netzwerkeinstellungen.
 Um IPv6 im mailcow-Netzwerk zu deaktivieren, öffnen Sie docker-compose.yml mit Ihrem bevorzugten Texteditor und suchen Sie nach dem Netzwerk-Abschnitt (er befindet sich am Ende der Datei). 
 **1.** Ändern Sie docker-compose.yml
 Ändern Sie `enable_ipv6: true` in `enable_ipv6: false`:
 ```
 networks:
  mailcow-network:
    [...]
    enable_ipv6: true # <<< auf false setzen
    [...]
 ```
 **2.** ipv6nat-mailcow deaktivieren
 Um den ipv6nat-mailcow Container ebenfalls zu deaktivieren, gehen Sie in Ihr mailcow Verzeichnis und erstellen Sie eine neue Datei namens "docker-compose.override.yml": 
 **HINWEIS:** Wenn Sie bereits eine Override-Datei haben, erstellen Sie diese natürlich nicht neu, sondern fügen Sie die untenstehenden Zeilen entsprechend in Ihre bestehende Datei ein!
 ```
 # cd /opt/mailcow-dockerized
 # touch docker-compose.override.yml
 ```
 Öffnen Sie die Datei in Ihrem bevorzugten Texteditor und tragen Sie folgendes ein:
 ```
 version: '2.1'
 services:
    ipv6nat-mailcow:
      image: bash:latest
      neustart: "no"
      entrypoint: ["echo", "ipv6nat disabled in compose.override.yml"]
 ```
 Damit diese Änderungen wirksam werden, müssen Sie den Stack vollständig stoppen und dann neu starten, damit Container und Netzwerke neu erstellt werden:
 ```
 docker-compose down
 docker-compose up -d
 ```
 **3.** Deaktivieren Sie IPv6 in unbound-mailcow
 Bearbeiten Sie `data/conf/unbound/unbound.conf` und setzen Sie `do-ip6` auf "no":
 ```
 Server:
  [...]
  do-ip6: no
  [...]
 ```
 unbound neu starten:
 ```
 docker-compose restart unbound-mailcow
 ```
 **4.** Deaktivieren Sie IPv6 in postfix-mailcow
 Erstellen Sie `data/conf/postfix/extra.cf` und setzen Sie `smtp_address_preference` auf `ipv4`:
 ```
 smtp_address_preference = ipv4
 inet_protocols = ipv4
 ```
 Starten Sie Postfix neu:
 ```
 docker-compose restart postfix-mailcow
 ```
--- a/docs/post_installation/firststeps-disable_ipv6.en.md
+++ b/docs/post_installation/firststeps-disable_ipv6.en.md
@ -0,0 +1,83 @@
 This is **ONLY** recommended if you do not have an IPv6 enabled network on your host!
 If you really need to, you can disable the usage of IPv6 in the compose file.
 Additionally, you can  also disable the startup of container "ipv6nat-mailcow", as it's not needed if you won't use IPv6.
 Instead of editing docker-compose.yml directly, it is preferable to create an override file for it 
 and implement your changes to the service there. Unfortunately, this right now only seems to work for services, not for network settings.
 To disable IPv6 on the mailcow network, open docker-compose.yml with your favourite text editor and search for the network section (it's near the bottom of the file). 
 **1.** Modify docker-compose.yml
 Change `enable_ipv6: true` to `enable_ipv6: false`:
 ```
 networks:
  mailcow-network:
    [...]
    enable_ipv6: true # <<< set to false
    [...]
 ```
 **2.** Disable ipv6nat-mailcow
 To disable the ipv6nat-mailcow container as well, go to your mailcow directory and create a new file called "docker-compose.override.yml": 
 **NOTE:** If you already have an override file, of course don't recreate it, but merge the lines below into your existing one accordingly!
 ```
 # cd /opt/mailcow-dockerized
 # touch docker-compose.override.yml
 ```
 Open the file in your favourite text editor and fill in the following:
 ```
 version: '2.1'
 services:
    ipv6nat-mailcow:
      image: bash:latest
      restart: "no"
      entrypoint: ["echo", "ipv6nat disabled in compose.override.yml"]
 ```
 For these changes to be effective, you need to fully stop and then restart the stack, so containers and networks are recreated:
 ```
 docker-compose down
 docker-compose up -d
 ```
 **3.** Disable IPv6 in unbound-mailcow
 Edit `data/conf/unbound/unbound.conf` and set `do-ip6` to "no":
 ```
 server:
  [...]
  do-ip6: no
  [...]
 ```
 Restart Unbound:
 ```
 docker-compose restart unbound-mailcow
 ```
 **4.** Disable IPv6 in postfix-mailcow
 Create `data/conf/postfix/extra.cf` and set `smtp_address_preference` to `ipv4`:
 ```
 smtp_address_preference = ipv4
 inet_protocols = ipv4
 ```
 Restart Postfix:
 ```
 docker-compose restart postfix-mailcow
 ```
--- a/docs/post_installation/firststeps-dmarc_reporting.de.md
+++ b/docs/post_installation/firststeps-dmarc_reporting.de.md
@ -0,0 +1,125 @@
 Die DMARC-Berichterstattung erfolgt über das Rspamd DMARC-Modul.
 Die Rspamd-Dokumentation finden Sie hier: https://rspamd.com/doc/modules/dmarc.html
 **Wichtig:**
 1. Ändern Sie `example.com`, `mail.example.com` und `Example` so, dass sie Ihrer Einrichtung entsprechen
 2. Die DMARC-Berichterstattung erfordert zusätzliche Aufmerksamkeit, insbesondere in den ersten Tagen
 3. Alle empfangenden Domains, die auf mailcow gehostet werden, senden von einer Reporting-Domain. Es wird empfohlen, die übergeordnete Domain Ihres `MAILCOW_HOSTNAME` zu verwenden:
    - Wenn Ihr `MAILCOW_HOSTNAME` `mail.example.com` ist, ändern Sie die folgende Konfiguration in `domain = "example.com";`
    - Setzen Sie `email` gleich, z.B. `email = "noreply-dmarc@example.com";`
 4. Es ist optional, aber empfohlen, einen E-Mail-Benutzer `noreply-dmarc` in mailcow zu erstellen, um Bounces zu behandeln.
 ## Aktivieren Sie DMARC-Berichterstattung
 Erstellen Sie die Datei `data/conf/rspamd/local.d/dmarc.conf` und setzen Sie den folgenden Inhalt:
 ```
 reporting {
    enabled = true;
    email = 'noreply-dmarc@example.com';
    domain = 'example.com';
    org_name = 'Example';
    helo = 'rspamd';
    smtp = 'postfix';
    smtp_port = 25;
    from_name = 'Example DMARC Report';
    msgid_from = 'rspamd.mail.example.com';
    max_entries = 2k;
    keys_expire = 2d;
 }
 ```
 Erstellen oder ändern Sie `docker-compose.override.yml` im mailcow-dockerized Basisverzeichnis:
 ```
 version: '2.1'
 services:
  rspamd-mailcow:
    environment:
      - MASTER=${MASTER:-y}
    Labels:
      ofelia.enabled: "true"
      ofelia.job-exec.rspamd_dmarc_reporting.schedule: "@every 24h"
      ofelia.job-exec.rspamd_dmarc_reporting.command: "/bin/bash -c \"[[ $${MASTER} == y ]] && /usr/bin/rspamadm dmarc_report > /var/lib/rspamd/dmarc_reports_last_log 2>&1 || exit 0\""
  ofelia-mailcow:
    depends_on:
      - rspamd-mailcow
 ```
 Starte `docker-compose up -d`
 ## Senden Sie eine Kopie der Berichte an sich selbst
 Um eine versteckte Kopie der von Rspamd erzeugten Berichte zu erhalten, können Sie eine `bcc_addrs` Liste im `reporting` Konfigurationsabschnitt von `data/conf/rspamd/local.d/dmarc.conf` setzen:
 ```
 reporting {
    enabled = true;
    email = 'noreply-dmarc@example.com';
    bcc_addrs = ["noreply-dmarc@example.com", "parsedmarc@example.com"];
 [...]
 ```
 Rspamd lädt Änderungen in Echtzeit, so dass Sie den Container zu diesem Zeitpunkt nicht neu starten müssen.
 Dies kann nützlich sein, wenn Sie...
 - ...überprüfen wollen, ob Ihre DMARC-Berichte korrekt und authentifiziert gesendet werden.
 - ...Ihre eigenen Berichte analysieren wollen, um Statistiken zu erhalten, z.B. um sie mit ParseDMARC oder anderen Analysesystemen zu verwenden.
 ## Fehlersuche
 Prüfen Sie, wann der Berichtsplan zuletzt ausgeführt wurde:
 ```
 docker-compose exec rspamd-mailcow date -r /var/lib/rspamd/dmarc_reports_last_log
 ```
 Sehen Sie sich die letzte Berichtsausgabe an:
 ```
 docker-compose exec rspamd-mailcow cat /var/lib/rspamd/dmarc_reports_last_log
 ```
 Manuelles Auslösen eines DMARC-Berichts:
 ```
 docker-compose exec rspamd-mailcow rspamadm dmarc_report
 ```
 Bestätigen Sie, dass Rspamd Daten in Redis aufgezeichnet hat:
 ```
 docker-compose exec redis-mailcow redis-cli KEYS 'dmarc;*'
 docker-compose exec redis-mailcow redis-cli HGETALL "dmarc;example.com;20211231"
 ```
 ## Ändern Sie die Häufigkeit der DMARC-Berichte
 Im obigen Beispiel werden die Berichte einmal alle 24 Stunden gesendet.
 Der Olefia-Zeitplan hat die gleiche Implementierung wie `cron` in Go, die unterstützte Syntax ist beschrieben in [cron Documentation](https://pkg.go.dev/github.com/robfig/cron)
 Um den Zeitplan zu ändern:
 1. Bearbeiten Sie `docker-compose.override.yml` und stellen Sie `ofelia.job-exec.rspamd_dmarc_reporting.schedule: "@every 24h"` auf einen gewünschten Wert, zum Beispiel auf `"@midnight"`
 2. Führen Sie `docker-compose up -d` aus.
 3. Führen Sie `docker-compose restart ofelia-mailcow` aus
 ## DMARC-Berichterstattung deaktivieren
 Zum Deaktivieren der Berichterstattung:
 1. Setzen Sie `enabled` auf `false` in `data/conf/rspamd/local.d/dmarc.conf`.
 2. Machen Sie Änderungen in `docker-compose.override.yml` an `rspamd-mailcow` und `ofelia-mailcow` rückgängig
 3. Führen Sie `docker-compose up -d` aus
--- a/docs/post_installation/firststeps-dmarc_reporting.en.md
+++ b/docs/post_installation/firststeps-dmarc_reporting.en.md
@ -0,0 +1,125 @@
 DMARC Reporting done via Rspamd DMARC Module.
 Rspamd documentation can be found here: https://rspamd.com/doc/modules/dmarc.html
 **Important:**
 1. Change `example.com`, `mail.example.com` and `Example` to reflect your setup
 2. DMARC reporting requires additional attention, especially over the first few days
 3. All receiving domains hosted on mailcow send from one reporting domain. It is recommended to use the parent domain of your `MAILCOW_HOSTNAME`:
    - If your `MAILCOW_HOSTNAME` is `mail.example.com` change the following config to `domain = "example.com";`
    - Set `email` equally, e.g. `email = "noreply-dmarc@example.com";`
 4. It is optional but recommended to create an email user `noreply-dmarc` in mailcow to handle bounces.
 ## Enable DMARC reporting
 Create the file `data/conf/rspamd/local.d/dmarc.conf` and set the following content:
 ```
 reporting {
    enabled = true;
    email = 'noreply-dmarc@example.com';
    domain = 'example.com';
    org_name = 'Example';
    helo = 'rspamd';
    smtp = 'postfix';
    smtp_port = 25;
    from_name = 'Example DMARC Report';
    msgid_from = 'rspamd.mail.example.com';
    max_entries = 2k;
    keys_expire = 2d;
 }
 ```
 Create or modify `docker-compose.override.yml` in the mailcow-dockerized base directory:
 ```
 version: '2.1'
 services:
  rspamd-mailcow:
    environment:
      - MASTER=${MASTER:-y}
    labels:
      ofelia.enabled: "true"
      ofelia.job-exec.rspamd_dmarc_reporting.schedule: "@every 24h"
      ofelia.job-exec.rspamd_dmarc_reporting.command: "/bin/bash -c \"[[ $${MASTER} == y ]] && /usr/bin/rspamadm dmarc_report > /var/lib/rspamd/dmarc_reports_last_log 2>&1 || exit 0\""
  ofelia-mailcow:
    depends_on:
      - rspamd-mailcow
 ```
 Run `docker-compose up -d`
 ## Send a copy reports to yourself
 To receive a hidden copy of reports generated by Rspamd you can set a `bcc_addrs` list in the `reporting` config section of `data/conf/rspamd/local.d/dmarc.conf`:
 ```
 reporting {
    enabled = true;
    email = 'noreply-dmarc@example.com';
    bcc_addrs = ["noreply-dmarc@example.com","parsedmarc@example.com"];
 [...]
 ```
 Rspamd will load changes in real time, so you won't need to restart the container at this point.
 This can be useful if you...
 - ...want to check that your DMARC reports are sent correctly and authenticated.
 - ...want to analyze your own reports to get statistics, i.e. to use with ParseDMARC or other analytic systems.
 ## Troubleshooting
 Check when the report schedule last ran:
 ```
 docker-compose exec rspamd-mailcow date -r /var/lib/rspamd/dmarc_reports_last_log
 ```
 See the latest report output:
 ```
 docker-compose exec rspamd-mailcow cat /var/lib/rspamd/dmarc_reports_last_log
 ```
 Manually trigger a DMARC report:
 ```
 docker-compose exec rspamd-mailcow rspamadm dmarc_report
 ```
 Validate that Rspamd has recorded data in Redis:
 ```
 docker-compose exec redis-mailcow redis-cli KEYS 'dmarc;*'
 docker-compose exec redis-mailcow redis-cli HGETALL "dmarc;example.com;20211231"
 ```
 ## Change DMARC reporting frequency
 In the example above reports are sent once every 24 hours.
 Olefia schedule has same implementation as `cron` in Go, supported syntax described at [cron Documentation](https://pkg.go.dev/github.com/robfig/cron)
 To change schedule:
 1. Edit `docker-compose.override.yml` and a djust `ofelia.job-exec.rspamd_dmarc_reporting.schedule: "@every 24h"` to a desired value, for example to `"@midnight"`
 2. Run `docker-compose up -d`
 3. Run `docker-compose restart ofelia-mailcow`
 ## Disable DMARC Reporting
 To disable reporting:
 1. Set `enabled` to `false` in `data/conf/rspamd/local.d/dmarc.conf`
 2. Revert changes done in `docker-compose.override.yml` to `rspamd-mailcow` and `ofelia-mailcow`
 3. Run `docker-compose up -d`
--- a/docs/post_installation/firststeps-firststeps-local_mta.de.md
+++ b/docs/post_installation/firststeps-firststeps-local_mta.de.md
@ -0,0 +1,23 @@
 Die einfachste Möglichkeit wäre, den Listener an Port 25/tcp zu deaktivieren.
 **Postfix**-Benutzer deaktivieren den Listener, indem sie die folgende Zeile (beginnend mit `smtp` oder `25`) in `/etc/postfix/master.cf` auskommentieren:
 ```
 #smtp      inet  n       -       -       -       -       smtpd
 ```
 Außerdem, um über eine Dockerized mailcow weiterzuleiten, sollten Sie `172.22.1.1` als Relayhost hinzufügen und das Docker-Interface aus "inet_interfaces" entfernen:
 ```
 postconf -e 'relayhost = 172.22.1.1'
 postconf -e "mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128"
 postconf -e "inet_interfaces = loopback-only"
 postconf -e "relay_transport = relay"
 postconf -e "default_transport = smtp"
 ```
 **Jetzt ist es wichtig**, dass Sie nicht denselben FQDN in `myhostname` haben, den Sie für Ihre mailcow verwenden. Prüfen Sie Ihre lokale (nicht-Docker) Postfix' main.cf auf `myhostname` und setzen Sie ihn auf etwas anderes, zum Beispiel `local.my.fqdn.tld`.
 "172.22.1.1" ist das von mailcow erstellte Netzwerk-Gateway in Docker.
 Das Relaying über diese Schnittstelle ist notwendig (anstatt - zum Beispiel - direkt über ${MAILCOW_HOSTNAME}), um über ein bekanntes internes Netzwerk weiterzuleiten.
 Starten Sie Postfix neu, nachdem Sie Ihre Änderungen vorgenommen haben.
--- a/docs/post_installation/firststeps-firststeps-local_mta.en.md
+++ b/docs/post_installation/firststeps-firststeps-local_mta.en.md
@ -0,0 +1,23 @@
 The easiest option would be to disable the listener on port 25/tcp.
 **Postfix** users disable the listener by commenting the following line (starting with `smtp` or `25`) in `/etc/postfix/master.cf`:
 ```
 #smtp      inet  n       -       -       -       -       smtpd
 ```
 Furthermore, to relay over a dockerized mailcow, you may want to add `172.22.1.1` as relayhost and remove the Docker interface from "inet_interfaces":
 ```
 postconf -e 'relayhost = 172.22.1.1'
 postconf -e "mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128"
 postconf -e "inet_interfaces = loopback-only"
 postconf -e "relay_transport = relay"
 postconf -e "default_transport = smtp"
 ```
 **Now it is important** to not have the same FQDN in `myhostname` as you use for your dockerized mailcow. Check your local (non-Docker) Postfix' main.cf for `myhostname` and set it to something different, for example `local.my.fqdn.tld`.
 "172.22.1.1" is the mailcow created network gateway in Docker.
 Relaying over this interface is necessary (instead of - for example - relaying directly over ${MAILCOW_HOSTNAME}) to relay over a known internal network.
 Restart Postfix after applying your changes.
--- a/docs/post_installation/firststeps-ip_bindings.de.md
+++ b/docs/post_installation/firststeps-ip_bindings.de.md
@ -0,0 +1,72 @@
 !!! warning
    Das Ändern der Bindung hat keinen Einfluss auf Source-NAT. Siehe [SNAT](https://mailcow.github.io/mailcow-dockerized-docs/de/post_installation/firststeps-snat) für die erforderlichen Schritte.
 ## IPv4-Binding
 Um eine oder mehrere IPv4-Bind(ings) anzupassen, öffne `mailcow.conf` und editiere eine, mehrere oder alle Variablen nach deinen Bedürfnissen:
 ```
 # Aus technischen Gründen unterscheiden sich die http-Bindungen ein wenig von anderen Service-Bindungen.
 # Sie werden die folgenden Variablen finden, getrennt durch eine Bindungsadresse und deren Port:
 # Beispiel: HTTP_BIND=1.2.3.4
 HTTP_PORT=80
 HTTP_BIND=
 HTTPS_PORT=443
 HTTPS_BIND=
 # Andere Dienste werden nach folgendem Format gebunden:
 # SMTP_PORT=1.2.3.4:25 bindet SMTP an die IP 1.2.3.4 auf Port 25
 # Wichtig! Durch die Angabe einer IPv4-Adresse werden alle IPv6-Bindungen seit Docker 20.x übersprungen.
 # doveadm, SQL sowie Solr sind nur an lokale Ports gebunden, bitte ändern Sie das nicht, es sei denn, Sie wissen, was Sie tun.
 SMTP_PORT=25
 SMTPS_PORT=465
 SUBMISSION_PORT=587
 IMAP_PORT=143
 IMAPS_PORT=993
 POP_PORT=110
 POPS_PORT=995
 SIEVE_PORT=4190
 DOVEADM_PORT=127.0.0.1:19991
 SQL_PORT=127.0.0.1:13306
 SOLR_PORT=127.0.0.1:18983
 ```
 Um Ihre Änderungen zu übernehmen, führen Sie `docker-compose down` gefolgt von `docker-compose up -d` aus.
 ## IPv6-Binding
 Das Ändern von IPv6-Bindings ist anders als bei IPv4. Auch dies hat einen technischen Hintergrund.
 Eine `docker-compose.override.yml` Datei wird verwendet, anstatt die `docker-compose.yml` Datei direkt zu bearbeiten. Dies geschieht, um die Aktualisierbarkeit zu erhalten, da die Datei `docker-compose.yml` regelmäßig aktualisiert wird und Ihre Änderungen höchstwahrscheinlich überschrieben werden.
 Bearbeiten Sie die Datei "docker-compose.override.yml" und erstellen Sie sie mit dem folgenden Inhalt. Ihr Inhalt wird mit der produktiven Datei "docker-compose.yml" zusammengeführt.
 Es wird eine imaginäre IPv6 **2a00:dead:beef::abc** angegeben. Das erste Suffix `:PORT1` definiert den externen Port, während das zweite Suffix `:PORT2` zu dem entsprechenden Port innerhalb des Containers führt und nicht verändert werden darf.
 ```
 version: '2.1'
 services:
    dovecot-mailcow:
      ports:
        - '2a00:dead:beef::abc:143:143'
        - '2a00:dead:beef::abc:993:993'
        - '2a00:dead:beef::abc:110:110'
        - '2a00:dead:beef::abc:995:995'
        - '2a00:dead:beef::abc:4190:4190'
    postfix-mailcow:
      ports:
        - '2a00:dead:beef::abc:25:25'
        - '2a00:dead:beef::abc:465:465'
        - '2a00:dead:beef::abc:587:587'
    nginx-mailcow:
      ports:
        - '2a00:dead:beef::abc:80:80'
        - '2a00:dead:beef::abc:443:443'
 ```
 Um Ihre Änderungen zu übernehmen, führen Sie `docker-compose down` gefolgt von `docker-compose up -d` aus.
--- a/docs/post_installation/firststeps-ip_bindings.en.md
+++ b/docs/post_installation/firststeps-ip_bindings.en.md
@ -0,0 +1,72 @@
 !!! warning
    Changing the binding does not affect source NAT. See [SNAT](https://mailcow.github.io/mailcow-dockerized-docs/en/post_installation/firststeps-snat) for required steps.
 ## IPv4 binding
 To adjust one or multiple IPv4 bindings, open `mailcow.conf` and edit one, multiple or all variables as per your needs:
 ```
 # For technical reasons, http bindings are a bit different from other service bindings.
 # You will find the following variables, separated by a bind address and its port:
 # Example: HTTP_BIND=1.2.3.4
 HTTP_PORT=80
 HTTP_BIND=
 HTTPS_PORT=443
 HTTPS_BIND=
 # Other services are bound by using the following format:
 # SMTP_PORT=1.2.3.4:25 will bind SMTP to the IP 1.2.3.4 on port 25
 # Important! Specifying an IPv4 address will skip all IPv6 bindings since Docker 20.x.
 # doveadm, SQL as well as Solr are bound to local ports only, please do not change that, unless you know what you are doing.
 SMTP_PORT=25
 SMTPS_PORT=465
 SUBMISSION_PORT=587
 IMAP_PORT=143
 IMAPS_PORT=993
 POP_PORT=110
 POPS_PORT=995
 SIEVE_PORT=4190
 DOVEADM_PORT=127.0.0.1:19991
 SQL_PORT=127.0.0.1:13306
 SOLR_PORT=127.0.0.1:18983
 ```
 To apply your changes, run `docker-compose down` followed by `docker-compose up -d`.
 ## IPv6 binding
 Changing IPv6 bindings is different from IPv4. Again, this has a technical background.
 A `docker-compose.override.yml` file will be used instead of editing the `docker-compose.yml` file directly. This is to maintain updatability, as the `docker-compose.yml` file gets updated regularly and your changes will most likely be overwritten.
 Edit to create a file  `docker-compose.override.yml` with the following content. Its content will be merged with the productive `docker-compose.yml` file.
 An imaginary IPv6 **2a00:dead:beef::abc** is given. The first suffix `:PORT1` defines the external port, while the second suffix `:PORT2` routes to the corresponding port inside the container and must not be changed.
 ```
 version: '2.1'
 services:
    dovecot-mailcow:
      ports:
        - '2a00:dead:beef::abc:143:143'
        - '2a00:dead:beef::abc:993:993'
        - '2a00:dead:beef::abc:110:110'
        - '2a00:dead:beef::abc:995:995'
        - '2a00:dead:beef::abc:4190:4190'
    postfix-mailcow:
      ports:
        - '2a00:dead:beef::abc:25:25'
        - '2a00:dead:beef::abc:465:465'
        - '2a00:dead:beef::abc:587:587'
    nginx-mailcow:
      ports:
        - '2a00:dead:beef::abc:80:80'
        - '2a00:dead:beef::abc:443:443'
 ```
 To apply your changes, run `docker-compose down` followed by `docker-compose up -d`.
--- a/docs/post_installation/firststeps-logging.de.md
+++ b/docs/post_installation/firststeps-logging.de.md
@ -0,0 +1,110 @@
 Das Logging in mailcow: dockerized besteht aus mehreren Stufen, ist aber immerhin wesentlich flexibler und einfacher in einen Logging-Daemon zu integrieren als bisher.
 In Docker schreibt die containerisierte Anwendung (PID 1) ihre Ausgabe auf stdout. Für echte Ein-Anwendungs-Container funktioniert das sehr gut.
 Führen Sie `docker-compose logs --help` aus, um mehr zu erfahren. 
 Einige Container protokollieren oder streamen an mehrere Ziele.
 Kein Container wird persistente Logs in sich behalten. Container sind flüchtige Objekte!
 Am Ende wird jede Zeile der Logs den Docker-Daemon erreichen - ungefiltert.
 Der **Standard-Logging-Treiber ist "json "**.
 ### Gefilterte Logs
 Einige Logs werden gefiltert und in Redis-Schlüssel geschrieben, aber auch in einen Redis-Kanal gestreamt.
 Der Redis-Kanal wird verwendet, um Protokolle mit fehlgeschlagenen Authentifizierungsversuchen zu streamen, die von netfilter-mailcow gelesen werden.
 Die Redis-Schlüssel sind persistent und halten 10000 Zeilen von Logs für die Web-UI.
 Dieser Mechanismus macht es möglich, jeden beliebigen Docker-Logging-Treiber zu verwenden, ohne die 
 ohne die Fähigkeit zu verlieren, Logs von der UI zu lesen oder verdächtige Clients mit netfilter-mailcow zu sperren.
 Redis-Schlüssel enthalten nur Logs von Anwendungen und filtern Systemmeldungen heraus (man denke an Cron etc.).
 ### Logging-Treiber
 #### Über docker-compose.override.yml
 Hier ist die gute Nachricht: Da Docker einige großartige Logging-Treiber hat, können Sie mailcow: dockerized mit Leichtigkeit in Ihre bestehende Logging-Umgebung integrieren.
 Erstellen Sie eine `docker-compose.override.yml` und fügen Sie zum Beispiel diesen Block hinzu, um das "gelf" Logging-Plugin für `postfix-mailcow` zu verwenden:
 ```
 version: '2.1'
 services:
  postfix-mailcow: # oder ein anderer
    logging:
      driver: "gelf"
      options:
        gelf-address: "udp://graylog:12201"
 ```
 Ein weiteres Beispiel für **Syslog**:
 ```
 version: '2.1'
 services:
  postfix-mailcow: # oder ein anderer
    logging:
      driver: "syslog"
      options:
        syslog-address: "udp://127.0.0.1:514"
        syslog-facility: "local3"
  dovecot-mailcow: # oder ein anderer
    logging:
      driver: "syslog"
      options:
        syslog-address: "udp://127.0.0.1:514"
        syslog-facility: "local3"
  rspamd-mailcow: # oder ein anderer
    logging:
      driver: "syslog"
      options:
        syslog-address: "udp://127.0.0.1:514"
        syslog-facility: "local3"
 # Nur für Rsyslog:
 # Um die local3-Eingabe nach /var/log/mailcow.log zu verschieben und die Verarbeitung zu beenden, erstellen Sie eine Datei "/etc/rsyslog.d/docker.conf":
 local3.* /var/log/mailcow.logs
 & ~
 # Danach rsyslog neu starten.
 ```
 #### Über daemon.json (global)
 Wenn Sie den Logging-Treiber **global** ändern wollen, editieren Sie die Konfigurationsdatei des Docker-Daemons `/etc/docker/daemon.json` und starten Sie den Docker-Dienst neu:
 ```
 {
 ...
  "log-driver": "gelf",
  "log-opts": {
    "gelf-address": "udp://graylog:12201"
  }
 ...
 }
 ```
 Für Syslog:
 ```
 {
 ...
  "log-driver": "syslog",
  "log-opts": {
    "syslog-address": "udp://1.2.3.4:514"
  }
 ...
 }
 ```
 Starten Sie den Docker-Daemon neu und führen Sie `docker-compose down && docker-compose up -d` aus, um die Container mit dem neuen Protokollierungstreiber neu zu erstellen.
--- a/docs/post_installation/firststeps-logging.en.md
+++ b/docs/post_installation/firststeps-logging.en.md
@ -0,0 +1,110 @@
 Logging in mailcow: dockerized consists of multiple stages, but is, after all, much more flexible and easier to integrate into a logging daemon than before.
 In Docker the containerized application (PID 1) writes its output to stdout. For real one-application containers this works just fine.
 Run `docker-compose logs --help` to learn more. 
 Some containers log or stream to multiple destinations.
 No container will keep persistent logs in it. Containers are transient items!
 In the end, every line of logs will reach the Docker daemon - unfiltered.
 The **default logging driver is "json"**.
 ### Filtered logs
 Some logs are filtered and written to Redis keys but also streamed to a Redis channel.
 The Redis channel is used to stream logs with failed authentication attempts to be read by netfilter-mailcow.
 The Redis keys are persistent and will keep 10000 lines of logs for the web UI.
 This mechanism makes it possible to use whatever Docker logging driver you want to, without losing 
 the ability to read logs from the UI or ban suspicious clients with netfilter-mailcow.
 Redis keys will only hold logs from applications and filter out system messages (think of cron etc.).
 ### Logging drivers
 #### Via docker-compose.override.yml
 Here is the good news: Since Docker has some great logging drivers, you can integrate mailcow: dockerized into your existing logging environment with ease.
 Create a `docker-compose.override.yml` and add, for example, this block to use the "gelf" logging plugin for `postfix-mailcow`:
 ```
 version: '2.1'
 services:
  postfix-mailcow: # or any other
    logging:
      driver: "gelf"
      options:
        gelf-address: "udp://graylog:12201"
 ```
 Another example for **Syslog**:
 ```
 version: '2.1'
 services:
  postfix-mailcow: # or any other
    logging:
      driver: "syslog"
      options:
        syslog-address: "udp://127.0.0.1:514"
        syslog-facility: "local3"
  dovecot-mailcow: # or any other
    logging:
      driver: "syslog"
      options:
        syslog-address: "udp://127.0.0.1:514"
        syslog-facility: "local3"
  rspamd-mailcow: # or any other
    logging:
      driver: "syslog"
      options:
        syslog-address: "udp://127.0.0.1:514"
        syslog-facility: "local3"
 # For Rsyslog only:
 # To move local3 input to /var/log/mailcow.log and stop processing, create a file "/etc/rsyslog.d/docker.conf":
 local3.*        /var/log/mailcow.logs
 & ~
 # Restart rsyslog afterwards.
 ```
 #### via daemon.json (globally)
 If you want to **change the logging driver globally**, edit Dockers daemon configuration file `/etc/docker/daemon.json` and restart the Docker service:
 ```
 {
 ...
  "log-driver": "gelf",
  "log-opts": {
    "gelf-address": "udp://graylog:12201"
  }
 ...
 }
 ```
 For Syslog:
 ```
 {
 ...
  "log-driver": "syslog",
  "log-opts": {
    "syslog-address": "udp://1.2.3.4:514"
  }
 ...
 }
 ```
 Restart the Docker daemon and run `docker-compose down && docker-compose up -d` to recreate the containers with the new logging driver.
--- a/docs/post_installation/firststeps-rp.de.md
+++ b/docs/post_installation/firststeps-rp.de.md
@ -0,0 +1,303 @@
 Sie müssen die Nginx-Seite, die mit mailcow: dockerized geliefert wird, nicht ändern.
 mailcow: dockerized vertraut auf das Standard-Gateway IP 172.22.1.1 als Proxy.
 1\. Stellen Sie sicher, dass Sie HTTP_BIND und HTTPS_BIND in `mailcow.conf` auf eine lokale Adresse ändern und die Ports entsprechend einstellen, zum Beispiel:
 `` bash
 HTTP_BIND=127.0.0.1
 HTTP_PORT=8080
 HTTPS_BIND=127.0.0.1
 HTTPS_PORT=8443
 ```
 Dadurch werden auch die Bindungen innerhalb des Nginx-Containers geändert! Dies ist wichtig, wenn Sie sich entscheiden, einen Proxy innerhalb von Docker zu verwenden.
 **WICHTIG:** Verwenden Sie nicht Port 8081, 9081 oder 65510!
 Erzeugen Sie die betroffenen Container neu, indem Sie `docker-compose up -d` ausführen.
 **Wichtige Informationen, bitte lesen Sie diese sorgfältig durch!**
 !!! info
    Wenn Sie planen, einen Reverse-Proxy zu verwenden und einen anderen Servernamen als **MAILCOW_HOSTNAME** verwenden wollen, müssen Sie **Zusätzliche Servernamen für mailcow UI** am Ende dieser Seite hinzufügen.
 !!! warning
    Stellen Sie sicher, dass Sie `generate_config.sh` ausführen, bevor Sie die untenstehenden Konfigurationsbeispiele aktivieren.
    Das Skript `generate_config.sh` kopiert die Snake-oil Zertifikate an den richtigen Ort, so dass die Dienste nicht aufgrund fehlender Dateien nicht starten können.
 !!! warning
    Wenn du TLS SNI aktivierst (`ENABLE_TLS_SNI` in mailcow.conf), **müssen** die Zertifikatspfade in deinem Reverse-Proxy mit den korrekten Pfaden in data/assets/ssl/{hostname} übereinstimmen. Die Zertifikate werden in `data/assets/ssl/{hostname1,hostname2,etc}` aufgeteilt und werden daher nicht funktionieren, wenn Sie die Beispiele von unten kopieren, die auf `data/assets/ssl/cert.pem` etc. zeigen.
 !!! info
    Die Verwendung der untenstehenden Site-Konfigurationen wird **acme-Anfragen an mailcow** weiterleiten und es die Zertifikate selbst verwalten lassen.
    Der Nachteil der Verwendung von mailcow als ACME-Client hinter einem Reverse-Proxy ist, dass Sie Ihren Webserver neu laden müssen, nachdem acme-mailcow das Zertifikat geändert/erneuert/erstellt hat. Sie können entweder Ihren Webserver täglich neu laden oder ein Skript schreiben, um die Datei auf Änderungen zu überwachen.
    Auf vielen Servern wird logrotate den Webserver sowieso täglich neu laden.
    Wenn Sie eine lokale Certbot-Installation verwenden möchten, müssen Sie die SSL-Zertifikatsparameter entsprechend ändern.
    **Stellen Sie sicher, dass Sie ein Post-Hook-Skript** ausführen, wenn Sie sich entscheiden, externe ACME-Clients zu verwenden. Ein Beispiel finden Sie am Ende dieser Seite.
 2\. Konfigurieren Sie Ihren lokalen Webserver als Reverse Proxy:
 ### Apache 2.4
 Erforderliche Module:
 ```
 a2enmod rewrite proxy proxy_http headers ssl
 ```
 Let's Encrypt wird unserem Rewrite folgen, Zertifikatsanfragen in mailcow werden problemlos funktionieren.
 **Die hervorgehobenen Zeilen müssen beachtet werden**.
 ``` apache hl_lines="2 10 11 17 22 23 24 25 30 31"
 <VirtualHost *:80>
  ServerName ZU MAILCOW HOSTNAMEN ÄNDERN
  ServerAlias autodiscover.*
  ServerAlias autoconfig.*
  RewriteEngine on
  RewriteCond %{HTTPS} off
  RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R=301,L]
  ProxyPass / http://127.0.0.1:8080/
  ProxyPassReverse / http://127.0.0.1:8080/
  ProxyPreserveHost On
  ProxyAddHeaders On
  RequestHeader set X-Forwarded-Proto "http"
 </VirtualHost>
 <VirtualHost *:443>
  ServerName ZU MAILCOW HOSTNAMEN ÄNDERN
  ServerAlias autodiscover.*
  ServerAlias autoconfig.*
  # You should proxy to a plain HTTP session to offload SSL processing
  ProxyPass /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync connectiontimeout=4000
  ProxyPassReverse /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync
  ProxyPass / http://127.0.0.1:8080/
  ProxyPassReverse / http://127.0.0.1:8080/
  ProxyPreserveHost On
  ProxyAddHeaders On
  RequestHeader set X-Forwarded-Proto "https"
  SSLCertificateFile MAILCOW_ORDNER/data/assets/ssl/cert.pem
  SSLCertificateKeyFile MAILCOW_ORDNER/data/assets/ssl/key.pem
  # Wenn Sie einen HTTPS-Host als Proxy verwenden möchten:
  #SSLProxyEngine On
  # Wenn Sie einen Proxy für einen nicht vertrauenswürdigen HTTPS-Host einrichten wollen:
  #SSLProxyVerify none
  #SSLProxyCheckPeerCN off
  #SSLProxyCheckPeerName off
  #SSLProxyCheckPeerExpire off
 </VirtualHost>
 ```
 ### Nginx
 Let's Encrypt folgt unserem Rewrite, Zertifikatsanfragen funktionieren problemlos.
 **Kümmern Sie sich um die hervorgehobenen Zeilen**.
 ``` hl_lines="4 10 12 13 25 39"
 server {
  listen 80 default_server;
  listen [::]:80 default_server;
  server_name ZU MAILCOW HOSTNAMEN ÄNDERN autodiscover.* autoconfig.*;
  return 301 https://$host$request_uri;
 }
 server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name ZU MAILCOW HOSTNAMEN ÄNDERN autodiscover.* autoconfig.*;
  ssl_certificate MAILCOW_PATH/data/assets/ssl/cert.pem;
  ssl_certificate_key MAILCOW_PATH/data/assets/ssl/key.pem;
  ssl_session_timeout 1d;
  ssl_session_cache shared:SSL:50m;
  ssl_session_tickets off;
  # Siehe https://ssl-config.mozilla.org/#server=nginx für die neuesten Empfehlungen zu ssl-Einstellungen
  # Ein Beispiel für eine Konfiguration ist unten angegeben
  ssl_protocols TLSv1.2;
  ssl_ciphers HIGH:!aNULL:!MD5:!SHA1:!kRSA;
  ssl_prefer_server_ciphers off;
  location /Microsoft-Server-ActiveSync {
    proxy_pass http://127.0.0.1:8080/Microsoft-Server-ActiveSync;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_connect_timeout 75;
    proxy_send_timeout 3650;
    proxy_read_timeout 3650;
    proxy_buffers 64 256k;
    client_body_buffer_size 512k;
    client_max_body_size 0;
  }
  location / {
    proxy_pass http://127.0.0.1:8080/;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    client_max_body_size 0;
  }
 }
 ```
 ### HAProxy (von der Community unterstützt)
 !!! warning
    Dies ist ein nicht unterstützter Community Beitrag. Sie können gerne Korrekturen bereitstellen.
 **Wichtig/Fix erwünscht**: Dieses Beispiel leitet nur HTTPS-Verkehr weiter und benutzt nicht den in mailcow eingebauten ACME-Client.
 ```
 frontend https-in
  bind :::443 v4v6 ssl crt mailcow.pem
  default_backend mailcow
 backend mailcow
  option forwardfor
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
  server mailcow 127.0.0.1:8080 check
 ```
 ### Traefik v2 (von der Community unterstützt)
 !!! warning
    Dies ist ein nicht unterstützter Community Beitrag. Fühlen Sie sich frei, Korrekturen bereitzustellen.
 **Wichtig**: Diese Konfiguration deckt nur das "Reverseproxing" des Webpanels (nginx-mailcow) unter Verwendung von Traefik v2 ab. Wenn Sie auch die Mail-Dienste wie dovecot, postfix... reproxen wollen, müssen Sie die folgende Konfiguration an jeden Container anpassen und einen [EntryPoint](https://docs.traefik.io/routing/entrypoints/) in Ihrer `traefik.toml` oder `traefik.yml` (je nachdem, welche Konfiguration Sie verwenden) für jeden Port erstellen. 
 In diesem Abschnitt gehen wir davon aus, dass Sie Ihren Traefik 2 `[certificatesresolvers]` in Ihrer Traefik-Konfigurationsdatei richtig konfiguriert haben und auch acme verwenden. Das folgende Beispiel verwendet Lets Encrypt, aber Sie können es gerne auf Ihren eigenen Zertifikatsresolver ändern. Eine grundlegende Traefik 2 toml-Konfigurationsdatei mit allen oben genannten Elementen, die für dieses Beispiel verwendet werden kann, finden Sie hier [traefik.toml](https://github.com/Frenzoid/TraefikBasicConfig/blob/master/traefik.toml), falls Sie eine solche Datei benötigen oder einen Hinweis, wie Sie Ihre Konfiguration anpassen können.
 Zuallererst werden wir den acme-mailcow-Container deaktivieren, da wir die von traefik bereitgestellten Zertifikate verwenden werden.
 Dazu müssen wir `SKIP_LETS_ENCRYPT=y` in unserer `mailcow.conf` setzen und `docker-compose up -d` ausführen, um die Änderungen zu übernehmen.
 Dann erstellen wir eine `docker-compose.override.yml` Datei, um die Hauptdatei `docker-compose.yml` zu überschreiben, die sich im Mailcow-Stammverzeichnis befindet. 
 ```yaml
 version: '2.1'
 services:
    nginx-mailcow:
      networks:
        # add Traefik's network
        web:
      labels:
        - traefik.enable=true
        # Creates a router called "moo" for the container, and sets up a rule to link the container to certain rule,
        #   in this case, a Host rule with our MAILCOW_HOSTNAME var.
        - traefik.http.routers.moo.rule=Host(`${MAILCOW_HOSTNAME}`)
        # Enables tls over the router we created before.
        - traefik.http.routers.moo.tls=true
        # Specifies which kind of cert resolver we'll use, in this case le (Lets Encrypt).
        - traefik.http.routers.moo.tls.certresolver=le
        # Creates a service called "moo" for the container, and specifies which internal port of the container
        #   should traefik route the incoming data to.
        - traefik.http.services.moo.loadbalancer.server.port=${HTTP_PORT}
        # Specifies which entrypoint (external port) should traefik listen to, for this container.
        #   websecure being port 443, check the traefik.toml file liked above.
        - traefik.http.routers.moo.entrypoints=websecure
        # Make sure traefik uses the web network, not the mailcowdockerized_mailcow-network
        - traefik.docker.network=web
    certdumper:
        image: humenius/traefik-certs-dumper
        container_name: traefik_certdumper
        network_mode: none
        volumes:
          # mount the folder which contains Traefik's `acme.json' file
          #   in this case Traefik is started from its own docker-compose in ../traefik
          - ../traefik/data:/traefik:ro
          # mount mailcow's SSL folder
          - ./data/assets/ssl/:/output:rw
        environment:
          # only change this, if you're using another domain for mailcow's web frontend compared to the standard config
          - DOMAIN=${MAILCOW_HOSTNAME}
 networks:
  web:
    external: true
 Version: '2.1'
 Dienste:
    nginx-mailcow:
      Netzwerke:
        # Traefiks Netzwerk hinzufügen
        web:
      labels:
        - traefik.enable=true
        # Erstellt einen Router namens "moo" für den Container und richtet eine Regel ein, um den Container mit einer bestimmten Regel zu verknüpfen,
        # in diesem Fall eine Host-Regel mit unserer MAILCOW_HOSTNAME-Variable.
        - traefik.http.routers.moo.rule=Host(`${MAILCOW_HOSTNAME}`)
        # Aktiviert tls über den zuvor erstellten Router.
        - traefik.http.routers.moo.tls=true
        # Gibt an, welche Art von Cert-Resolver wir verwenden werden, in diesem Fall le (Lets Encrypt).
        - traefik.http.routers.moo.tls.certresolver=le
        # Erzeugt einen Dienst namens "moo" für den Container und gibt an, welchen internen Port des Containers
        # Traefik die eingehenden Daten weiterleiten soll.
        - traefik.http.services.moo.loadbalancer.server.port=${HTTP_PORT}
        # Gibt an, welchen Eingangspunkt (externer Port) traefik für diesen Container abhören soll.
        # Websecure ist Port 443, siehe die Datei traefik.toml wie oben.
        - traefik.http.routers.moo.entrypoints=websecure
        # Stellen Sie sicher, dass traefik das Web-Netzwerk verwendet, nicht das mailcowdockerized_mailcow-network
        - traefik.docker.network=web
    certdumper:
        image: humenius/traefik-certs-dumper
        container_name: traefik_certdumper
        network_mode: keine
        volumes:
          # mounten Sie den Ordner, der Traefiks `acme.json' Datei enthält
          # in diesem Fall wird Traefik von seinem eigenen docker-compose in ../traefik gestartet
          - ../traefik/data:/traefik:ro
          # SSL-Ordner von mailcow einhängen
          - ./data/assets/ssl/:/output:rw
        Umgebung:
          # Ändern Sie dies nur, wenn Sie eine andere Domain für Mailcows Web-Frontend verwenden als in der Standard-Konfiguration
          - DOMAIN=${MAILCOW_HOSTNAME}
 Netzwerke:
  web:
    extern: true
 ```
 Starten Sie die neuen Container mit `docker-compose up -d`.
 Da Traefik 2 ein acme v2 Format verwendet, um ALLE Lizenzen von allen Domains zu speichern, müssen wir einen Weg finden, die Zertifikate auszulagern. Zum Glück haben wir [diesen kleinen Container] (https://hub.docker.com/r/humenius/traefik-certs-dumper), der die Datei `acme.json` über ein Volume und eine Variable `DOMAIN=example. org`, und damit wird der Container die `cert.pem` und `key.pem` Dateien ausgeben, dafür lassen wir einfach den `traefik-certs-dumper` Container laufen, binden das `/traefik` Volume an den Ordner, in dem unsere `acme.json` gespeichert ist, binden das `/output` Volume an unseren mailcow `data/assets/ssl/` Ordner, und setzen die `DOMAIN=example.org` Variable auf die Domain, von der wir die Zertifikate ausgeben wollen. 
 Dieser Container überwacht die Datei `acme.json` auf Änderungen und generiert die Dateien `cert.pem` und `key.pem` direkt in `data/assets/ssl/`, wobei der Pfad mit dem `/output`-Pfad des Containers verbunden ist.
 Sie können es über die Kommandozeile ausführen oder das [hier] gezeigte docker-compose verwenden (https://hub.docker.com/r/humenius/traefik-certs-dumper).
 Nachdem wir die Zertifikate übertragen haben, müssen wir die Konfigurationen aus unseren Postfix- und Dovecot-Containern neu laden und die Zertifikate überprüfen. Wie das geht, sehen Sie [hier](https://mailcow.github.io/mailcow-dockerized-docs/de/post_installation/firststeps-ssl/#wie-sie-ihr-eigenes-zertifikat-verwenden).
 Und das sollte es gewesen sein 😊, Sie können überprüfen, ob der Traefik-Router einwandfrei funktioniert, indem Sie das Dashboard von Traefik / traefik logs / über https auf die eingestellte Domain zugreifen, oder / und HTTPS, SMTP und IMAP mit den Befehlen auf der zuvor verlinkten Seite überprüfen.
 ### Optional: Post-Hook-Skript für nicht-mailcow ACME-Clients
 Die Verwendung eines lokalen Certbots (oder eines anderen ACME-Clients) erfordert den Neustart einiger Container, was Sie mit einem Post-Hook-Skript erledigen können.
 Stellen Sie sicher, dass Sie die Pfade entsprechend ändern:
 ```
 #!/bin/bash
 cp /etc/letsencrypt/live/my.domain.tld/fullchain.pem /opt/mailcow-dockerized/data/assets/ssl/cert.pem
 cp /etc/letsencrypt/live/my.domain.tld/privkey.pem /opt/mailcow-dockerized/data/assets/ssl/key.pem
 postfix_c=$(docker ps -qaf name=postfix-mailcow)
 dovecot_c=$(docker ps -qaf name=dovecot-mailcow)
 nginx_c=$(docker ps -qaf name=nginx-mailcow)
 docker restart ${postfix_c} ${dovecot_c} ${nginx_c}
 ```
 ### Hinzufügen weiterer Servernamen für mailcow UI
 Wenn Sie vorhaben, einen Servernamen zu verwenden, der nicht `MAILCOW_HOSTNAME` in Ihrem Reverse-Proxy ist, stellen Sie sicher, dass Sie diesen Namen zuerst in mailcow.conf über `ADDITIONAL_SERVER_NAMES` einpflegen. Die Namen müssen durch Kommas getrennt werden und **dürfen** keine Leerzeichen enthalten. Wenn Sie diesen Schritt überspringen, kann es sein, dass mailcow auf Ihren Reverse-Proxy mit einer falschen Seite antwortet.
 ```
 ADDITIONAL_SERVER_NAMES=webmail.domain.tld,other.example.tld
 ```
 Führen Sie `docker-compose up -d` zum Anwenden aus.
--- a/docs/post_installation/firststeps-rp.en.md
+++ b/docs/post_installation/firststeps-rp.en.md
@ -0,0 +1,265 @@
 You don't need to change the Nginx site that comes with mailcow: dockerized.
 mailcow: dockerized trusts the default gateway IP 172.22.1.1 as proxy.
 1\. Make sure you change HTTP_BIND and HTTPS_BIND in `mailcow.conf` to a local address and set the ports accordingly, for example:
 ``` bash
 HTTP_BIND=127.0.0.1
 HTTP_PORT=8080
 HTTPS_BIND=127.0.0.1
 HTTPS_PORT=8443
 ```
 This will also change the bindings inside the Nginx container! This is important, if you decide to use a proxy within Docker.
 **IMPORTANT:** Do not use port 8081, 9081 or 65510!
 Recreate affected containers by running `docker-compose up -d`.
 **Important information, please read them carefully!**
 !!! info
    If you plan to use a reverse proxy and want to use another server name that is **not** MAILCOW_HOSTNAME, you need to read **Adding additional server names for mailcow UI** at the bottom of this page.
 !!! warning
    Make sure you run `generate_config.sh` before you enable any site configuration examples below.
    The script `generate_config.sh` copies snake-oil certificates to the correct location, so the services will not fail to start due to missing files.
 !!! warning
    If you enable TLS SNI (`ENABLE_TLS_SNI` in mailcow.conf), the certificate paths in your reverse proxy **must** match the correct paths in data/assets/ssl/{hostname}. The certificates will be split into `data/assets/ssl/{hostname1,hostname2,etc}` and therefore will not work when you copy the examples from below pointing to `data/assets/ssl/cert.pem` etc.
 !!! info
    Using the site configs below will **forward ACME requests to mailcow** and let it handle certificates itself.
    The downside of using mailcow as ACME client behind a reverse proxy is, that you will need to reload your webserver after acme-mailcow changed/renewed/created the certificate. You can either reload your webserver daily or write a script to watch the file for changes.
    On many servers logrotate will reload the webserver daily anyway.
    If you want to use a local certbot installation, you will need to change the SSL certificate parameters accordingly.
    **Make sure you run a post-hook script** when you decide to use external ACME clients. You will find an example at the bottom of this page.
 2\. Configure your local webserver as reverse proxy:
 ### Apache 2.4
 Required modules:
 ```
 a2enmod rewrite proxy proxy_http headers ssl
 ```
 Let's Encrypt will follow our rewrite, certificate requests in mailcow will work fine.
 **Take care of highlighted lines.**
 ``` apache hl_lines="2 10 11 17 22 23 24 25 30 31"
 <VirtualHost *:80>
  ServerName CHANGE_TO_MAILCOW_HOSTNAME
  ServerAlias autodiscover.*
  ServerAlias autoconfig.*
  RewriteEngine on
  RewriteCond %{HTTPS} off
  RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R=301,L]
  ProxyPass / http://127.0.0.1:8080/
  ProxyPassReverse / http://127.0.0.1:8080/
  ProxyPreserveHost On
  ProxyAddHeaders On
  RequestHeader set X-Forwarded-Proto "http"
 </VirtualHost>
 <VirtualHost *:443>
  ServerName CHANGE_TO_MAILCOW_HOSTNAME
  ServerAlias autodiscover.*
  ServerAlias autoconfig.*
  # You should proxy to a plain HTTP session to offload SSL processing
  ProxyPass /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync connectiontimeout=4000
  ProxyPassReverse /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync
  ProxyPass / http://127.0.0.1:8080/
  ProxyPassReverse / http://127.0.0.1:8080/
  ProxyPreserveHost On
  ProxyAddHeaders On
  RequestHeader set X-Forwarded-Proto "https"
  SSLCertificateFile MAILCOW_PATH/data/assets/ssl/cert.pem
  SSLCertificateKeyFile MAILCOW_PATH/data/assets/ssl/key.pem
  # If you plan to proxy to a HTTPS host:
  #SSLProxyEngine On
  # If you plan to proxy to an untrusted HTTPS host:
  #SSLProxyVerify none
  #SSLProxyCheckPeerCN off
  #SSLProxyCheckPeerName off
  #SSLProxyCheckPeerExpire off
 </VirtualHost>
 ```
 ### Nginx
 Let's Encrypt will follow our rewrite, certificate requests will work fine.
 **Take care of highlighted lines.**
 ``` hl_lines="4 10 12 13 25 39"
 server {
  listen 80 default_server;
  listen [::]:80 default_server;
  server_name CHANGE_TO_MAILCOW_HOSTNAME autodiscover.* autoconfig.*;
  return 301 https://$host$request_uri;
 }
 server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name CHANGE_TO_MAILCOW_HOSTNAME autodiscover.* autoconfig.*;
  ssl_certificate MAILCOW_PATH/data/assets/ssl/cert.pem;
  ssl_certificate_key MAILCOW_PATH/data/assets/ssl/key.pem;
  ssl_session_timeout 1d;
  ssl_session_cache shared:SSL:50m;
  ssl_session_tickets off;
  # See https://ssl-config.mozilla.org/#server=nginx for the latest ssl settings recommendations
  # An example config is given below
  ssl_protocols TLSv1.2;
  ssl_ciphers HIGH:!aNULL:!MD5:!SHA1:!kRSA;
  ssl_prefer_server_ciphers off;
  location /Microsoft-Server-ActiveSync {
    proxy_pass http://127.0.0.1:8080/Microsoft-Server-ActiveSync;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_connect_timeout 75;
    proxy_send_timeout 3650;
    proxy_read_timeout 3650;
    proxy_buffers 64 256k;
    client_body_buffer_size 512k;
    client_max_body_size 0;
  }
  location / {
    proxy_pass http://127.0.0.1:8080/;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    client_max_body_size 0;
  }
 }
 ```
 ### HAProxy (community supported)
 !!! warning
    This is an unsupported community contribution. Feel free to provide fixes.
 **Important/Fixme**: This example only forwards HTTPS traffic and does not use mailcows built-in ACME client.
 ```
 frontend https-in
  bind :::443 v4v6 ssl crt mailcow.pem
  default_backend mailcow
 backend mailcow
  option forwardfor
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
  server mailcow 127.0.0.1:8080 check
 ```
 ### Traefik v2 (community supported)
 !!! warning
    This is an unsupported community contribution. Feel free to provide fixes.
 **Important**: This config only covers the "reverseproxing" of the webpannel (nginx-mailcow) using Traefik v2, if you also want to reverseproxy the mail services such as dovecot, postfix... you'll just need to adapt the following config to each container and create an [EntryPoint](https://docs.traefik.io/routing/entrypoints/) on your `traefik.toml` or `traefik.yml` (depending which config you use) for each port. 
 For this section we'll assume you have your Traefik 2 `[certificatesresolvers]` properly configured on your traefik configuration file, and also using acme, also, the following example uses Lets Encrypt, but feel free to change it to your own cert resolver. You can find a basic Traefik 2 toml config file with all the above implemented which can be used for this example here [traefik.toml](https://github.com/Frenzoid/TraefikBasicConfig/blob/master/traefik.toml) if you need one, or a hint on how to adapt your config.
 So, first of all, we are going to disable the acme-mailcow container since we'll use the certs that traefik will provide us.
 For this we'll have to set `SKIP_LETS_ENCRYPT=y` on our `mailcow.conf`, and run `docker-compose up -d` to apply the changes.
 Then we'll create a `docker-compose.override.yml` file in order to override the main `docker-compose.yml` found in your mailcow root folder. 
 ```yaml
 version: '2.1'
 services:
    nginx-mailcow:
      networks:
        # add Traefik's network
        web:
      labels:
        - traefik.enable=true
        # Creates a router called "moo" for the container, and sets up a rule to link the container to certain rule,
        #   in this case, a Host rule with our MAILCOW_HOSTNAME var.
        - traefik.http.routers.moo.rule=Host(`${MAILCOW_HOSTNAME}`)
        # Enables tls over the router we created before.
        - traefik.http.routers.moo.tls=true
        # Specifies which kind of cert resolver we'll use, in this case le (Lets Encrypt).
        - traefik.http.routers.moo.tls.certresolver=le
        # Creates a service called "moo" for the container, and specifies which internal port of the container
        #   should traefik route the incoming data to.
        - traefik.http.services.moo.loadbalancer.server.port=${HTTP_PORT}
        # Specifies which entrypoint (external port) should traefik listen to, for this container.
        #   websecure being port 443, check the traefik.toml file liked above.
        - traefik.http.routers.moo.entrypoints=websecure
        # Make sure traefik uses the web network, not the mailcowdockerized_mailcow-network
        - traefik.docker.network=web
    certdumper:
        image: humenius/traefik-certs-dumper
        container_name: traefik_certdumper
        network_mode: none
        volumes:
          # mount the folder which contains Traefik's `acme.json' file
          #   in this case Traefik is started from its own docker-compose in ../traefik
          - ../traefik/data:/traefik:ro
          # mount mailcow's SSL folder
          - ./data/assets/ssl/:/output:rw
        environment:
          # only change this, if you're using another domain for mailcow's web frontend compared to the standard config
          - DOMAIN=${MAILCOW_HOSTNAME}
 networks:
  web:
    external: true
 ```
 Start the new containers with `docker-compose up -d`.
 Now, there's only one thing left to do, which is setup the certs so that the mail services can use them as well, since Traefik 2 uses an acme v2 format to save ALL the license from all the domains we have, we'll need to find a way to dump the certs, lucky we have [this tiny container](https://hub.docker.com/r/humenius/traefik-certs-dumper) which grabs the `acme.json` file trough a volume, and a variable `DOMAIN=example.org`, and with these, the container will output the `cert.pem` and `key.pem` files, for this we'll simply run the `traefik-certs-dumper` container binding the `/traefik` volume to the folder where our `acme.json` is saved, bind the `/output` volume to our mailcow `data/assets/ssl/` folder, and set up the `DOMAIN=example.org` variable to the domain we want the certs dumped from. 
 This container will watch over the `acme.json` file for any changes, and regenerate the `cert.pem` and `key.pem` files directly into `data/assets/ssl/` being the path binded to the container's `/output` path.
 You can use the command line to run it, or use the docker-compose shown [here](https://hub.docker.com/r/humenius/traefik-certs-dumper).
 After we have the certs dumped, we'll have to reload the configs from our postfix and dovecot containers, and check the certs, you can see how [here](https://mailcow.github.io/mailcow-dockerized-docs/firststeps-ssl/#how-to-use-your-own-certificate).
 Aaand that should be it 😊, you can check if the Traefik router works fine trough Traefik's dashboard / traefik logs / accessing the setted domain trough https, or / and check HTTPS, SMTP and IMAP trough the commands shown on the page linked before.
 ### Optional: Post-hook script for non-mailcow ACME clients
 Using a local certbot (or any other ACME client) requires to restart some containers, you can do this with a post-hook script.
 Make sure you change the paths accordingly:
 ```
 #!/bin/bash
 cp /etc/letsencrypt/live/my.domain.tld/fullchain.pem /opt/mailcow-dockerized/data/assets/ssl/cert.pem
 cp /etc/letsencrypt/live/my.domain.tld/privkey.pem /opt/mailcow-dockerized/data/assets/ssl/key.pem
 postfix_c=$(docker ps -qaf name=postfix-mailcow)
 dovecot_c=$(docker ps -qaf name=dovecot-mailcow)
 nginx_c=$(docker ps -qaf name=nginx-mailcow)
 docker restart ${postfix_c} ${dovecot_c} ${nginx_c}
 ```
 ### Adding additional server names for mailcow UI
 If you plan to use a server name that is not `MAILCOW_HOSTNAME` in your reverse proxy, make sure to populate that name in mailcow.conf via `ADDITIONAL_SERVER_NAMES` first. Names must be separated by commas and **must not** contain spaces. If you skip this step, mailcow may respond to your reverse proxy with an incorrect site.
 ```
 ADDITIONAL_SERVER_NAMES=webmail.domain.tld,other.example.tld
 ```
 Run `docker-compose up -d` to apply.
--- a/docs/post_installation/firststeps-rspamd_ui.de.md
+++ b/docs/post_installation/firststeps-rspamd_ui.de.md
@ -0,0 +1,8 @@
 [Rspamd](https://rspamd.com/) ist ein einfach zu benutzendes Spam-Filter-Tool, das derzeit mit mailcow installiert ist.
 1. Gehen Sie zum mailcow Web-Admin-Interface
 2. Navigieren Sie zur Registerkarte Zugang.(Zugang > Rspamd UI)
 3. Ändern Sie das Rspamd UI Passwort
 4. Gehen Sie in einem Browser zu https://${MAILCOW_HOSTNAME}/rspamd und melden Sie sich an!
 Weitere Konfigurationsoptionen und Dokumentation finden Sie hier: https://rspamd.com/webui/
--- a/docs/post_installation/firststeps-rspamd_ui.en.md
+++ b/docs/post_installation/firststeps-rspamd_ui.en.md
@ -0,0 +1,8 @@
 [Rspamd](https://rspamd.com/) is an easy to use spam filtering tool presently installed with mailcow.
 1. Go to the mailcow web admin interface
 2. Navigate to the Access tab. (Access > Rspamd UI)
 3. Modify the Rspamd UI password
 4. Go to https://${MAILCOW_HOSTNAME}/rspamd in a browser and log in!
 Additional configuration options and documentation can be found here : https://rspamd.com/webui/
--- a/docs/post_installation/firststeps-snat.de.md
+++ b/docs/post_installation/firststeps-snat.de.md
@ -0,0 +1,18 @@
 SNAT wird verwendet, um die Quelladresse der von mailcow gesendeten Pakete zu ändern.
 Es kann verwendet werden, um die ausgehende IP-Adresse auf Systemen mit mehreren IP-Adressen zu ändern.
 Öffnen Sie `mailcow.conf`, setzen Sie einen oder beide der folgenden Parameter:
 ```
 # Benutze diese IPv4 für ausgehende Verbindungen (SNAT)
 SNAT_TO_SOURCE=1.2.3.4
 # Benutze dieses IPv6 für ausgehende Verbindungen (SNAT)
 SNAT6_TO_SOURCE=dead:beef
 ```
 Führen Sie `docker-compose up -d` aus.
 Die Werte werden von netfilter-mailcow gelesen. netfilter-mailcow stellt sicher, dass die Post-Routing-Regeln auf Position 1 in der Netfilter-Tabelle stehen. Es löscht sie automatisch und legt sie neu an, wenn sie an einer anderen Position als 1 gefunden werden.
 Überprüfen Sie die Ausgabe von `docker-compose logs --tail=200 netfilter-mailcow`, um sicherzustellen, dass die SNAT-Einstellungen angewendet wurden.
--- a/docs/post_installation/firststeps-snat.en.md
+++ b/docs/post_installation/firststeps-snat.en.md
@ -0,0 +1,18 @@
 SNAT is used to change the source address of the packets sent by mailcow.
 It can be used to change the outgoing IP address on systems with multiple IP addresses.
 Open `mailcow.conf`, set either or both of the following parameters:
 ```
 # Use this IPv4 for outgoing connections (SNAT)
 SNAT_TO_SOURCE=1.2.3.4
 # Use this IPv6 for outgoing connections (SNAT)
 SNAT6_TO_SOURCE=dead:beef
 ```
 Run `docker-compose up -d`.
 The values are read by netfilter-mailcow. netfilter-mailcow will make sure, the post-routing rules are on position 1 in the netfilter table. It does automatically delete and re-create them if they are found on another position than 1.
 Check the output of `docker-compose logs --tail=200 netfilter-mailcow` to ensure the SNAT settings have been applied.
--- a/docs/post_installation/firststeps-ssl.de.md
+++ b/docs/post_installation/firststeps-ssl.de.md
@ -0,0 +1,170 @@
 ## Let's Encrypt (sofort einsatzbereit)
 Der "acme-mailcow" Container wird versuchen, ein LE-Zertifikat für `${MAILCOW_HOSTNAME}`, `autodiscover.ADDED_MAIL_DOMAIN` und `autoconfig.ADDED_MAIL_DOMAIN` zu erhalten.
 !!! warning
    mailcow **muss** auf Port 80 verfügbar sein, damit der acme-Client funktioniert. Unsere Reverse Proxy Beispielkonfigurationen decken das ab. Sie können auch jeden externen ACME-Client (z.B. certbot) verwenden, um Zertifikate zu erhalten, aber Sie müssen sicherstellen, dass sie an den richtigen Ort kopiert werden und ein Post-Hook die betroffenen Container neu lädt. Weitere Informationen finden Sie in der Reverse Proxy-Dokumentation.
 Standardmäßig, d.h. **0 Domains** sind zu mailcow hinzugefügt, wird es versuchen, ein Zertifikat für `${MAILCOW_HOSTNAME}` zu erhalten.
 Für jede hinzugefügte Domain wird versucht, `autodiscover.ADDED_MAIL_DOMAIN` und `autoconfig.ADDED_MAIL_DOMAIN` in die IPv6-Adresse oder - falls IPv6 in der Domain nicht konfiguriert ist - in die IPv4-Adresse aufzulösen. Wenn dies gelingt, wird ein Name als SAN zur Zertifikatsanforderung hinzugefügt.
 Nur Namen, die validiert werden können, werden als SAN hinzugefügt.
 Für jede Domain, die Sie entfernen, wird das Zertifikat verschoben und ein neues Zertifikat angefordert. Es ist nicht möglich, Domains in einem Zertifikat zu behalten, wenn wir nicht in der Lage sind, die Challenge für diese zu validieren.
 Wenn Sie den ACME-Client neu starten wollen, verwenden Sie `docker-compose restart acme-mailcow` und überwachen Sie die Protokolle mit `docker-compose logs --tail=200 -f acme-mailcow`.
 ### Zusätzliche Domain-Namen
 Bearbeiten Sie "mailcow.conf" und fügen Sie einen Parameter `ADDITIONAL_SAN` wie folgt hinzu:
 Verwenden Sie keine Anführungszeichen (`"`) und keine Leerzeichen zwischen den Namen!
 ```
 ADDITIONAL_SAN=smtp.*,cert1.example.com,cert2.example.org,whatever.*
 ```
 Jeder Name wird anhand seiner IPv6-Adresse oder - wenn IPv6 in Ihrer Domäne nicht konfiguriert ist - anhand seiner IPv4-Adresse überprüft.
 Ein Wildcard-Name wie `smtp.*` wird versuchen, ein smtp.DOMAIN_NAME SAN für jede zu mailcow hinzugefügte Domain zu erhalten.
 Führen Sie `docker-compose up -d` aus, um betroffene Container automatisch neu zu erstellen.
 !!! info
    Die Verwendung anderer Namen als `MAILCOW_HOSTNAME` für den Zugriff auf das mailcow UI kann weitere Konfiguration erfordern.
 Wenn Sie planen, einen anderen Servernamen als `MAILCOW_HOSTNAME` für den Zugriff auf die mailcow UI zu verwenden (z.B. durch Hinzufügen von `mail.*` zu `ADDITIONAL_SAN`), stellen Sie sicher, dass Sie diesen Namen in mailcow.conf über `ADDITIONAL_SERVER_NAMES` eintragen. Die Namen müssen durch Kommas getrennt sein und **dürfen** keine Leerzeichen enthalten. Wenn Sie diesen Schritt auslassen, kann mailcow mit einer falschen Seite antworten.
 ```
 ADDITIONAL_SERVER_NAMES=webmail.domain.tld,other.example.tld
 ```
 Führen Sie `docker-compose up -d` aus, um es anzuwenden.
 ### Erneuerung erzwingen
 Um eine Erneuerung zu erzwingen, müssen Sie eine Datei namens `force_renew` erstellen und den `acme-mailcow` Container neu starten:
 ```
 cd /opt/mailcow-dockerized
 touch data/assets/ssl/force_renew
 docker-compose restart acme-mailcow
 # Prüfen Sie nun die Logs auf eine Erneuerung
 docker-compose logs --tail=200 -f acme-mailcow
 ```
 Die Datei wird automatisch gelöscht.
 ### Validierungsfehler und wie man die Validierung überspringt
 Sie können die **IP-Überprüfung** überspringen, indem Sie `SKIP_IP_CHECK=y` in mailcow.conf setzen (keine Anführungszeichen). Seien Sie gewarnt, dass eine Fehlkonfiguration dazu führt, dass Sie von Let's Encrypt eingeschränkt werden! Dies ist vor allem für Multi-IP-Setups nützlich, bei denen der IP-Check die falsche Quell-IP-Adresse zurückgeben würde. Aufgrund der Verwendung von dynamischen IPs für acme-mailcow ist Source-NAT bei Neustarts nicht konsistent.
 Wenn Sie Probleme mit der "HTTP-Validierung" haben, aber Ihre IP-Adressbestätigung erfolgreich ist, verwenden Sie höchstwahrscheinlich firewalld, ufw oder eine andere Firewall, die Verbindungen von `br-mailcow` zu Ihrem externen Interface verbietet. Sowohl firewalld als auch ufw lassen dies standardmäßig nicht zu. Es reicht oft nicht aus, diese Firewall-Dienste einfach zu stoppen. Sie müssen mailcow stoppen (`docker-compose down`), den Firewall-Dienst stoppen, die Ketten flushen und Docker neu starten.
 Sie können diese Validierungsmethode auch überspringen, indem Sie `SKIP_HTTP_VERIFICATION=y` in "mailcow.conf" setzen. Seien Sie gewarnt, dass dies nicht zu empfehlen ist. In den meisten Fällen wird die HTTP-Überprüfung übersprungen, um unbekannte NAT-Reflection-Probleme zu umgehen, die durch das Ignorieren dieser spezifischen Netzwerk-Fehlkonfiguration nicht gelöst werden. Wenn Sie Probleme haben, TLSA-Einträge in der DNS-Übersicht innerhalb von mailcow zu generieren, haben Sie höchstwahrscheinlich Probleme mit NAT-Reflexion, die Sie beheben sollten.
 Wenn du einen SKIP_* Parameter geändert hast, führe `docker-compose up -d` aus, um deine Änderungen zu übernehmen.
 ### Deaktivieren Sie Let's Encrypt
 #### Deaktivieren Sie Let's Encrypt vollständig
 Setzen Sie `SKIP_LETS_ENCRYPT=y` in "mailcow.conf" und erstellen Sie "acme-mailcow" neu, indem Sie `docker-compose up -d` ausführen.
 #### Alle Namen außer ${MAILCOW_HOSTNAME} überspringen
 Fügen Sie `ONLY_MAILCOW_HOSTNAME=y` zu "mailcow.conf" hinzu und erstellen Sie "acme-mailcow" neu, indem Sie `docker-compose up -d` ausführen.
 ### Das Let's Encrypt subjectAltName-Limit von 100 Domains
 Let's Encrypt hat derzeit [ein Limit von 100 Domainnamen pro Zertifikat](https://letsencrypt.org/docs/rate-limits/).
 Standardmäßig erstellt "acme-mailcow" ein einzelnes SAN-Zertifikat für alle validierten Domains
 (siehe den [ersten Abschnitt](#lets-encrypt-out-of-the-box) und [Zusätzliche Domainnamen](#additional-domain-names)).
 Dies bietet beste Kompatibilität, bedeutet aber, dass das Let's Encrypt-Limit überschritten wird, wenn Sie zu viele Domains zu einer einzelnen Mailcow-Installation hinzufügen.
 Um dies zu lösen, können Sie `ENABLE_SSL_SNI` so konfigurieren, dass es generiert wird:
 - Ein Hauptserver-Zertifikat mit `MAILCOW_HOSTNAME` und allen voll qualifizierten Domainnamen in der `ADDITIONAL_SAN` Konfiguration
 - Ein zusätzliches Zertifikat für jede in der Datenbank gefundene Domain mit autodiscover.*, autoconfig.* und jeder anderen in diesem Format konfigurierten `ADDITIONAL_SAN` (subdomain.*).
 - Begrenzungen: Ein Zertifikatsname `ADDITIONAL_SAN=test.example.com` wird als SAN zum Hauptzertifikat hinzugefügt. Ein separates Zertifikat/Schlüsselpaar wird für dieses Format **nicht** erzeugt.
 Postfix, Dovecot und Nginx werden dann diese Zertifikate mit SNI bedienen.
 Setzen Sie `ENABLE_SSL_SNI=y` in "mailcow.conf" und erstellen Sie "acme-mailcow" durch Ausführen von `docker-compose up -d`.
 !!! warning
    Nicht alle Clients unterstützen SNI, [siehe Dovecot Dokumentation](https://wiki.dovecot.org/SSL/SNIClientSupport) oder [Wikipedia](https://en.wikipedia.org/wiki/Server_Name_Indication#Support).
    Sie sollten sicherstellen, dass diese Clients den `MAILCOW_HOSTNAME` für sichere Verbindungen verwenden, wenn Sie diese Funktion aktivieren.
 Hier ist ein Beispiel:
 - `MAILCOW_HOSTNAME=server.email.tld`
 - `ADDITIONAL_SAN=webmail.email.tld,mail.*`
 - Mailcow E-Mail-Domänen: "domain1.tld" und "domain2.tld"
 Die folgenden Zertifikate werden generiert:
 - `server.email.tld, webmail.email.tld` -> dies ist das Standard-Zertifikat, alle Clients können sich mit diesen Domains verbinden
 - `mail.domain1.tld, autoconfig.domain1.tld, autodiscover.domain1.tld` -> individuelles Zertifikat für domain1.tld, kann von Clients ohne SNI-Unterstützung nicht verwendet werden
 - `mail.domain2.tld, autoconfig.domain2.tld, autodiscover.domain2.tld` -> individuelles Zertifikat für domain2.tld, kann von Clients ohne SNI-Unterstützung nicht verwendet werden
 ### Wie Sie Ihr eigenes Zertifikat verwenden
 Stellen Sie sicher, dass Sie mailcows internen LE-Client deaktivieren (siehe oben).
 Um Ihre eigenen Zertifikate zu verwenden, speichern Sie einfach das kombinierte Zertifikat (mit dem Zertifikat und der zwischengeschalteten CA/CA, falls vorhanden) unter `data/assets/ssl/cert.pem` und den entsprechenden Schlüssel unter `data/assets/ssl/key.pem`.
 **WICHTIG:** Verwenden Sie keine symbolischen Links! Stellen Sie sicher, dass Sie die Zertifikate kopieren und sie nicht mit `data/assets/ssl` verknüpfen.
 Starten Sie die betroffenen Dienste anschließend neu:
 ```
 docker restart $(docker ps -qaf name=postfix-mailcow)
 docker neu starten $(docker ps -qaf name=nginx-mailcow)
 docker restart $(docker ps -qaf name=dovecot-mailcow)
 ```
 Siehe [Post-Hook-Skript für Nicht-Mailcow-ACME-Clients](../firststeps-rp/#optional-post-hook-script-for-non-mailcow-acme-clients) für ein vollständiges Beispielskript.
 ### Test gegen das ACME-Verzeichnis
 Bearbeiten Sie `mailcow.conf` und fügen Sie `LE_STAGING=y` hinzu.
 Führen Sie `docker-compose up -d` aus, um Ihre Änderungen zu aktivieren.
 ### Benutzerdefinierte Verzeichnis-URL
 Editieren Sie `mailcow.conf` und fügen Sie die entsprechende Verzeichnis-URL in die neue Variable `DIRECTORY_URL` ein:
 ```
 DIRECTORY_URL=https://acme-custom-v9000.api.letsencrypt.org/directory
 ```
 Sie können `LE_STAGING` nicht mit `DIRECTORY_URL` verwenden. Wenn beide gesetzt sind, wird nur `LE_STAGING` verwendet.
 Führen Sie `docker-compose up -d` aus, um Ihre Änderungen zu aktivieren.
 ### Überprüfen Sie Ihre Konfiguration
 Führen Sie `docker-compose logs acme-mailcow` aus, um herauszufinden, warum eine Validierung fehlschlägt.
 Um zu überprüfen, ob nginx das richtige Zertifikat verwendet, benutzen Sie einfach einen Browser Ihrer Wahl und überprüfen Sie das angezeigte Zertifikat.
 Um das von Postfix, Dovecot und Nginx verwendete Zertifikat zu überprüfen, verwenden wir `openssl`:
 ```
 # Verbindung über SMTP (587)
 echo "Q" | openssl s_client -starttls smtp -crlf -connect mx.mailcow.email:587
 # Verbindung über IMAP (143)
 echo "Q" | openssl s_client -starttls imap -showcerts -connect mx.mailcow.email:143
 # Verbindung über HTTPS (443)
 echo "Q" | openssl s_client -connect mx.mailcow.email:443
 ```
 Um die von openssl zurückgegebenen Verfallsdaten gegen MAILCOW_HOSTNAME zu validieren, können Sie unser Hilfsskript verwenden:
 ```
 cd /opt/mailcow-dockerized
 bash helper-scripts/expiry-dates.sh
 ```
--- a/docs/post_installation/firststeps-ssl.en.md
+++ b/docs/post_installation/firststeps-ssl.en.md
@ -0,0 +1,170 @@
 ## Let's Encrypt (out-of-the-box)
 The "acme-mailcow" container will try to obtain a LE certificate for `${MAILCOW_HOSTNAME}`, `autodiscover.ADDED_MAIL_DOMAIN` and `autoconfig.ADDED_MAIL_DOMAIN`.
 !!! warning
    mailcow **must** be available on port 80 for the acme-client to work. Our reverse proxy example configurations do cover that. You can also use any external ACME client (certbot for example) to obtain certificates, but you will need to make sure, that they are copied to the correct location and a post-hook reloads affected containers. See more in the Reverse Proxy documentation.
 By default, which means **0 domains** are added to mailcow, it will try to obtain a certificate for `${MAILCOW_HOSTNAME}`.
 For each domain you add, it will try to resolve `autodiscover.ADDED_MAIL_DOMAIN` and `autoconfig.ADDED_MAIL_DOMAIN` to its IPv6 address or - if IPv6 is not configured in your domain - IPv4 address. If it succeeds, a name will be added as SAN to the certificate request.
 Only names that can be validated, will be added as SAN.
 For every domain you remove, the certificate will be moved and a new certificate will be requested. It is not possible to keep domains in a certificate, when we are not able validate the challenge for those.
 If you want to re-run the ACME client, use `docker-compose restart acme-mailcow` and monitor its logs with `docker-compose logs --tail=200 -f acme-mailcow`.
 ### Additional domain names
 Edit "mailcow.conf" and add a parameter `ADDITIONAL_SAN` like this:
 Do not use quotes (`"`) and do not use spaces between the names!
 ```
 ADDITIONAL_SAN=smtp.*,cert1.example.com,cert2.example.org,whatever.*
 ```
 Each name will be validated against its IPv6 address or - if IPv6 is not configured in your domain - IPv4 address.
 A wildcard name like `smtp.*` will try to obtain a smtp.DOMAIN_NAME SAN for each domain added to mailcow.
 Run `docker-compose up -d` to recreate affected containers automatically.
 !!! info
    Using names other name `MAILCOW_HOSTNAME` to access the mailcow UI may need further configuration.
 If you plan to use a server name that is not `MAILCOW_HOSTNAME` to access the mailcow UI (for example by adding `mail.*` to `ADDITIONAL_SAN` make sure to populate that name in mailcow.conf via `ADDITIONAL_SERVER_NAMES`. Names must be separated by commas and **must not** contain spaces. If you skip this step, mailcow may respond with an incorrect site.
 ```
 ADDITIONAL_SERVER_NAMES=webmail.domain.tld,other.example.tld
 ```
 Run `docker-compose up -d` to apply.
 ### Force renewal
 To force a renewal, you need to create a file named `force_renew` and restart the `acme-mailcow` container:
 ```
 cd /opt/mailcow-dockerized
 touch data/assets/ssl/force_renew
 docker-compose restart acme-mailcow
 # Now check the logs for a renewal
 docker-compose logs --tail=200 -f acme-mailcow
 ```
 The file will be deleted automatically.
 ### Validation errors and how to skip validation
 You can skip the **IP verification** by setting `SKIP_IP_CHECK=y` in mailcow.conf (no quotes). Be warned that a misconfiguration will get you ratelimited by Let's Encrypt! This is primarily useful for multi-IP setups where the IP check would return the incorrect source IP address. Due to using dynamic IPs for acme-mailcow, source NAT is not consistent over restarts.
 If you encounter problems with "HTTP validation", but your IP address confirmation succeeds, you are most likely using firewalld, ufw or any other firewall, that disallows connections from `br-mailcow` to your external interface. Both firewalld and ufw disallow this by default. It is often not enough to just stop these firewall services. You'd need to stop mailcow (`docker-compose down`), stop the firewall service, flush the chains and restart Docker.
 You can also skip this validation method by setting `SKIP_HTTP_VERIFICATION=y` in "mailcow.conf". Be warned that this is discouraged. In most cases, the HTTP verification is skipped to workaround unknown NAT reflection issues, which are not resolved by ignoring this specific network misconfiguration. If you encounter problems generating TLSA records in the DNS overview within mailcow, you are most likely having issues with NAT reflection you should fix.
 If you changed a SKIP_* parameter, run `docker-compose up -d` to apply your changes.
 ### Disable Let's Encrypt
 #### Disable Let's Encrypt completely
 Set `SKIP_LETS_ENCRYPT=y` in "mailcow.conf" and recreate "acme-mailcow" by running `docker-compose up -d`.
 #### Skip all names but ${MAILCOW_HOSTNAME}
 Add `ONLY_MAILCOW_HOSTNAME=y` to "mailcow.conf" and recreate "acme-mailcow" by running `docker-compose up -d`.
 ### The Let's Encrypt subjectAltName limit of 100 domains
 Let's Encrypt currently has [a limit of 100 Domain Names per Certificate](https://letsencrypt.org/docs/rate-limits/).
 By default, "acme-mailcow" will create a single SAN certificate for all validated domains
 (see the [first section](#lets-encrypt-out-of-the-box) and [Additional domain names](#additional-domain-names)).
 This provides best compatibility but means the Let's Encrypt limit exceeds if you add too many domains to a single mailcow installation.
 To solve this, you can configure `ENABLE_SSL_SNI` to generate:
 - A main server certificate with `MAILCOW_HOSTNAME` and all fully qualified domain names in the `ADDITIONAL_SAN` config
 - One additional certificate for each domain found in the database with autodiscover.*, autoconfig.* and any other `ADDITIONAL_SAN` configured in this format (subdomain.*).
 - Limitations: A certificate name `ADDITIONAL_SAN=test.example.com` will be added as SAN to the main certificate. A separate certificate/key pair will **not** be generated for this format.
 Postfix, Dovecot and Nginx will then serve these certificates with SNI.
 Set `ENABLE_SSL_SNI=y` in "mailcow.conf" and recreate "acme-mailcow" by running `docker-compose up -d`.
 !!! warning
    Not all clients support SNI, [see Dovecot documentation](https://wiki.dovecot.org/SSL/SNIClientSupport) or [Wikipedia](https://en.wikipedia.org/wiki/Server_Name_Indication#Support).
    You should make sure these clients use the `MAILCOW_HOSTNAME` for secure connections if you enable this feature.
 Here is an example:
 - `MAILCOW_HOSTNAME=server.email.tld`
 - `ADDITIONAL_SAN=webmail.email.tld,mail.*`
 - Mailcow email domains: "domain1.tld" and "domain2.tld"
 The following certificates will be generated:
 - `server.email.tld, webmail.email.tld` -> this is the default certificate, all clients can connect with these domains
 - `mail.domain1.tld, autoconfig.domain1.tld, autodiscover.domain1.tld` -> individual certificate for domain1.tld, cannot be used by clients without SNI support
 - `mail.domain2.tld, autoconfig.domain2.tld, autodiscover.domain2.tld` -> individual certificate for domain2.tld, cannot be used by clients without SNI support
 ### How to use your own certificate
 Make sure you disable mailcows internal LE client (see above).
 To use your own certificates, just save the combined certificate (containing the certificate and intermediate CA/CA if any) to `data/assets/ssl/cert.pem` and the corresponding key to `data/assets/ssl/key.pem`.
 **IMPORTANT:** Do not use symbolic links! Make sure you copy the certificates and do not link them to `data/assets/ssl`.
 Restart affected services afterwards:
 ```
 docker restart $(docker ps -qaf name=postfix-mailcow)
 docker restart $(docker ps -qaf name=nginx-mailcow)
 docker restart $(docker ps -qaf name=dovecot-mailcow)
 ```
 See [Post-hook script for non-mailcow ACME clients](../firststeps-rp/#optional-post-hook-script-for-non-mailcow-acme-clients) for a full example script.
 ### Test against staging ACME directory
 Edit `mailcow.conf` and add `LE_STAGING=y`.
 Run `docker-compose up -d` to activate your changes.
 ### Custom directory URL
 Edit `mailcow.conf` and add the corresponding directory URL to the new variable `DIRECTORY_URL`:
 ```
 DIRECTORY_URL=https://acme-custom-v9000.api.letsencrypt.org/directory
 ```
 You cannot use `LE_STAGING` with `DIRECTORY_URL`. If both are set, only `LE_STAGING` is used.
 Run `docker-compose up -d` to activate your changes.
 ### Check your configuration
 Run `docker-compose logs acme-mailcow` to find out why a validation fails.
 To check if nginx serves the correct certificate, simply use a browser of your choice and check the displayed certificate.
 To check the certificate served by Postfix, Dovecot and Nginx we will use `openssl`:
 ```
 # Connect via SMTP (587)
 echo "Q" | openssl s_client -starttls smtp -crlf -connect mx.mailcow.email:587
 # Connect via IMAP (143)
 echo "Q" | openssl s_client -starttls imap -showcerts -connect mx.mailcow.email:143
 # Connect via HTTPS (443)
 echo "Q" | openssl s_client -connect mx.mailcow.email:443
 ```
 To validate the expiry dates as returned by openssl against MAILCOW_HOSTNAME, you are able to use our helper script:
 ```
 cd /opt/mailcow-dockerized
 bash helper-scripts/expiry-dates.sh
 ```
--- a/docs/post_installation/firststeps-sync_jobs_migration.de.md
+++ b/docs/post_installation/firststeps-sync_jobs_migration.de.md
@ -0,0 +1,22 @@
 Sync-Aufträge werden verwendet, um bestehende E-Mails von einem externen IMAP-Server oder innerhalb von mailcow's bestehenden Mailboxen zu kopieren oder zu verschieben.
 !!! info
    Abhängig von der ACL Ihrer Mailbox haben Sie möglicherweise nicht die Möglichkeit, einen Sync-Job hinzuzufügen. Bitte kontaktieren Sie in diesem Fall Ihren Domain-Administrator.
 ## Einrichten eines Sync-Jobs
 1. Erstellen Sie unter dem Punkt "Konfiguration --> E-Mail-Setup" oder "Benutzereinstellungen" einen neuen Synchronisierungsauftrag.
 2. Wenn Sie ein Administrator sind, wählen Sie den Benutzernamen der nachgelagerten mailcow-Mailbox im Dropdown-Menü "Benutzername".
 3. Füllen Sie die Felder "Host" und "Port" mit den entsprechenden korrekten Werten des vorgelagerten IMAP-Servers aus.
 4. Geben Sie in den Feldern "Benutzername" und "Passwort" die korrekten Zugangsdaten des vorgelagerten IMAP-Servers ein.
 5. Wählen Sie die "Verschlüsselungsmethode". Wenn der vorgelagerte IMAP-Server Port 143 verwendet, ist es wahrscheinlich, dass die Verschlüsselungsmethode TLS und SSL für Port 993 ist. Sie können auch PLAIN-Authentifizierung verwenden, aber davon wird dringend abgeraten.
 6. Alle anderen Felder können Sie so lassen, wie sie sind, oder sie nach Belieben ändern.
 7. Vergewissern Sie sich, dass Sie "Aktiv" ankreuzen und klicken Sie auf "Hinzufügen".
 !!! info
    Sobald Sie fertig sind, melden Sie sich in der Mailbox an und überprüfen Sie, ob alle E-Mails korrekt importiert wurden. Wenn alles gut geht, werden alle Ihre E-Mails in Ihrem neuen Postfach landen. Vergessen Sie nicht, den Synchronisierungsauftrag zu löschen oder zu deaktivieren, nachdem er verwendet wurde.
--- a/docs/post_installation/firststeps-sync_jobs_migration.en.md
+++ b/docs/post_installation/firststeps-sync_jobs_migration.en.md
@ -0,0 +1,22 @@
 Sync jobs are used to copy or move existing emails from an external IMAP server or within mailcow's existing mailboxes.
 !!! info
    Depending on your mailbox's ACL you may not have the option to add a sync job. Please contact your domain administrator if so.
 ## Setup a Sync Job
 1. In the "Mail Setup" or "User Settings" interface, create a new sync job.
 2. If you are an administrator, select the username of the downstream mailcow mailbox in the "Username" dropdown.
 3. Fill in the "Host" and "Port" fields with their respective correct values from the upstream IMAP server.
 4. In the "Username" and "Password" fields, supply the correct access credentials from the upstream IMAP server.
 5. Select the "Encryption Method". If the upstream IMAP server uses port 143, it is likely that the encryption method is TLS and SSL for port 993. Nevertheless, you can use PLAIN authentication, but it is stongly discouraged.
 6. For all ther other fields, you can leave them as is or modify them as desired.
 7. Make sure to tick "Active" and click "Add".
 !!! info
    Once Completed, log into the mailbox and check if all emails are imported correctly. If all goes well, all your mails shall end up in your new mailbox. And don't forget to delete or deactivate the sync job after it is used.
--- a/mkdocs.yml
+++ b/mkdocs.yml
@ -1,6 +1,6 @@
 site_name: 'mailcow: dockerized documentation'
 site_url: https://mailcow.github.io/mailcow-dockerized-docs/
-copyright: "Copyright &copy; 2022 Servercow Team & Community<br>Based on the work from André Peters"
+copyright: "Copyright &copy; 2022 Servercow Team & Community<br>Based on the work from [@andryyy](https://github.com/andryyy)"
 repo_name: mailcow/mailcow-dockerized
 repo_url: https://github.com/mailcow/mailcow-dockerized
 edit_uri: ../mailcow-dockerized-docs/edit/master/docs/
@ -37,16 +37,16 @@ nav:
    - 'Migration': 'i_u_m/i_u_m_migration.md'
    - 'Deinstallation': 'i_u_m/i_u_m_deinstall.md'
  - 'Post Installation Tasks':
-    - 'Advanced SSL': 'firststeps-ssl.md'
+    - 'Advanced SSL': 'post_installation/firststeps-ssl.md'
-    - 'Disable IPv6': 'firststeps-disable_ipv6.md'
+    - 'Disable IPv6': 'post_installation/firststeps-disable_ipv6.md'
-    - 'DMARC Reporting': 'firststeps-dmarc_reporting.md'
+    - 'DMARC Reporting': 'post_installation/firststeps-dmarc_reporting.md'
-    - 'IP bindings': 'firststeps-ip_bindings.md'
+    - 'IP bindings': 'post_installation/firststeps-ip_bindings.md'
-    - 'Local MTA on Docker host': 'firststeps-local_mta.md'
+    - 'Local MTA on Docker host': 'post_installation/firststeps-local_mta.md'
-    - 'Logging': 'firststeps-logging.md'
+    - 'Logging': 'post_installation/firststeps-logging.md'
-    - 'Reverse Proxy': 'firststeps-rp.md'
+    - 'Reverse Proxy': 'post_installation/firststeps-rp.md'
-    - 'Rspamd UI': 'firststeps-rspamd_ui.md'
+    - 'Rspamd UI': 'post_installation/firststeps-rspamd_ui.md'
-    - 'SNAT': 'firststeps-snat.md'
+    - 'SNAT': 'post_installation/firststeps-snat.md'
-    - 'Sync job migration': 'firststeps-sync_jobs_migration.md'
+    - 'Sync job migration': 'post_installation/firststeps-sync_jobs_migration.md'
  - 'Models':
    - 'ACL': 'model-acl.md'
    - 'Password hashing': 'model-passwd.md'