Kurzüberblick

Dieser Beitrag zeigt Schritt für Schritt, wie in grommunio ein Funktionspostfach als Alternative zu einer Public-Folder-Struktur aufgebaut wird. Getestet wurden zwei Domains innerhalb derselben Organisation, granulare MAPI-Ordnerrechte, Root- und Parent-Rechte mit foldervisible, grommunio-Web-Automount, Send-As und ein SMTP-Alias.

Wichtig: Der Artikel beschreibt den technisch belegten Stand aus dem Lab. Thunderbird wurde zusätzlich in einer isolierten X11-Testumgebung mit echten GUI-Screenshots geprüft. Outlook und automatische Inbox-Regeln sind als noch nicht vollständig verifiziert gekennzeichnet und werden nachgereicht, sobald diese Client-Tests reproduzierbar abgeschlossen sind.

Ausgangssituation und Zielbild

Im Test gibt es eine Organisation mit zwei Domains. Ein klassischer Public Folder aus Domain A ist nicht automatisch eine organisationsweite Ablage für Benutzer aus Domain B. Für gemeinsam genutzte Strukturen über Domain-Grenzen hinweg wurde deshalb ein normales Funktionspostfach verwendet.

markdown
Example Group
├── example-a.test
└── example-b.test


shared-folders@example-a.test
├── Finance
├── Sales
├── Projects
│   ├── Project-A
│   └── Project-B
└── Shared

Getestete Grundlage

Die Anleitung basiert auf einer isolierten grommunio Appliance 2026.06.1. Es wurden ausschließlich neutrale Testdaten verwendet. Produktive Kundendaten waren nicht beteiligt.

markdown
Organisation:        Example Group
Domains:             example-a.test, example-b.test
Benutzer:            alice@example-a.test, bob@example-b.test
Funktionspostfach:   shared-folders@example-a.test
SMTP-Alias:          finance@example-a.test
CLI-Version:         grommunio-admin 1.21.0+2
Werkzeuge:           grommunio-admin, gromox-mbop, jq, xxd, IMAP/SMTP-Testclient, Playwright, Thunderbird 153.0.2

Beispielwerte für den eigenen PoC ersetzen

Alle folgenden Werte sind neutrale Lab-Beispiele. Für einen Kunden-PoC müssen sie durch die eigenen Testdomains, Benutzer und das eigene Funktionspostfach ersetzt werden. Die Struktur der Befehle bleibt gleich, nur die konkreten Namen und die automatisch ermittelten Ordner-IDs ändern sich.

Voraussetzungen

Für den Nachbau brauchst du Administrationsrechte auf grommunio, Shell-Zugriff auf die Appliance, zwei Domains in derselben Organisation, mindestens zwei Testbenutzer und ein separates Funktionspostfach. In produktiven Umgebungen sollte der Test zuerst mit neutralen Konten durchgeführt werden.

Auf der Shell müssen mindestens diese Werkzeuge verfügbar sein: grommunio-admin für Benutzer, Domains und ACLs, gromox-mbop für Websettings, jq für JSON-Verarbeitung und xxd für den Websettings-Key des Shared Stores.

Schritt 1: Organisation, Domains und Benutzer prüfen

Zuerst wird geprüft, ob beide Domains derselben Organisation zugeordnet sind und die Testbenutzer existieren. Im Lab wurden Example Group, example-a.test und example-b.test verwendet.

bash
grommunio-admin org list
grommunio-admin domain list
grommunio-admin user list

Die Organisation muss beide Testdomains enthalten. Erst dann ist der Cross-Domain-Test innerhalb derselben Organisation aussagekräftig.

Die Domainliste zeigt example-a.test und example-b.test als aktive Domains der Organisation.

Die Benutzerliste zeigt Alice in example-a.test, Bob in example-b.test und das Funktionspostfach shared-folders@example-a.test. Der SMTP-Alias finance@example-a.test hängt am Funktionspostfach.

Schritt 2: Funktionspostfach anlegen

Das Funktionspostfach ist kein spezieller Public-Folder-Typ, sondern ein normales grommunio-Benutzerpostfach. Genau dadurch kann es eine eigene Ordnerstruktur, Aliasadressen und separate Send-As-Rechte bekommen.

bash
grommunio-admin user create shared-folders@example-a.test \
  --domain example-a.test \
  --lang de_DE \
  --pop3-imap true \
  --smtp true \
  --privWeb true


grommunio-admin passwd --password '<internes-testpasswort>' \
  shared-folders@example-a.test


grommunio-admin user modify shared-folders@example-a.test \
  --alias finance@example-a.test


grommunio-admin user show shared-folders@example-a.test

Im Lab war das Postfach danach vorhanden, hatte eine eigene Mailbox unter example-a.test und führte finance@example-a.test als Alias. Das Passwort ist absichtlich nicht veröffentlicht.

Schritt 3: Ordnerstruktur anlegen

Die Ordner wurden mit grommunio-admin exmdb im Store des Funktionspostfachs angelegt. Die Root-ID war im Lab 0x9. Die konkreten Ordner-IDs können in anderen Umgebungen abweichen und sollten immer per folder list oder folder find geprüft werden.

bash
grommunio-admin exmdb shared-folders@example-a.test folder create Finance 0x9
grommunio-admin exmdb shared-folders@example-a.test folder create Sales 0x9
grommunio-admin exmdb shared-folders@example-a.test folder create Projects 0x9
grommunio-admin exmdb shared-folders@example-a.test folder create Shared 0x9


grommunio-admin exmdb shared-folders@example-a.test folder find Finance 0x9
grommunio-admin exmdb shared-folders@example-a.test folder find Sales 0x9
grommunio-admin exmdb shared-folders@example-a.test folder find Projects 0x9
grommunio-admin exmdb shared-folders@example-a.test folder find Shared 0x9


# Beispiel aus dem Lab: Projects hatte danach die ID 0x1f0000.
grommunio-admin exmdb shared-folders@example-a.test folder create Project-A 0x1f0000
grommunio-admin exmdb shared-folders@example-a.test folder create Project-B 0x1f0000


grommunio-admin exmdb shared-folders@example-a.test folder list -r

Erwartetes Ergebnis: Finance, Sales, Projects, Shared sowie Project-A und Project-B unter Projects erscheinen im rekursiven Folder Listing.

Schritt 4: Folder visible und Arbeitsrechte setzen

foldervisible ist das Wegerecht durch die Ordnerhierarchie. Es macht einen Ordner im Baum sichtbar, gibt aber allein noch keinen inhaltlichen Lese- oder Schreibzugriff auf andere Ordner. Für verschachtelte Zielordner müssen Root und alle Parent-Ordner sichtbar sein.

markdown
Mailbox Root
└── foldervisible für Alice und Bob


Projects
└── foldervisible für Bob


Project-A
└── Arbeitsrechte für Bob


Project-B
└── keine Bob-Rechte

Im Lab wurden folgende Ordner-IDs verwendet: Root 0x9, Finance 0x1d0000, Sales 0x1e0000, Projects 0x1f0000, Project-A 0x210000 und Project-B 0x220000. In einer anderen Umgebung vorher die IDs neu ermitteln.

bash
# Root sichtbar machen, aber keine Inhalte auf Root freigeben.
grommunio-admin exmdb shared-folders@example-a.test folder grant \
  0x9 alice@example-a.test foldervisible


grommunio-admin exmdb shared-folders@example-a.test folder grant \
  0x9 bob@example-b.test foldervisible


# Alice darf Finance bearbeiten.
grommunio-admin exmdb shared-folders@example-a.test folder grant \
  0x1d0000 alice@example-a.test \
  readany create editowned deleteowned editany deleteany createsubfolder folderowner foldercontact foldervisible


# Bob darf Sales bearbeiten.
grommunio-admin exmdb shared-folders@example-a.test folder grant \
  0x1e0000 bob@example-b.test \
  readany create editowned deleteowned editany deleteany createsubfolder folderowner foldercontact foldervisible


# Bob darf den Parent Projects sehen.
grommunio-admin exmdb shared-folders@example-a.test folder grant \
  0x1f0000 bob@example-b.test foldervisible


# Bob darf Project-A bearbeiten, aber nicht Project-B.
grommunio-admin exmdb shared-folders@example-a.test folder grant \
  0x210000 bob@example-b.test \
  readany create editowned deleteowned editany deleteany foldervisible

Im Test wurden keine StoreOwner- oder Delegate-Rechte vergeben. Die Freigabe bleibt damit absichtlich auf Folder ACLs beschränkt.

Schritt 5: Rechte verifizieren

Nach dem Setzen der Rechte wurden Root, Finance, Sales, Projects, Project-A und Project-B einzeln geprüft. Wichtig ist der Negativtest: Ein Benutzer darf nicht nur den erwarteten Ordner sehen, sondern nicht berechtigte Ordner müssen ohne Rechte bleiben.

bash
grommunio-admin exmdb shared-folders@example-a.test folder permissions 0x9
grommunio-admin exmdb shared-folders@example-a.test folder permissions 0x1d0000
grommunio-admin exmdb shared-folders@example-a.test folder permissions 0x1e0000
grommunio-admin exmdb shared-folders@example-a.test folder permissions 0x1f0000
grommunio-admin exmdb shared-folders@example-a.test folder permissions 0x210000
grommunio-admin exmdb shared-folders@example-a.test folder permissions 0x220000


grommunio-admin user storeowner shared-folders@example-a.test list
grommunio-admin user delegates shared-folders@example-a.test list
markdown
Geprüfte Ergebnisse aus dem Lab:
Alice -> Finance: Zugriff gesetzt, PASS
Alice -> Sales: kein Zugriff gesetzt, PASS
Bob -> Sales: Zugriff gesetzt, PASS
Bob -> Finance: kein Zugriff gesetzt, PASS
Bob -> Projects: nur foldervisible, PASS
Bob -> Project-A: Zugriff gesetzt, PASS per CLI
Bob -> Project-B: kein Zugriff gesetzt, PASS
StoreOwner/Delegate: keine pauschalen Rechte, PASS

Schritt 6: grommunio Web automatisch einbinden

grommunio Web zeigt ein fremdes Postfach nicht allein wegen Folder ACLs automatisch im linken Ordnerbaum. Für den Webclient wurde deshalb das Funktionspostfach in den Websettings des jeweiligen Benutzers als shared_stores-Eintrag hinterlegt. In grommunio Web 5 liegt dieser Eintrag unter dem grommunio-Namespace; ältere oder migrierte Profile können noch zarafa-Einträge enthalten.

Das folgende Script ist die getestete robuste Variante. USER_A ist der Benutzer, der den Store sehen soll. USER_B ist das Funktionspostfach. Die Mailadresse des Funktionspostfachs wird hex-kodiert, weil grommunio Web den Shared-Store-Key in dieser Form speichert.

bash
#!/usr/bin/env bash
set -euo pipefail


usage() {
  printf 'Usage: %s <web-user-email> <shared-mailbox-email> [folder-type]\n' "$0" >&2
}


if [ "$#" -lt 2 ] || [ "$#" -gt 3 ]; then
  usage
  exit 64
fi


web_user=$1
shared_mailbox=$2
folder_type=${3:-all}


for cmd in gromox-mbop jq xxd grommunio-admin; do
  if ! command -v "$cmd" >/dev/null 2>&1; then
    printf 'ERROR: required command not found: %s\n' "$cmd" >&2
    exit 69
  fi
done


if ! grommunio-admin user show "$web_user" >/dev/null 2>&1; then
  printf 'ERROR: web user does not exist: %s\n' "$web_user" >&2
  exit 67
fi


if ! grommunio-admin user show "$shared_mailbox" >/dev/null 2>&1; then
  printf 'ERROR: shared mailbox does not exist: %s\n' "$shared_mailbox" >&2
  exit 67
fi


shared_id=$(printf '%s' "$shared_mailbox" | xxd -p -c 256)
settings=$(gromox-mbop -u "$web_user" get-websettings)


if [ -z "${settings//[[:space:]]/}" ]; then
  settings='{"settings":{"grommunio":{"v1":{"contexts":{"hierarchy":{}}}}}}'
fi


updated=$(printf '%s' "$settings" | jq --arg id "$shared_id" --arg folder_type "$folder_type" '
  .settings //= {}
  | .settings.grommunio //= {}
  | .settings.grommunio.v1 //= {}
  | .settings.grommunio.v1.contexts //= {}
  | .settings.grommunio.v1.contexts.hierarchy //= {}
  | .settings.grommunio.v1.contexts.hierarchy.shared_stores =
    (if (.settings.grommunio.v1.contexts.hierarchy.shared_stores | type) == "object"
     then .settings.grommunio.v1.contexts.hierarchy.shared_stores
     else {}
     end)
  | .settings.grommunio.v1.contexts.hierarchy.shared_stores[$id] = {
      "all": {
        "folder_type": $folder_type,
        "show_subfolders": true
      }
    }
')


printf '%s' "$updated" | gromox-mbop -u "$web_user" set-websettings >/dev/null
printf 'OK: %s now has shared store %s (%s)\n' "$web_user" "$shared_mailbox" "$shared_id"

Das Script überschreibt keine anderen Einstellungen, initialisiert fehlende Hierarchie-Objekte und ist idempotent. Im Lab wurde es für Alice und Bob jeweils zweimal ausgeführt; es entstanden keine Duplikate.

bash
./grommunio-web-automount-shared-store.sh \
  alice@example-a.test \
  shared-folders@example-a.test


./grommunio-web-automount-shared-store.sh \
  bob@example-b.test \
  shared-folders@example-a.test


gromox-mbop -u alice@example-a.test get-websettings | \
  jq '.settings.grommunio.v1.contexts.hierarchy.shared_stores'


gromox-mbop -u bob@example-b.test get-websettings | \
  jq '.settings.grommunio.v1.contexts.hierarchy.shared_stores'

Schritt 7: grommunio Web testen

Nach dem Websettings-Eintrag muss der Benutzer abgemeldet und neu angemeldet werden. Danach wird nicht nur geprüft, ob das Funktionspostfach sichtbar ist, sondern auch, ob die Rechte je Benutzer unterschiedlich greifen.

Alice aus example-a.test sieht das eingebundene Funktionspostfach shared-folders@example-a.test und den berechtigten Ordner Finance. Sales ist für Alice nicht freigegeben.

Bob aus example-b.test sieht ebenfalls shared-folders@example-a.test, aber mit Bob-spezifischer Sicht auf Sales und Projects. Finance bleibt für Bob verborgen. Außerdem sieht Bob den eigenen Public-Folder-Store aus example-b.test und nicht den Public-Folder-Store aus example-a.test.

Die ACL für Project-A ist per CLI belegt. Im Headless-Weblauf wurde die verschachtelte Project-A-Sicht jedoch nicht als sichtbarer PASS gewertet, weil der Ordnerbaum nicht reproduzierbar aufgeklappt wurde. Dieser Teil bleibt deshalb ehrlich als Web-Detailprüfung offen.

Schritt 8: Send-As getrennt von Ordnerrechten setzen

Folder ACLs und Send-As sind zwei unterschiedliche Dinge. Alice kann einen Ordner lesen oder bearbeiten, ohne automatisch als shared-folders@example-a.test senden zu dürfen. Send-As wurde daher separat vergeben und anschließend per SMTP getestet.

bash
grommunio-admin user sendas shared-folders@example-a.test add alice@example-a.test
grommunio-admin user sendas shared-folders@example-a.test list

Der Mailflow-Test von Alice mit From: shared-folders@example-a.test an Bob war erfolgreich. Damit ist Send-As für den getesteten internen Pfad belegt.

Schritt 9: SMTP-Alias prüfen

Der Alias finance@example-a.test wurde am Funktionspostfach gesetzt. Die Zustellung an diesen Alias erreichte im Lab die Shared Mailbox. Damit ist der Alias selbst geprüft.

bash
grommunio-admin user modify shared-folders@example-a.test \
  --alias finance@example-a.test


grommunio-admin user show shared-folders@example-a.test

Eine automatische Regel, die Nachrichten an finance@example-a.test serverseitig nach Finance verschiebt, wurde in diesem Lauf noch nicht als PASS gewertet. Die Zustellung an den Alias ist bestätigt, die Inbox-Rule-Konfiguration wird nachgereicht.

Schritt 10: Thunderbird mit separatem Testprofil prüfen

Thunderbird wurde zusätzlich in einer isolierten Fedora-44-X11-Testumgebung mit Xvfb, openbox und scrot geprüft. Verwendet wurde Thunderbird 153.0.2 aus Fedora Updates. Das Profil war neu und enthielt ausschließlich neutrale Lab-Konten.

Der Versionsdialog belegt die getestete Thunderbird-Version. Die Screenshots stammen aus der isolierten X11-Testumgebung, nicht aus einem persönlichen Desktop-Profil.

Die Kontoeinrichtung wurde mit neutralen Daten geprüft. Passwörter wurden nur intern aus den Lab-Secret-Dateien in die laufende Testsession eingegeben und erscheinen nicht im Artikel.

Alice wurde per IMAP angebunden. Der Screenshot zeigt eine neutrale Testnachricht, die zuvor in die grommunio-Lab-Mailbox geschrieben wurde. Damit ist sichtbar belegt, dass Thunderbird gegen die Lab-Umgebung arbeitet.

Das Funktionspostfach shared-folders@example-a.test wurde als separates IMAP-Konto eingebunden. Wichtig: Das ist kein delegiertes Exchange-/MAPI-Shared-Mailbox-Modell, sondern ein eigenes Konto mit eigenen Credentials. Damit werden Finance, Sales, Projects, Project-A, Project-B und Shared sichtbar.

Der Finance-Ordner enthält eine neutrale Testnachricht aus dem Lab. Dieser Pfad wurde als Thunderbird IMAP Shared Mailbox PASS WITH CONDITIONS bewertet, weil das Konto separat eingebunden wird.

Auch der verschachtelte Ordner Project-A wurde im separaten IMAP-Konto sichtbar geöffnet. Damit ist die Ordnerstruktur des Funktionspostfachs in Thunderbird praktisch nachvollziehbar.

Thunderbird 153.0.2 bietet im manuellen Einrichtungsdialog außerdem EWS als Protokoll an. Der direkte EWS-Protokolltest gegen grommunio war erfolgreich. Der vollständige Thunderbird-EWS-GUI-Abschluss wurde in diesem Lauf jedoch nicht als PASS gewertet, weil die GUI im Lab an der Zertifikatsausnahme beziehungsweise dem manuellen Lab-Endpunkt stehen blieb.

Der Protokoll-Dropdown zeigt EWS als native Option. Für den Artikel zählt das als sichtbarer Nachweis der verfügbaren Thunderbird-GUI-Option, nicht als erfolgreicher EWS-Accountabschluss.

Mit dem vollständigen grommunio-EWS-Endpunkt erreichte Thunderbird den nächsten Schritt. Der direkte Protokolltest hatte denselben Endpunkt zuvor erfolgreich verwendet.

Der GUI-Test erreichte die Zertifikatsprüfung des Lab-Endpunkts. Deshalb bleibt Thunderbird EWS im Artikel als PASS WITH CONDITIONS beziehungsweise als noch nicht vollständig abgeschlossener GUI-Pfad markiert. Delegierter EWS-Zugriff auf das Funktionspostfach wurde weiterhin nicht als PASS gewertet.

markdown
Thunderbird IMAP Alice: PASS
Thunderbird IMAP Funktionspostfach als separates Konto: PASS WITH CONDITIONS
Thunderbird EWS-Protokoll direkt gegen grommunio: PASS
Thunderbird EWS-GUI normaler Account: PASS WITH CONDITIONS
Thunderbird EWS delegierte Shared Mailbox: NOT PASSED
Sichtbare Thunderbird-GUI-Screenshots: PASS
Outlook unter Windows: NOT TESTED

Für klassisches Outlook bleibt der geplante produktionsnahe Prüfpfad: Konto öffnen, Weitere Einstellungen, Erweitert, zusätzliches Postfach hinzufügen, shared-folders@example-a.test auswählen, Outlook neu starten und die sichtbaren Ordner sowie Negativtests prüfen. Dieser Outlook-Teil wird nicht als getestet dargestellt.

Public Folder vs. Funktionspostfach

Der Public-Folder-Test zeigte getrennte Public-Folder-Stores pro Domain. example-a.test enthielt Example-A-Public, example-b.test hatte einen eigenen leeren Public-Folder-Store. Cross-Domain-ACLs ließen sich per CLI setzen, aber das ersetzt keinen vollständigen Clientnachweis für organisationsweite Public-Folder-Nutzung.

markdown
Public Folder:
- domainbezogener Public-Folder-Store
- Clientverhalten je Domain gesondert prüfen
- kein automatisch belegter organisationsweiter Ersatz über mehrere Domains


Funktionspostfach:
- normales Postfach mit eigener Ordnerstruktur
- Cross-Domain-Folder-ACL innerhalb derselben Organisation getestet
- grommunio Web sichtbar per Websettings-Automount
- Send-As und SMTP-Aliase separat steuerbar

Migrationslogik von Public Folder zu Funktionspostfach

Eine produktive Migration wurde in diesem Lauf nicht durchgeführt. Praktisch ableitbar ist aber der notwendige Ablauf: Struktur aufnehmen, Zielordner im Funktionspostfach anlegen, Nachrichten/Kalender/Kontakte/Anhänge migrieren, ACLs mappen, SMTP-Adressen und Send-As getrennt nachziehen und danach jeden Clienttyp testen.

markdown
Vor Migration aufnehmen:
- Ordnerhierarchie
- Folder Types: Mail, Kalender, Kontakte, Aufgaben
- vorhandene ACLs
- Mailadressen und Aliase
- Send-As-Anforderungen
- Regeln
- genutzte Clients: grommunio Web, Outlook, Thunderbird, Mobile
- Negativtests: wer darf was bewusst nicht sehen?

Troubleshooting

Shared Store erscheint in Web nicht: Websettings prüfen, Benutzer neu anmelden und sicherstellen, dass shared_stores ein Objekt ist.

bash
gromox-mbop -u alice@example-a.test get-websettings | \
  jq '.settings.grommunio.v1.contexts.hierarchy.shared_stores'

Benutzer sieht Unterordner nicht: Root foldervisible, alle Parent-Folder und die Zielordner-ACL prüfen. foldervisible auf Projects reicht nicht für den Inhalt von Project-A.

Benutzer sieht zu viel: Default-Rechte, anonymous-Rechte, Gruppenmitgliedschaften, rekursive Grants und versehentliche StoreOwner-/Delegate-Rechte prüfen.

Send-As schlägt fehl: Send-As separat kontrollieren, Absender im Client neu auswählen und nach Rechteänderungen die Sitzung neu starten.

Checkliste für den eigenen PoC

Der serverseitige PoC ist erst aussagekräftig, wenn nicht nur die erlaubten Zugriffe funktionieren, sondern auch die bewusst verweigerten Zugriffe geprüft wurden. Die folgende Liste kann direkt als Abnahmeprotokoll verwendet werden.

markdown
- [ ] Beide Testdomains gehören derselben grommunio-Organisation an.
- [ ] Ein zentrales Funktionspostfach wurde angelegt.
- [ ] Die gewünschte Ordnerstruktur wurde erstellt.
- [ ] Benutzer A stammt aus Domain A.
- [ ] Benutzer B stammt aus Domain B.
- [ ] Root- und Parent-Ordner besitzen nur die benötigte Sichtbarkeit.
- [ ] Zielordner besitzen die gewünschte Folder ACL.
- [ ] Benutzer A kann den freigegebenen Ordner öffnen.
- [ ] Benutzer A kann einen nicht freigegebenen Ordner nicht öffnen.
- [ ] Benutzer B kann domainübergreifend den freigegebenen Ordner öffnen.
- [ ] Benutzer B kann einen nicht freigegebenen Ordner nicht öffnen.
- [ ] Das Funktionspostfach erscheint in grommunio Web.
- [ ] Bestehende Websettings wurden durch den Automount nicht überschrieben.
- [ ] Send-As wurde separat vergeben und getestet, falls benötigt.
- [ ] Nicht vollständig getestete Clientpfade sind separat markiert.

PASS-/FAIL-Kriterien für die Kundenabnahme

PASS bedeutet in diesem Artikel: Der jeweilige Schritt wurde praktisch ausgeführt und das erwartete Ergebnis war sichtbar oder per CLI nachweisbar. FAIL bedeutet: Der Schritt wurde ausgeführt, aber das erwartete Ergebnis blieb aus oder ein Benutzer sah mehr beziehungsweise weniger als vorgesehen. NOT TESTED bedeutet: Der Punkt wurde in diesem Lauf nicht abschließend geprüft und darf nicht als bestanden übernommen werden.

Ergebniskontrolle

Die folgende Ergebniskontrolle trennt bestätigte Lab-Ergebnisse von noch offenen Client-Tests. PASS bedeutet hier, dass der jeweilige Punkt in dieser Testumgebung praktisch ausgeführt wurde.

markdown
Prüfbereich                         Prüfung                                      Ergebnis
Shared Mailbox                       Ordnerstruktur angelegt                     PASS
ACL                                  Cross-Domain-Benutzer berechtigt            PASS
ACL                                  Root/Parent foldervisible gesetzt           PASS
ACL                                  Nicht berechtigte Ordner ohne Rechte        PASS
grommunio Web                        Automount bei Alice und Bob sichtbar        PASS
Script                               Idempotenz und leere Websettings            PASS
Mailflow                             Send-As                                     PASS
Mailflow                             SMTP-Alias-Zustellung                       PASS
Public Folder                        Domain-Store-Vergleich                      PASS WITH CONDITIONS
Thunderbird                          Separates IMAP-Konto                        PASS WITH CONDITIONS
Thunderbird                          GUI-Screenshots IMAP                         PASS
Thunderbird                          EWS-Protokoll direkt                         PASS
Thunderbird                          EWS-GUI normaler Account                     PASS WITH CONDITIONS
Thunderbird                          EWS delegierte Shared Mailbox                NOT PASSED
Outlook                              Manuelles Einbinden                         NOT TESTED
Inbox Rule                           Alias automatisch nach Finance verschieben  NOT TESTED

Was noch nachgereicht wird

Die grundlegende Architektur, Cross-Domain-Berechtigungen, Folder ACLs, foldervisible, grommunio-Web-Automount, Send-As, Alias-Zustellung und Thunderbird per separatem IMAP-Konto sind praktisch getestet. Noch ausstehend sind der vollständige Outlook-Test unter Windows, der vollständige Thunderbird-EWS-Delegationspfad und der finale Inbox-Rule-Test.

Fazit

Für gemeinsam genutzte Ordner über mehrere Domains innerhalb einer grommunio-Organisation ist ein Funktionspostfach ein nachvollziehbarer und gut prüfbarer Ansatz. Entscheidend ist, keine pauschalen Full-Access-Rechte zu vergeben, sondern Root-/Parent-Sichtbarkeit, Zielordnerrechte, Send-As und Aliase getrennt zu behandeln.