Self-Hosting

Mailrelay wandelt eingehende E-Mails in Webhooks für die Self-Hosted-Automatisierung um

Ein neues Open-Source-Tool namens mailrelay akzeptiert SMTP-Traffic, analysiert E-Mails und löst Webhooks basierend auf konfigurierbaren Regeln für lokale Automatisierungen aus.

Ein Umschlag, der sich in ein Datenpaket verwandelt, das mit Servern verbunden ist
Für diesen Artikel erstellte Illustration

Automatisch aus dem englischen Original übersetzt.

Am 24. Oktober 2026 hat der Entwickler gowthamgts mailrelay veröffentlicht, einen Open-Source-Mailserver für eingehende Nachrichten, der die Lücke zwischen traditionellen E-Mail-Protokollen und moderner HTTP-basierter Automatisierung schließt. Diese Self-Hosted-Lösung ermöglicht es Nutzern, E-Mails zu empfangen, deren Inhalt zu analysieren und Webhooks gemäß spezifischer Regeln auszulösen. Dies erlaubt eine nahtlose Integration mit Homelab-Diensten und Tools für kleine Unternehmen, die keine native Unterstützung für die Aufnahme von E-Mails bieten.

Was ist passiert?

Die Veröffentlichung stellt einen leichtgewichtigen SMTP-Server vor, der in Go geschrieben ist und als Relais für eingehende Nachrichten fungiert. Anstatt E-Mails in einem herkömmlichen Postfach für den menschlichen Leser zu speichern, wertet mailrelay jede Nachricht anhand benutzerdefinierter Bedingungen aus und leitet die Daten an festgelegte Webhook-URLs weiter. Das System ist auf Robustheit ausgelegt: Es bestätigt den Empfang einer E-Mail sofort mit einer 250 OK-Antwort, während die tatsächliche Zustellung des Webhooks asynchron im Hintergrund erfolgt. So wird sichergestellt, dass vorübergehende Fehler oder langsame Antworten nachgelagerter Dienste nicht dazu führen, dass die ursprüngliche E-Mail abgewiesen wird.

Das Projekt bietet mehrere Bereitstellungsoptionen, um unterschiedlichen Infrastrukturpräferenzen gerecht zu werden. Nutzer können es über Docker betreiben, wobei die Weboberfläche standardmäßig aktiviert ist, oder als eigenständige Binary, die aus dem Quellcode erstellt wurde. Die Anwendung speichert alle Betriebsdaten, einschließlich einer SQLite-Datenbank, roher .eml-Dateien und Konfigurationseinstellungen, in einem einzigen /data-Verzeichnis. Diese Struktur vereinfacht Backups und Migrationen für Self-Hoster, die ein minimales Abhängigkeitsmanagement bevorzugen. Eine Quick-Start-Docker-Compose-Datei steht zur Verfügung, damit Nutzer die Funktionalität zunächst mit einem Beispiel-Echo-Server testen können, bevor sie echte Dienste anschließen.

Wichtige Details

  • Regelbasiertes Routing: Nutzer können in der Web-UI Regeln erstellen, die E-Mails basierend auf Feldern wie From, To, Subject, Body, Headern oder SMTP-Umschlagadressen (Envelope) abgleichen. Muster unterstützen Globs und reguläre Ausdrücke.
  • Asynchrone Zustellung mit Wiederholungen: Webhooks werden im Hintergrund mit exponentiellem Backoff gesendet. Jeder Versuch wird protokolliert, und fehlgeschlagene Zustellungen können manuell über die Oberfläche wiederholt werden.
  • Sicherheitsstandards: Standardmäßig können Webhooks keine privaten Netzwerke, localhost oder Cloud-Metadaten-Endpunkte erreichen. Diese Einschränkung kann über Umgebungsvariablen aufgehoben werden, um die Integration interner Dienste zu ermöglichen.
  • Unterstützung für Authentifizierung: Die Web-UI unterstützt OpenID-Connect-(OIDC)-Provider wie Google, Okta und Authentik für sicheren Zugriff, wobei GitHub-Login aufgrund von Protokolleinschränkungen nicht unterstützt wird.
  • Flexible Payload-Formatierung: Webhooks erhalten standardmäßig geparstes JSON, aber Nutzer können die Ausgabe mithilfe von Go-Vorlagen anpassen, die Funktionen zum Verbinden von Listen oder zum Festlegen von Fallback-Werten enthalten.
  • E-Mail-Verifizierung: Der Server führt SPF-, DKIM- und DMARC-Prüfungen durch, mit Optionen zum Protokollieren oder Durchsetzen dieser Richtlinien. Er verifiziert zudem ARC-Header, um Authentifizierungsergebnisse für weitergeleitete Mails beizubehalten.

Hintergrund

Jahrelang erforderte die Integration von E-Mails in automatisierte Workflows komplexe Middleware oder die Abhängigkeit von Drittanbieter-SaaS-Plattformen. Traditionelle SMTP-Server sind für die Kommunikation zwischen Menschen konzipiert und speichern Nachrichten in Postfächern, statt Codeausführungen auszulösen. Webhooks hingegen sind der Standard für die Maschine-zu-Maschine-Kommunikation und ermöglichen es Anwendungen, Echtzeitdaten über HTTP zu senden. Mailrelay überbrückt diese Kluft, indem es als SMTP-Endpunkt fungiert, der E-Mail-Ereignisse in HTTP-Anfragen übersetzt.

Dieser Ansatz ist besonders wertvoll für Self-Hosted-Umgebungen, in denen Datenschutz und Kontrolle Priorität haben. Anstatt einem Cloud-Dienst Zugriff auf sensible Finanzwarnungen oder Support-Tickets zu gewähren, können Organisationen die gesamte Pipeline innerhalb ihres eigenen Netzwerks halten. Das Tool übernimmt die Komplexitäten der E-Mail-Analyse, einschließlich Extraktion von Anhängen und Header-Analyse, und präsentiert die Daten in einem sauberen JSON-Format, das moderne Anwendungen leicht verarbeiten können.

Warum das wichtig ist

Teams, die ihre eigene Software betreiben, haben oft Schwierigkeiten, Legacy-basierte E-Mail-Benachrichtigungen mit modernen Dashboards und Automatisierungstools zu verbinden. Beispielsweise landen Bankbenachrichtigungen, Versandstatusmeldungen oder Systemüberwachungs-E-Mails typischerweise im Postfach und erfordern manuelle Eingriffe zur Reaktion. Mailrelay ermöglicht es diesen Nachrichten, automatisch Aktionen in Tools wie Home Assistant, Paperless-ngx oder benutzerdefinierten APIs auszulösen. Dies reduziert den manuellen Arbeitsaufwand und stellt sicher, dass kritische Informationen ohne menschliche Verzögerung sofort verarbeitet werden.

Darüber hinaus ist die Möglichkeit, Webhooks erneut zuzustellen, ein erheblicher betrieblicher Vorteil. In verteilten Systemen können Netzwerkstörungen oder Neustarts von Diensten dazu führen, dass Webhook-Zustellungen fehlschlagen. Ohne einen Wiederholungsmechanismus gehen diese Ereignisse für immer verloren. Mailrelay protokolliert jeden Versuch und ermöglicht Administratoren, bestimmte E-Mails über die UI erneut zu senden, was die Datenkonsistenz gewährleistet. Die standardmäßige Sicherheitskonfiguration, die den Zugriff auf private Netzwerke blockiert, es sei denn, dies ist explizit erlaubt, schützt auch vor versehentlichem internem Datenleck bei der Konfiguration extern zugänglicher Dienste.

Was Sie tun können

  • Stellen Sie den Quick-Start-Docker-Compose-Stack bereit, um den SMTP-Listener und den Webhook-Echo-Server lokal zu testen.
  • Konfigurieren Sie smtp.allowed_recipients, um den Server so einzuschränken, dass er nur E-Mails für Ihre spezifischen Domains oder Adressen akzeptiert.
  • Richten Sie OIDC-Authentifizierung für die Web-UI unter Verwendung von Providern wie Authentik oder Keycloak ein, um den administrativen Zugriff zu sichern.
  • Verwenden Sie Go-Vorlagen in der Regelkonfiguration, um unnötige Header zu entfernen und die Größe des Payloads zu reduzieren, das an nachgelagerte Dienste gesendet wird.
  • Aktivieren Sie webhook.allow_private_networks nur, wenn sich Ihre Zielautomatisierungsdienste im selben lokalen Netzwerk oder Docker-Bridge-Netzwerk befinden.
  • Überwachen Sie den /metrics-Endpunkt mit Prometheus, um das E-Mail-Volumen, die Erfolgsraten der Webhooks und die Anzahl der Wiederholungen zu verfolgen.

Weitere News

Alle News