Mail mit einem SMTP-Gateway bereitstellen

Workspace übernimmt Postfächer und Webmail. Ein vorgeschaltetes Gateway wie Proxmox Mail Gateway bleibt die öffentliche SMTP-Kante und hält MX, PTR, Reputation, DKIM, Filter und die externe Queue.

Beginnen Sie mit dem tenantgebundenen Zugriffscheck und schließen Sie die Einrichtung mit einem prüfbaren Ein- und Ausgangstest ab. Workspace verwaltet danach persönliche und gemeinsame Postfächer sowie Verteiler; das Gateway übernimmt weiterhin die öffentliche Mailzustellung. Den technischen API-Vertrag beschreibt Mail-API und Gateway-Handoff.

Zugriff und Agentenablauf prüfen

Melden Sie sich mit nucli am betroffenen Tenant an. Prüfen Sie zuerst die Identität, die Mail-Berechtigungen und die erreichbaren Mail-Endpunkte:

nucli --tenant <tenant> whoami --scopes
nucli --tenant <tenant> api GET /api/v1/mail/mailboxes --summary
nucli --tenant <tenant> api GET /api/v1/mail/admin/domains --summary

Ein automatisierter Agent liest vor der Arbeit den eingebauten Mail-Ablauf:

nucli skills show mail

Der Skill verwendet ausschließlich tenantgebundene HTTP-Aufrufe. Er darf weder Datenbankzugriffe noch numin, Storage-Pfade oder Gateway-Zugriffe nutzen, um Authentisierung, Tenancy, Berechtigungen oder Mail-Verträge zu umgehen. Freigaben für Mailinhalte ergeben sich aus den Mailbox-Rollen und ResourceACL, nicht allein aus einer Tenant-Administratorrolle.

Postfächer vorbereiten

1. Legen Sie die gehostete Domain über POST /api/v1/mail/admin/domains an.
2. Legen Sie persönliche oder gemeinsame Postfächer über POST /api/v1/mail/admin/mailboxes an.
3. Ergänzen Sie Mitglieder gemeinsamer Postfächer über POST /api/v1/mail/admin/mailboxes/{id}/memberships.
4. Legen Sie Verteiler separat über POST /api/v1/mail/admin/distribution-lists an.
5. Setzen Sie storage.context.mail.store_id tenantbezogen auf den vorhandenen verschlüsselten Mail-Store.
6. Setzen Sie bei Bedarf eine logische Postfachgrenze über PUT /api/v1/mail/admin/mailboxes/{id}/quota. Der Wert 0 bedeutet unbegrenzt. Bei einem Postfach, das schon vor Einführung der Quoten bestand, gleichen Sie zuerst den belegten Speicher über POST /api/v1/mail/admin/mailboxes/{id}/quota/reconcile ab. Der Server lehnt eine positive Quote bis zu diesem ausdrücklich protokollierten Abgleich ab.

Verteiler vervielfachen die Zustellung an Zielpostfächer. Gemeinsame Postfächer teilen dagegen Arbeitszustand, Zuweisung und Absenderregeln.

Übergeben Sie schreibende API-Payloads als geschützte Dateien. So landen Adressen und Identitäts-IDs nicht in der Shell-Historie:

nucli --tenant <tenant> api POST /api/v1/mail/admin/domains \
  --input mail-domain.json --summary
nucli --tenant <tenant> api POST /api/v1/mail/admin/mailboxes \
  --input mailbox.json --summary
nucli --tenant <tenant> api POST \
  /api/v1/mail/admin/mailboxes/<mailbox-id>/memberships \
  --input membership.json --summary
nucli --tenant <tenant> api POST /api/v1/mail/admin/distribution-lists \
  --input distribution-list.json --summary

Verwenden Sie für Postfächer den Typ personal oder shared und für Mitgliedschaften die Rolle owner, editor oder viewer. Historischen Zugriff eines neuen Mitglieds geben Sie nur bewusst und auditiert über historyGrantedFromAt frei. Jede schreibende Änderung benötigt eine ausdrückliche Administratorfreigabe.

Privaten Handoff absichern

Aktivieren Sie mail.handoff.mailbox.enabled erst, wenn alle TLS-Werte gesetzt sind:

• mail.handoff.mailbox.bind_address: private oder Loopback-IP
• mail.handoff.mailbox.port: dedizierter interner Port
• mail.handoff.mailbox.tls.cert_file und mail.handoff.mailbox.tls.key_file
• mail.handoff.mailbox.tls.client_ca_file
• mail.handoff.mailbox.gateway_sha256: erlaubte SHA-256-Zertifikatsfingerprints

Der Listener verlangt TLS 1.3 und ein gültiges Clientzertifikat. PMG darf eine Nachricht erst nach erfolgreichem RCPT TO und dem abschließenden 250 stored aus seiner Queue entfernen. Normale Zustellung und DSNs verwenden getrennte Recipient-Router am privaten Handoff.

Versand und Bounces

Konfigurieren Sie die vorhandene tenantbezogene SMTP-Konfiguration ausschließlich auf das Gateway. Workspace stellt nicht direkt an fremde MX-Server zu. mail.outbound.bounce_domain muss auf die vom Gateway zurückgeroutete Bounce-Domain zeigen.

Wählen Sie für jeden neuen SMTP-Stand einen eindeutigen Authentifizierungsmodus:

Workspace handelt den Modus nicht automatisch aus und fällt nicht auf einen anderen Mechanismus zurück. Wenn ein alter SMTP-Stand noch keinen Modus enthält, legen Sie einen neuen Stand an, prüfen Sie die Verbindung und aktivieren Sie anschließend genau diesen Stand.

Mailpit verschlüsselt anbinden

Mailpit kann STARTTLS selbst bereitstellen und erzwingen. Hinterlegen Sie ein stabiles Serverzertifikat samt Schlüssel und aktivieren Sie die Pflicht für STARTTLS:

MP_SMTP_TLS_CERT=/certs/mailpit.crt
MP_SMTP_TLS_KEY=/certs/mailpit.key
MP_SMTP_REQUIRE_STARTTLS=true

Der im SMTP-Stand eingetragene Hostname muss im Zertifikat enthalten sein. Außerdem muss Workspace der ausstellenden Zertifizierungsstelle vertrauen. Konfigurieren Sie den SMTP-Stand mit authMode=none, encryption=starttls, leerem Benutzernamen und ohne Credential. Lassen Sie unsichere Zertifikatsausnahmen deaktiviert. Ein bei jedem Neustart neu erzeugtes selbstsigniertes Zertifikat eignet sich nicht für eine stabile Prüfung, weil sich damit auch der Vertrauensanker ändert.

Ein Proxy ist für diesen Aufbau nicht erforderlich. Falls die betriebliche PKI TLS zentral terminiert, muss der Proxy SMTP-STARTTLS gegenüber Workspace vollständig anbieten und ein dort vertrauenswürdiges Zertifikat ausliefern. Sichern Sie auch die Weiterleitung vom Proxy zu Mailpit mit geprüftem TLS ab. Ein reiner TCP-TLS-Terminator oder implizites TLS auf einer SMTPS-Verbindung ersetzt STARTTLS nicht und passt deshalb nicht zum Modus none.

Prüfen Sie nach der Einrichtung, dass Mailpit die Annahme von Nachrichten ohne STARTTLS ablehnt und der SMTP-Mitschnitt nach STARTTLS kein AUTH enthält. Die zugehörigen Mailpit-Optionen sind in der SMTP-Konfiguration von Mailpit dokumentiert.

Workspace speichert einen DSN verschlüsselt, übernimmt die Content-ACL der gesendeten Nachricht und zeigt die getrennten Queuezustände der Envelope-Empfänger im Thread an.

Bestehende Postfächer kontrolliert übertragen

Workspace verbindet sich für Migrationen nicht selbst mit Zimbra oder einem anderen IMAP-Server. Ein externer Adapter liest das Quellsystem und übergibt Ordner, unveränderte RFC822-Nachrichten, ursprüngliche Zeitpunkte und Flags an die providerneutrale Transfer-API. Zugangsdaten des Quellsystems bleiben damit außerhalb von Workspace.

Der Ablauf besteht aus einer Baseline und beliebig vielen Deltas:

1. Eine Transfersession an genau ein Zielpostfach binden.
2. Alle Quellordner einschließlich „Gesendet“ und eigener Unterordner anlegen.
3. Einen Batch mit erwarteten Mengen, Bytes und Manifest-Hashes deklarieren.
4. Jedes Element als streng geordnetes Multipart-Payload mit Metadaten und anschließendem message/rfc822-Stream übertragen. Löschmarker benötigen keinen Nachrichtenkörper.
5. Die Reconciliation starten und den Batchstatus bis ready abfragen.
6. Erst dann veröffentlichen. Der Vorgang ist idempotent; ein gleicher Quellschlüssel mit abweichendem Inhalt wird abgewiesen.

Importierte Ordner erscheinen in der Mail-Arbeitsfläche als schreibgeschützte Quellordner. Neue Mails kommen unabhängig davon über den privaten SMTP-Handoff in dasselbe Postfach.

Führen Sie vor dem Routingwechsel einen vollständigen Baseline-Lauf, einen Delta-Lauf und zuletzt ein weiteres Delta aus. Vergleichen Sie pro Ordner und für den gesamten Batch Anzahl, Bytes und Manifest-Hash. Ein berechtigter Rückweg verwendet POST /api/v1/mail/mailboxes/{mailboxID}/exports; der Exportjob liefert nach Abschluss einen vollständigen Snapshot oder ein Delta nach einer exakten Mailboxrevision. Die Zielsystemlogik bleibt Aufgabe des externen Adapters.

Ändern Sie MX, PTR, SPF, DKIM und DMARC in einem getrennt freigegebenen Betriebsschnitt. Workspace verändert diese externe Konfiguration nicht.

Bereitstellung prüfen

Die Bereitstellung ist abgeschlossen, wenn alle folgenden Prüfungen erfolgreich sind:

1. GET /api/v1/mail/mailboxes zeigt für die Testidentität nur die freigegebenen persönlichen und gemeinsamen Postfächer.
2. Eine Testmail an eine gehostete Adresse erhält am privaten Handoff erst nach dauerhafter Storage-Speicherung 250 stored und erscheint danach in der Mail-Workbench.
3. Eine freigegebene Testmail wechselt zunächst in den gespeicherten Zustand und in die Queue. Prüfen Sie anschließend den Status jedes Envelope-Empfängers; „queued“ bedeutet noch nicht „zugestellt“.
4. Bei none zeigt der SMTP-Mitschnitt des Gateways STARTTLS, aber kein AUTH. Prüfen Sie zusätzlich am Gateway, dass eine nicht freigegebene Quelladresse und eine unzulässige Absenderdomain abgewiesen werden.
5. Ein absichtlich erzeugter DSN wird vom getrennten Bounce-Router angenommen und dem gesendeten Thread zugeordnet.
6. Ein Mitglied eines gemeinsamen Postfachs sieht nur den freigegebenen Historienbereich und kann nur entsprechend seiner Rolle lesen oder senden.
7. Ein Verteiler stellt eine autorisierte Testmail an die konfigurierten Zielpostfächer zu, ohne einen gemeinsamen Arbeitszustand zu erzeugen.
8. Alle deklarierten Quellordner sind sichtbar; Reconciliation und Export sind abgeschlossen, und ein Hashvergleich des Exportartefakts ist erfolgreich.

Persönliche und gemeinsame Mail bearbeiten Nutzer anschließend wie unter Mail bearbeiten beschrieben.

Installation ohne PMG planen

Der Produktkern bindet sich nicht an PMG. Eine Installation ohne vorhandenes Gateway benötigt einen separat betriebenen Mail-Edge auf Basis bewährter MTA-Software. Dieser Edge übernimmt dieselben öffentlichen Aufgaben und nutzt denselben privaten mTLS-Handoff. Liefern Sie ihn erst nach einem eigenen Lizenz-, Security-, Update- und Betriebs-Gate aus; der Workspace-Server wird nicht zum öffentlichen MTA.