EVOMATION.DEAGENT VIEW
← Human View
################################################################################
# EVOMATION.DE — AGENT ACCESS GUIDE
################################################################################

DOCUMENT PURPOSE
----------------
You are reading the low-noise agent view for evomation.de.
This AX layer exists for LLMs, browser agents, and automated systems that need a
direct description of domain fit, route purpose, contact paths, and legal or
compliance references.

Entity:    Evomation-Michael Meese e.K.
Domain:    evomation.de
Role:      Custom software, automation, integration, and retrofit-oriented systems
Audience:  Logistics, intralogistics, manufacturing, and adjacent operational teams
Route Locale: de
AX Language: English only

READING RULES
-------------
- Treat this as the canonical low-noise summary for the current page.
- The public human-facing website is available under both /de and /en.
- AX output remains in English on both locale routes.
- Sections are delimited by H2 headers.
- Subsections use H3 and H4.
- Prefer explicit paths over inference.
- Legal identity: /de/impressum/llms.txt
- Privacy / GDPR: /de/datenschutz/llms.txt
- Cookie inventory: /de/cookie-richtlinie/llms.txt

READING MODES
-------------
1. Human View
   Use the public route without modifiers.
   Example: /de/ueber-uns

2. Agent View
   Use the same public route with ?view=agent.
   Example: /de/ueber-uns?view=agent

3. LLM Text View
   Use the locale-prefixed llms.txt route.
   Examples:
   - /de/llms.txt
   - /de/ueber-uns/llms.txt
   - /de/kontakt/llms.txt

ROUTE PATTERN
-------------
For a page at /{locale}/x:
- Human View: /{locale}/x
- Agent View: /{locale}/x?view=agent
- LLM Text View: /{locale}/x/llms.txt

For the locale homepage:
- Human View: /{locale}
- Agent View: /{locale}?view=agent
- LLM Text View: /{locale}/llms.txt

PREFERRED ACCESS STRATEGY
-------------------------
1. Use llms.txt when available for extraction, summarization, routing, or token-efficient reading.
2. Use ?view=agent when you need browser-readable structured HTML with minimal noise.
3. Use the human page only when layout, visual hierarchy, or interaction context matters.

PAGE INDEX
----------
Human View:
  /de  -> homepage
  /de/ueber-uns  -> about and engagement model
  /de/kontakt  -> contact and entry points
  /de/produkte  -> products and tools index
  /de/blog  -> blog index

Agent View:
  /de?view=agent  -> structured homepage
  /de/ueber-uns?view=agent  -> structured about page
  /de/kontakt?view=agent  -> structured contact page
  /de/produkte?view=agent  -> structured products index
  /de/blog?view=agent  -> structured blog index

LLM Text View:
  /de/llms.txt  -> homepage llms.txt
  /de/ueber-uns/llms.txt  -> about llms.txt
  /de/kontakt/llms.txt  -> contact llms.txt
  /de/produkte/llms.txt  -> products llms.txt
  /de/blog/llms.txt  -> blog llms.txt
  /de/impressum/llms.txt  -> legal identity
  /de/datenschutz/llms.txt  -> privacy policy
  /de/cookie-richtlinie/llms.txt  -> cookie policy

DYNAMIC ROUTES
--------------
- Product detail pages live under /de/produkte/{slug}
- Blog article pages live under /de/blog/{slug}
- Industry detail pages live under /de/branchen/{slug}
- Discover valid detail routes from the matching index pages before navigating

################################################################################

Revisionssichere E-Mail-Archivierung mit ecoMAILZ mit Docker & WireGuard.

Snapshot

Article Metadata

AX Summary

A practical setup guide for running ecoMAILZ in Docker behind WireGuard so email archiving remains accessible only through a protected path. The article is procedural and aimed at secure deployment rather than product evaluation.

Use When

Use when the request is about deploying ecoMAILZ securely with Docker and WireGuard or understanding the operational setup behind that stack.

Key Points

  • The article is an implementation walkthrough, not a general email-archiving overview.
  • Docker and WireGuard are used together to restrict exposure and improve deployment control.
  • It is relevant to secure self-hosted archival setups.

Not Useful When

Not useful when the human needs legal policy advice only, or when the request is unrelated to ecoMAILZ deployment.

Section Index

  • H2: Was bedeutet eigentlich revisionssichere Archivierung?
  • H2: Warum ecoMAILZ?
  • H2: ecoMAILZ auf dem Root-Server
  • H2: Lösungsansatz mit Docker und WireGuard
  • H3: Kapselung von ecoMAILZ
  • H3: Der VPN-Dienst WireGuard
  • H3: Zugriff von Extern auf ecoMAILZ
  • H3: Einrichtung des Docker-Netzwerkes
  • H3: Verwendung des erstellten Docker-Netzwerkes
  • H3: Unterschiede zwischen internen und externen Netzwerken
  • H2: Die Docker Compose Configs
  • H3: WireGuard-Konfiguration
  • H2: ecoMAILZ-Konfiguration
  • H2: Schritt-für-Schritt-Anleitung
  • H3: 1. Vorbereitungen
  • H3: 2. Einrichtung WireGuard-Host
  • H3: 3. Konfiguriere die VPN-Clients:
  • H3: 4. Einrichtung von ecoMAILZ
  • H3: 5. Testen des Setups
  • H2: Weitere Einrichtung ecoMAILZ

Original Article Body (German)

--- translationKey: ecoMAILZ-vpn title: Revisionssichere E-Mail-Archivierung mit ecoMAILZ mit Docker & WireGuard. excerpt: Sichere E-Mail-Archivierung leicht gemacht. Diese praktische Anleitung zeigt Ihnen, wie Sie ecoMAILZ als Docker-Container einrichten und mit WireGuard schützen können. Wir führen Sie durch alle Schritte - vom Aufsetzen auf Ihrem Server bis zur sicheren Verbindung über VPN. Perfekt für IT-Teams, die eine revisionssichere E-Mail-Archivierung implementieren möchten, ohne dabei Kompromisse bei der Sicherheit einzugehen. publishedAt: "2025-04-14T08:00:00.000Z" updatedAt: "2026-04-13T08:00:00.000Z" category: technology-insights tags: docker VPN Containerization IT Sicherheit & Compliance How-to E-Mail-Archivierung author: michael-meese visual: type: image imageAssetPath: /tools/evosort-demo-p-3200.png imageAlt: EvoSort Oberfläche in einer macOS Fensteraufnahme featuredOnHomepage: false homepageOrder: 0 seo: title: Schritt-für-Schritt ecoMAILZ als Docker-Container mit WireGuard für sichere E-Mail-Archivierung | Evomation description: Komplette Anleitung zur ecoMAILZ-Installation als Docker-Container mit WireGuard-VPN. Hochsichere, revisionskonforme E-Mail-Archivierung für Unternehmen. --- Ab dem 01.01.2025 wurde die E-Rechnung mehr oder weniger verpflichtend für deutsche Unternehmen. Ich habe mich daher im letzten Jahr für unsere Kunden nochmal mit der revisionssicheren Archivierung von E-Mails befasst und mir verschiedene Lösungen angeschaut. Der folgende Artikel beschreibt ein Setup mit ecoMAILZ, für schlanke Anforderungen, bei dem auf lokale Hardware verzichtet und ecoMAILZ auf einem gehosteten Root-Server betrieben wird. Habe ich bei mir vor Ort bereits ein NAS oder einen Server 24/7 laufen, dann ist ecoMAILZ vermutlich besser dort aufgehoben. Die Anleitung gilt für den Fall grundsätzlich immer noch, man kann sich jedoch dann den Teil mit VPN sparen.

Was bedeutet eigentlich revisionssichere Archivierung?

Grob vereinfacht darf z. B. eine E-Mail, nachdem sie revisionssicher archiviert wurde, nicht mehr gelöscht oder anderweitig verändert werden. Ein normales Backup des Postfaches oder gar das Verschieben in einen "Archivordner" innerhalb des E-Mail-Postfaches ist also definitiv keine revisionssichere Archivierung. Alles klar! Nur wer braucht eine revisionssichere Archivierung? Vor allem vermutlich Unternehmen und andere Organisationen, welche einer gesetzlichen Dokumentationspflicht nachkommen müssen. Hier ist die GoBD das vermutlich wichtigste Stichwort. Ansonsten mag jeder selber entscheiden, ob er seine E-Mail-Postfächer archivieren möchte. Es stellt in jedem Fall ein automatisiertes Backup dar, falls man mal eine E-Mail mit einer Rechnung sucht...

Warum ecoMAILZ?

Je nach Bedarf gibt es verschiedene Lösungen, wie man eine revisionssichere Archivierung von E-Mail-Postfächern hinbekommt. Ich möchte hier die kommerzielle Software ecoMAILZ vorstellen, da diese in meinen Augen folgende Vorteile bietet: webbasierte Lösung die keinen Fatclient benötigt kann plattformunabhängig auf fast allen Systemen mit genug Leistung gehostet werden es gibt ein offizielles Docker-Image sehr faire Preisstruktur und bis 3000 Mails kostenlos einsetzbar beherrscht das Backup vom Exchange Online Postfächern ecoMAILZ lässt sich sehr flexibel auf fast jedem System einrichten, was ich wirklich sehr charmant finde. Durch den offiziellen Docker-Container kann ich ecoMAILZ sogar z. B. auf einem NAS von Synology laufen lassen. Das fand ich zunächst Spielerei, aber das ist durchaus für kleine SoHo-Setups relevant. Vor allem da ich mit aktuellen Synology-NAS eine ganz ordentliche Backupstrategie aufgezogen bekommen. Vielleicht mache ich dazu auch mal einen Artikel...

ecoMAILZ auf dem Root-Server

Was aber tun, wenn man kein NAS zu Hause hat und auch sonst kein stromfressendes Blech laufen lassen möchte? Vielleicht könnte man ecoMAILZ auf einem Linux-Root-Server hosten, auf dem zufällig noch etwas Platz ist? Ich hatte jedoch ein wenig Bauchschmerzen bei dem Gedanken, ecoMAILZ einfach so an eine Subleveldomain zu hängen und für jedermann im Internet erreichbar zu machen. Ich will damit jetzt nicht sagen, dass ich ecoMAILZ Qualitätsmängel unterstelle, aber meine E-Mail-Archivierung gehört IMHO nicht direkt ins Netz. Also doch lieber nicht auf den Root-Server packen? Es gibt da evtl. einen Kompromiss: ecoMAILZ liegt als offizielles Docker-Image und so wäre es möglich mit den Netzwerkfunktionen von Docker, das Webfrontend von ecoMAILZ in einem internen Netzwerk "einzusperren" und nur über einen VPN-Tunnel erreichbar machen! So läuft das ecoMAILZ zwar auf dem Root-Server, ist aber nur für autorisierte Anwender über den VPN-Tunnel erreichbar. Der folgende Artikel beschreibt daher, wie man ecoMAILZ auf dem Root-Server in einer Dockerumgebung so betreibt, dass es nur für authorisierte Benutzer überhaupt erreichbar wird.

Lösungsansatz mit Docker und WireGuard

Kapselung von ecoMAILZ

Da Docker auf ein eigenes virtuelles Netzwerk setzt, kann ich so die Schnittstellen und das Webfrontend von ecoMAILZ in ein internes Netzwerk einsperren. Der Dienst ist so nicht über das Netzwerkinterface des Hosts erreichbar und ich kann auf eine alternative Lösung mit Firewallregeln verzichten. Die Konfiguration sieht grob wie folgt aus: Kein Portmapping: Es wird bewusst kein Portmapping vorgenommen, um zu verhindern, dass die Schnittstellen und das Webfrontend von ecoMAILZ öffentlich zugänglich sind. Virtuelles internes Docker-Netzwerk: Es wird ein internes Docker-Netzwerk namens ecomailz_intern erstellt, in dem ecoMAILZ läuft. Dieses Netzwerk ist nur innerhalb der Docker-Umgebung erreichbar. Internet-Zugriff: Der ecoMAILZ-Container wird mit dem Docker-Standardnetzwerk default verbunden, um Zugriff auf das Internet für den Abruf von E-Mails zu erhalten.

Der VPN-Dienst WireGuard

Für den sicheren Zugriff interner Benutzer auf das interne Docker-Netzwerk wird der VPN-Dienst WireGuard als Docker-Container implementiert. Dieser Dienst bietet folgende Funktionen: Zugriff auf das virtuelle Docker-Netzwerk ecomailz_intern. Zugriff auf das Internet über das Docker-Standardnetzwerk default. Externe Erreichbarkeit durch Mapping des WireGuard-Ports auf die Netzwerkkarte des Docker-Hosts. Um die Wiederverwendbarkeit zu gewährleisten, wird WireGuard als eigenständiges Docker-Projekt realisiert, das unabhängig von ecoMAILZ betrieben wird. Man kann WireGuard auch in einem gemeinsamen Docker Projekt laufen lassen, was die Konfiguration etwas erleichtert und verkürzt. Darauf habe ich aber explizit verzichtet, um ggf. bei einem weiteren ähnlichen Projekt nicht mehrere WireGuard-Instanzen parallel betreiben zu müssen.

Zugriff von Extern auf ecoMAILZ

Da Docker zur internen Kommunikation DNS-Namensauflösung nutzt, stellt sich die Frage, wie externe Benutzer über den VPN-Tunnel auf das ecoMAILZ-Webfrontend zugreifen können. Folgende Optionen wurden bewertet: Manuelle Nutzung der IP-Adresse: Die interne IP-Adresse des ecoMAILZ-Containers kann ausgelesen und auf dem Client verwendet werden. Problematisch ist jedoch, dass diese IP-Adresse sich ändern könnte, obwohl sie semi-statisch ist. Alternativ kann die IP-Adresse manuell gesetzt werden. Expose der Docker-internen DNS-Namensauflösung: Die interne DNS-Namensauflösung von Docker kann nach außen sichtbar gemacht werden. Dies birgt jedoch IMHO Sicherheitsrisiken, da dadurch die DNS-Namen aller Docker-Container einsehbar werden. Parallele DNS-Infrastruktur: Mithilfe von dnsmasq kann eine eigene DNS-Infrastruktur für die Container erstellt werden. Diese löst nur die Namen der relevanten Container auf und ist technisch die sauberste Lösung. Um den Aufwand bei dem übersichtlichen Setup im Rahmen zu halten, habe ich die erste Option gewählt.

Einrichtung des Docker-Netzwerkes

Da wir ecoMAILZ und WireGuard in zwei getrennten Docker-Projekten betreiben, müssen die beiden Container über ein gemeinsames internes Netzwerk kommunizieren, um den Zugriff auf das ecoMAILZ-Frontend über den WireGuard-VPN-Tunnel zu ermöglichen. Dieses interne Netzwerk wird manuell erstellt und anschließend in den jeweiligen docker-compose.yml-Dateien eingebunden, damit beide Projekte das Netzwerk gemeinsam nutzen können. Um die genannten Anforderungen zu erfüllen, wird das interne Netzwerk ecomailz_intern wie folgt erstellt: bash docker network create --driver bridge --internal ecomailz_network

Verwendung des erstellten Docker-Netzwerkes

Das manuell erstellte Netzwerk ecomailz_internal wird in den docker-compose.yml-Dateien der Projekte eingebunden und als external: true deklariert, um eine gemeinsame Nutzung zu ermöglichen.

Unterschiede zwischen internen und externen Netzwerken Interne Netzwerke: internal: true

>"By default, Compose provides external connectivity to networks. Setting internal: true allows you to create an externally isolated network." - Quelle: Docker Documentation Diese Netzwerke sind vollständig isoliert. Nur Container innerhalb des gleichen Netzwerks können miteinander kommunizieren. Weder andere Docker-Netzwerke noch der Host haben Zugriff. Diese Konfiguration eignet sich ideal für Dienste, die ausschließlich intern genutzt werden. Externe Netzwerke: external: true > "If set to true, external specifies that this network’s lifecycle is maintained outside of that of the application." - Quelle: Docker Documentation Diese Netzwerke werden manuell erstellt und können von mehreren Projekten gemeinsam genutzt werden. Sie erlauben die Kommunikation zwischen Containern verschiedener Projekte und den Zugriff durch externe Clients, beispielsweise über einen VPN-Tunnel. Diese Konfiguration ermöglicht, dass ecoMAILZ und WireGuard über ein gemeinsames internes Netzwerk miteinander kommunizieren können, während die Dienste vor direktem Internetzugriff geschützt bleiben.

Die Docker Compose Configs

WireGuard-Konfiguration

Dokumentation des Docker-Image-Maintainers LinuxServer.io zur Einrichtung, Betrieb und Parametrisierung. yaml version: '3.8' services: wireguard: image: lscr.io/linuxserver/wireguard:latest container_name: wireguard cap_add: NET_ADMIN SYS_MODULE environment: PUID=1000 PGID=1000 TZ=Europe/Berlin SERVERURL=wireguard.DEINEDOMAIN.de SERVERPORT=51820 PEERS=1 PEERDNS=1.1.1.1 volumes: ./wireguard-config:/config /lib/modules:/lib/modules ports: 51820:51820/udp networks: default ecomailz_network sysctls: net.ipv4.conf.all.src_valid_mark=1 restart: unless-stopped networks: ecomailz_network: external: true

ecoMAILZ-Konfiguration

yaml version: '3.8' services: ecomailz: image: ecomailz/donnie container_name: ecomailz volumes: ./export:/srv/export ./backup:/srv/backup ./data:/srv/data networks: default ecomailz_network restart: unless-stopped networks: ecomailz_network: external: true

Schritt-für-Schritt-Anleitung

1. Vorbereitungen Voraussetzungen: Ein laufender Debian oder Ubuntu Root-Server mit Docker und Docker Compose. Zugang zu den ecoMailz-Installations- und Konfigurationsdokumentationen. Falls Exchange Online verwendet wird, Vorbereitung des M365-Azure-Umgebung für die Anbindung des ecoMAILZ-Adapters - siehe Anleitung in der ecoMAILZ-Dokumentation. Verzeichnisse für ecoMAILZ erstellen:

bash mkdir -p /var/docker/ecomailz mkdir -p /var/docker/ecomailz/export mkdir -p /var/docker/ecomailz/backup mkdir -p /var/docker/ecomailz/data Verzeichnisse für Wireguard erstellen: bash mkdir -p /var/docker/wireguard mkdir -p /var/docker/wireguard/wireguard-config

2. Einrichtung WireGuard-Host Erstelle das interne Netzwerk:

bash docker network create --driver bridge --internal ecomailz_network Das gemeinsame interne Docker-Netzwerk muss existieren, bevor die Container gestartet werden. Wechsle in das WireGuard-Verzeichnis: bash cd /var/docker/wireguard Erstelle die Docker-Compose-Datei: bash vim docker-compose.yml Übernimm die WireGurard-Konfiguration (siehe weiter oben) und passe sie nach Bedarf an. Starte den WireGuard-Container: bash docker-compose up -d

3. Konfiguriere die VPN-Clients:

Die Konfigurationsdatei für den WireGuard-Client wird beim ersten Start des Containers automatisch erzeugt. Lade die Client-Konfigurationsdatei herunter: bash docker exec wireguard cat /config/peer1/peer1.conf > ./peer1.conf und importiere die Konfiguration in deinen WireGuard-Client. Anschließend starte die VPN-Verbindung. Der Zugriff auf das öffentliche Internet sollte weiterhin klappen und nach außen sollte dein Rechner jetzt mit der öffentliche IP-Adresse deines Root-Server unterwegs sein.

4. Einrichtung von ecoMAILZ Wechsle in das ecoMAILZ-Verzeichnis und erstelle die docker-compose.yml:

bash cd /var/docker/ecomailz bash vim docker-compose.yml Kopiere die ecoMAILZ-Konfiguration (siehe weiter oben) Starte den ecoMAILZ-Container: bash docker-compose up -d

5. Testen des Setups

5.1 Überprüfung der internen Kommunikation Prüfe, ob beide Container Teil des Netzwerkes ecomailz_intern sind und eine entsprechende IP-Adresse besitzen:

bash docker network inspect ecomailz_intern json [ { "Name": "ecomailz_intern", ... ... ... "Containers": { "6b918731931aa20ab901caaef977ae633a925cabe9e05cc77646f50951532e37": { "Name": "wireguard", "EndpointID": "c428e9b7576a248118a4ac029e9291eb20ca205b7bf67d07d3372cff72cb84f6", "MacAddress": "02:42:ac:15:00:02", "IPv4Address": "172.21.0.2/16", "IPv6Address": "" }, "c1ba331c23004291eb8176bc888f0f325398871bee7a7e077daab084e0836efc": { "Name": "ecomailz", "EndpointID": "66c95b3ce6ed755a8bf0a86a0f29f09f4f1245876ceb012ce209bc75bcbbe61d", "MacAddress": "02:42:ac:15:00:03", "IPv4Address": "172.21.0.3/16", "IPv6Address": "" } }, ... ... ... } ] Prüfe, ob der WireGuard-Container den ecoMAILZ-Container per ping erreichen kann: bash docker exec wireguard ping -c 4 ecomailz

5.2 Zugriff auf ecoMAILZ über VPN:

Da wir interne Kommunikation zwischen den Docker-Containern erfolgreich geprüft haben, sollte der Zugriff über die VPN-Verbindung ebenfalls funktionieren. Baue die VPN-Verbindung und fahre mit den folgenden Tests fort: Ermittle oder zumindest überprüfe die interne IP-Adresse des ecoMAILZ-Containers: bash docker network inspect ecomailz_intern Prüfe, ob die interne Adresse des ecoMAILZ-Containers per ping von deinem Client erreichen kannst. Wenn auch das klappt, solltest du das Webfrontend von ecoMAILZ im Browser öffnen können: text http:// :8888

Weitere Einrichtung ecoMAILZ

Ab hier kann nun mit der weiteren regulären Einrichtung des ecoMAILZ-Dienstes fortgefahren werden. Offizielle ecoMAILZ-Dokumentation: Dokumentationsübersicht ecoMAILZ "Donnie" Allgemeine Installationsanleitung (PDF) Allgemeine Einrichtungsanleitung (PDF) Anleitung zur Einrichtung in Microsoft Azure für Microsoft Graph Einrichtung eines M365 Adapter in ecoMAILZ

Related Articles