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.

Diese Betriebsanleitung richtet sich an Workspace- und Mail-Administratoren. Sie führt vom tenantgebundenen Zugriffscheck bis zu einem prüfbaren Ein- und Ausgangstest. Am Ende verwaltet Workspace persönliche und gemeinsame Postfächer sowie Verteiler, während das Gateway weiterhin die öffentliche Mailzustellung übernimmt. 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:

bash

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:

bash

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

Legen Sie die gehostete Domain über POST /api/v1/mail/admin/domains an.
Legen Sie persönliche oder gemeinsame Postfächer über POST /api/v1/mail/admin/mailboxes an.
Ergänzen Sie Mitglieder gemeinsamer Postfächer über POST /api/v1/mail/admin/mailboxes/{id}/memberships.
Legen Sie Verteiler separat über POST /api/v1/mail/admin/distribution-lists an.
Setzen Sie storage.context.mail.store_id tenantbezogen auf den vorhandenen verschlüsselten Mail-Store.

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:

bash

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.

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.

Zimbra kontrolliert importieren

Legen Sie einen Storage-Store mit verschlüsselten IMAP-Zugangsdaten für Zimbra an. Starten Sie anschließend den Taskstream-Runnable mailbox.import.imap mit:

json

{
  "tenant_id": "<tenant-uuid>",
  "source_store_id": "<zimbra-source-store-uuid>",
  "target_store_id": "<mail-storage-store-uuid>",
  "recipient": "user@example.com"
}

Führen Sie zuerst einen Vollimport, danach einen Delta-Lauf und unmittelbar vor dem Gateway-Cutover einen letzten Delta-Lauf aus. Wiederholungen sind über Quell-Store, Quell-UID, Message-ID und Inhalts-Hash idempotent. Der Taskstream-Lauf meldet verarbeitete und übersprungene Nachrichten. Vergleichen Sie vor dem Cutover diese Mengen und testen Sie Ein- und Ausgang sowie einen DSN.

Ä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:

GET /api/v1/mail/mailboxes zeigt für die Testidentität nur die freigegebenen persönlichen und gemeinsamen Postfächer.
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.
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“.
Ein absichtlich erzeugter DSN wird vom getrennten Bounce-Router angenommen und dem gesendeten Thread zugeordnet.
Ein Mitglied eines gemeinsamen Postfachs sieht nur den freigegebenen Historienbereich und kann nur entsprechend seiner Rolle lesen oder senden.
Ein Verteiler stellt eine autorisierte Testmail an die konfigurierten Zielpostfächer zu, ohne einen gemeinsamen Arbeitszustand zu erzeugen.

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.