Zum Inhalt

ADR-016: Hostpoint als E-Mail-Provider

Stand: 08.08.2026 13:28 Branch: main Status: Akzeptiert

Datum, Uhrzeit Version Änderung Autor
08.08.2026 13:28 1.0 Hostpoint als bevorzugten V1-Provider für transaktionale E-Mails mit Produktivsperre bis zum vollständigen Providernachweis festgelegt Codex

Kontext

UC00 benötigt transaktionale E-Mails für Einladungen, Passwortzurücksetzung, Vertragslinks und Sicherheitsinformationen. Das Backend verwendet bereits Nodemailer und eine generische SMTP-Konfiguration. Ältere Reviews diskutieren Resend; der aktuelle UC00-Entscheid schliesst Resend und einen selbst betriebenen Mailserver für V1 aus.

Hetzner stellt für Cloud Server keinen eigenständigen verwalteten Transaktionsmaildienst bereit. SMTP gehört dort zu Webhosting oder Managed Servern. Hostpoint ist bereits langjähriger Provider des Product Owners und bietet authentifizierten SMTP, Schweizer Infrastruktur und E-Mail-Authentifizierung für die eigene Domain.

SMTP bedeutet Simple Mail Transfer Protocol und ist das Standardprotokoll zur Übermittlung von E-Mails an einen Mailserver.

Geprüfte Varianten

Variante A: Hostpoint

  • Authentifizierter SMTP-Versand über asmtp.mail.hostpoint.ch mit Port 587 und STARTTLS ist dokumentiert.
  • SPF, DKIM und DMARC sowie strikte Absenderrichtlinien werden unterstützt.
  • Hostpoint AG ist Schweizer Vertragspartei und beschreibt Hosting- und Datentransferleistungen grundsätzlich als Auftragsbearbeitung.
  • Eine bestehende, langjährig bewährte Kundenbeziehung reduziert Einführungs- und Betriebsaufwand.
  • Hostpoint ist kein spezialisierter Transaktionsmaildienst; feste Versandgrenzen, automatisierte Bounce-Webhooks und der konkrete Unterauftragnehmerumfang sind vor Produktivbetrieb noch zu bestätigen.

Variante B: Hetzner-Webhosting-SMTP

  • Technisch über Port 587 und STARTTLS mit der bestehenden Implementierung nutzbar.
  • Verarbeitung in deutschen Rechenzentren und Auftragsverarbeitungsvertrag sind grundsätzlich möglich.
  • Ein zusätzliches Webhostingprodukt wäre nur für SMTP erforderlich.
  • Auch dieses Angebot ist kein eigenständiger Transaktionsmaildienst und besitzt keine dokumentierten Bounce-Webhooks.

Variante C: Spezialisierter Transaktionsmaildienst

  • Bietet typischerweise Zustellereignisse, Bounce-Webhooks und detaillierte Reputationserkennung.
  • Benötigt eine zusätzliche Anbieter-, Regionen-, Unterauftragnehmer- und Drittlandprüfung.
  • Für das erwartete geringe V1-Volumen entsteht unnötige zusätzliche Anbieterbindung.

Variante D: Eigener Mailserver

  • Bietet hohe Kontrolle, verursacht aber unverhältnismässigen Aufwand für Betrieb, Sicherheit, Reputation, Spamabwehr und Zustellbarkeit.

Entscheidung

Hostpoint wird als bevorzugter E-Mail-Provider für V1 akzeptiert.

Es gelten folgende Regeln:

  • Produktive Plattformnachrichten werden über ein der Domain divelogix360.ch zugeordnetes Hostpoint-Postfach per authentifiziertem SMTP versendet.
  • Die Anwendung verwendet Port 587 mit STARTTLS und erzwingt die Prüfung des Serverzertifikats.
  • Die technische Konfiguration bleibt über generische SMTP-Umgebungsvariablen providerunabhängig.
  • noreply@divelogix360.ch dient als Versandadresse; die Anmeldung erfolgt mit genau diesem Benutzer und einer strikten Absenderrichtlinie.
  • bounces@divelogix360.ch dient als kontrollierte Rücklaufadresse. In V1 wird das Postfach mindestens betrieblich überwacht; automatisierte Bounce-Verarbeitung bleibt eine technische Folgeaufgabe.
  • SPF, DKIM und DMARC werden vor Produktivbetrieb eingerichtet und geprüft. DMARC beginnt kontrolliert mit Beobachtung und wird nach erfolgreicher Auswertung auf quarantine beziehungsweise reject verschärft.
  • Resend und ein selbst betriebener Mailserver bleiben für V1 ausgeschlossen.
  • Nachrichten enthalten nur die für ihren Zweck erforderlichen Daten. Passwörter, Wiederherstellungscodes, Access-Token, Refresh-Token und Vertragsdokumente werden nicht per E-Mail versendet.
  • Einmalige Einladungs-, Passwortzurücksetzungs- und Vertragslinks sind zulässig. Ihre Token sind kurzlebig oder fest befristet, einmalig, widerrufbar, serverseitig nur gehasht und von Anwendungs- sowie Versandprotokollen ausgeschlossen.
  • Entwicklungs- und Testversand ist vor der Produktivfreigabe nur an kontrollierte interne oder synthetische Adressen zulässig. Automatisierte Tests verwenden einen lokalen Mail-Catcher und keinen realen Provider.

Produktivsperre und noch erforderliche Nachweise

Der Fachentscheid erlaubt Konfiguration und Entwicklung, setzt Hostpoint im Providerregister aber noch nicht auf approved. Vor dem ersten Versand an reale Tenant-Admins, Mitarbeitende oder andere produktive Empfänger müssen folgende Nachweise vorliegen:

  1. Hostpoint bestätigt schriftlich, dass der automatisierte transaktionale Versand des extern betriebenen DiveLogix360-Backends im erwarteten Volumen zulässig ist.
  2. Versandgrenzen, Fair-Use-Regeln und Eskalationsweg sind dokumentiert.
  3. Eine Auftragsbearbeitungsvereinbarung ist abgeschlossen und geprüft.
  4. Primär-, Protokoll-, Backup-, Support- und Fernzugriffsstandorte sowie Unterauftragnehmer sind geprüft.
  5. Anbieterprotokolle, Nachrichtenpufferung, Aufbewahrung und Löschung entsprechen der Fristenmatrix; Abweichungen sind dokumentiert und freigegeben.
  6. SPF, DKIM, DMARC, STARTTLS, Absenderrichtlinie, Rücklaufpostfach und Zustellbarkeit sind technisch getestet.

Erst danach darf der Status des konkreten Hostpoint-Dienstes im Providerregister auf approved wechseln.

Transport vertraulicher Inhalte

  • Passwörter werden von der betroffenen Person ausschliesslich über die HTTPS-geschützte Anwendung gesetzt; gespeichert wird nur der Argon2id-Hash.
  • Wiederherstellungscodes werden einmalig in der authentifizierten Anwendung angezeigt und serverseitig nur gehasht gespeichert.
  • Vertragsdokumente werden im geschützten Portal über eine höchstens fünf Minuten gültige signierte URL bereitgestellt und niemals als E-Mail-Anhang versendet.
  • E-Mails transportieren nur einen sicheren einmaligen Link und die für das Erkennen des Vorgangs erforderlichen Informationen.

Konsequenzen

  • Die bestehende Nodemailer-Schnittstelle kann grundsätzlich beibehalten werden.
  • Konfiguration, Secret-Verwaltung, Zeitüberschreitungen, Wiederholungen und minimierte Versandprotokolle müssen produktionsfest ergänzt werden.
  • Unzustellbare Einladungen benötigen einen kontrollierten betrieblichen Ablauf; eine spätere Provider- oder Bounce-Automatisierung bleibt ohne Änderung der fachlichen Nachrichtenregeln möglich.
  • Ein Wechsel des Providers erfordert eine neue ADR-Bewertung und Aktualisierung des Providerregisters.

Umsetzungsstatus

Teil Status
Fachliche Providerwahl Umgesetzt
Generische Nodemailer-Schnittstelle Teilweise vorhanden
Hostpoint-Postfächer und Secrets Offen
Schriftliche Nutzungsbestätigung Offen – Produktivsperre
Auftragsbearbeitungsvereinbarung und Unterauftragnehmerprüfung Offen – Produktivsperre
SPF, DKIM, DMARC und Absenderrichtlinie Offen – Produktivsperre
Bounce-Überwachung Offen – Produktivsperre
Automatisierte Tests Offen

Quellen

Verwandte ADRs

  • ADR-011: Globale Benutzeridentität und E-Mail-Eindeutigkeit
  • ADR-013: Vertragsdokumente im privaten Objektspeicher
  • ADR-015: Auftragsverarbeitungsvertrag und Datenschutzrollen