Goooy Administratorhandbuch

Alles, was eine Administratorin oder ein Administrator braucht, um Goooy auszuführen, abzusichern und zu betreiben: Ihre selbstgehostete Alternative zu Microsoft Exchange / Office 365.

Goooy ist eine vollständige Groupware-Suite, die Sie selbst hosten: E-Mail, Kalender, Kontakte, Aufgaben, Notizen, Chat, Dateien, Videobesprechungen, kollaboratives Office und eine Admin-Konsole, alles aus einer Anwendung, einem Datenmodell und einem Helm-Chart. Ihnen gehören die Server, die Daten und die Schlüssel.

Dieses Handbuch richtet sich an die Personen, die Goooy betreiben. Für die technischen Grundlagen der Plattform (die Architektur, die Bereitstellung mit Helm oder Docker Compose und die Konfigurationsgrundlagen), siehe das Entwicklerhandbuch. Für die Sicht der Endnutzer auf die Apps siehe das Benutzerhandbuch. Für tiefe technische Details enthält der docs/-Ordner eigene Referenzen (Architektur, Sicherheit, Mailserver, Mandantenfähigkeit, Deployment, Migration und die nativen Client-Protokolle).

Inhalt

• Die Admin-Konsole
• Organisationen, Domains & Nutzer
• Authentifizierung & Zugriffsrichtlinie
• Der Mailserver
• Native Clients & Geräteverwaltung
• Migration von einem anderen System
• Mandantenfähigkeit & Isolation
• Sicherheit & Compliance
• Backups & Betrieb
• Self-Service-Anmeldung & Ihre Marketing-Präsenz

Die Admin-Konsole

Melden Sie sich als Admin an, und Sie erhalten einen RBAC-geschützten Admin-Bereich (die REST-Schnittstelle ist /api/v1/admin, beschränkt auf SYSADMIN / ORGADMIN und nach Organisation eingegrenzt). Von dort aus können Sie:

• Organisationen, Domains, Nutzer und Gruppen verwalten (erstellen, bearbeiten, löschen).
• ein Statistik-Dashboard zur Plattform-/Organisationsnutzung ansehen.
• Mobile Device Management betreiben: registrierte Geräte auflisten und Remote-Löschungen anfordern.
• ein Verzeichnis anbinden: Nutzer per Massenimport einspielen und aus LDAP synchronisieren.
• organisationsspezifisches SSO und Sicherheitsrichtlinien konfigurieren (2FA-Pflicht, SSO-Erzwingung).
• den Domain-Besitz über DNS-TXT-Einträge verifizieren.
• Migrationen aus anderen Mailsystemen ausführen (Admin ▸ Migrationen).

Organisationen, Domains & Nutzer

Das Mandanten-Rückgrat von Goooy ist Organization → Domain → User. Jeder Nutzer besitzt ein Postfach mit einem typisierten Ordnerbaum (E-Mail, Kalender, Kontakte, Aufgaben, Notizen, Dateien), sodass ein einziges Speicher- und Berechtigungsmodell jeder App zugrunde liegt. Das Löschen einer Organisation, eines Nutzers oder eines Postfachs kaskadiert sauber auf alles darunter.

Rollen (RBAC)

ORGADMIN-Aktionen werden automatisch auf ihre orgId eingegrenzt; ein ORGADMIN kann keine Organisationen erstellen oder SYSADMIN vergeben. Jede mandantenübergreifende Abfrage filtert nach der Organisation des Aufrufers, sodass Mandanten niemals die Daten der anderen sehen.

Nutzer hinzufügen

Erstellen Sie Nutzer einzeln in der Konsole, spielen Sie sie per Massenimport ein oder synchronisieren Sie aus LDAP mit ldapts. Jeder neue Nutzer wird automatisch mit einem Postfach und dem Standard-Ordnerbaum bereitgestellt. Passwörter folgen Ihrer Richtlinie (siehe unten).

Verifizierung des Domain-Besitzes

Bevor eine Domain echte E-Mails verarbeitet, kann eine Administratorin oder ein Administrator die Kontrolle darüber auf dieselbe Weise nachweisen wie Google Workspace und Microsoft 365:

1. Die Konsole zeigt einen zu veröffentlichenden TXT-Eintrag an (_goooy-verify.<domain> mit einem stabilen Token-Wert).
2. Veröffentlichen Sie ihn in Ihrem DNS.
3. Klicken Sie auf Jetzt verifizieren. Goooy führt eine Live-DNS-Abfrage durch und markiert die Domain als verifiziert.

Dies ist organisationsbezogen und auditiert; ein ORGADMIN kann nur die Domains der eigenen Organisation verifizieren.

Authentifizierung & Zugriffsrichtlinie

Goooy unterstützt das gesamte Spektrum moderner Zugriffskontrollen. Die Standardeinstellungen sind sicher; verschärfen Sie sie bei Bedarf pro Organisation.

Passwörter

• Gehasht mit bcrypt (Cost 12), dieselben Hashes, die Dovecot verifiziert, sodass es einen einzigen Anmeldedaten-Speicher über Webmail und natives IMAP/POP3 hinweg gibt.
• Bei jedem Setzen/Ändern/Zurücksetzen/Registrieren wird eine Passwortrichtlinie durchgesetzt: eine Mindestlänge (PASSWORD_MIN_LENGTH, Standard 10) und eine optionale Have I Been Pwned-Leak-Prüfung (k-Anonymität: es verlässt nur ein SHA-1-Präfix den Server, und sie ist fail-open, sodass ein HIBP-Ausfall eine Passwortänderung nie blockiert).
• Das Self-Service-Zurücksetzen des Passworts ist enumerationssicher und widerruft bei Nutzung alle anderen Sitzungen.

Multi-Faktor-Authentifizierung

• TOTP-Authenticator-Codes mit einmaligen Wiederherstellungscodes sowie FIDO2/WebAuthn-Passkeys (mit Klon-Erkennung).
• Setzen Sie Organization.requireMfa, um 2FA für eine Organisation vorzuschreiben. Nutzer werden durch die Einrichtung geführt und von der App ausgeschlossen, bis sie sie abgeschlossen haben.

Schutz vor Brute-Force & Kontoübernahme

• Zwei Schichten der Drosselung: eine Ratenbegrenzung pro IP an den Login-/MFA-Endpunkten und eine Kontosperre pro Konto (nach einer Schwelle fehlgeschlagener Versuche sperrt sich das Konto für ein exponentiell wachsendes Zeitfenster), die verteiltes Credential-Stuffing vereitelt.
• Login-Audit: Jeder Versuch wird aufgezeichnet (IP, User-Agent, Ergebnis), und Nutzer können ihre letzten Anmeldungen unter Einstellungen → Sicherheit einsehen.
• Warnungen bei neuen Geräten: Meldet sich ein Gerät zum ersten Mal an, erhält das Konto eine „Neue Anmeldung”-E-Mail; auch Passwort- und MFA-Änderungen benachrichtigen den Nutzer (gesteuert durch SECURITY_EMAILS_ENABLED).

Single Sign-on (organisationsspezifisches OIDC)

Konfigurieren Sie pro Organisation eine generische OIDC-Verbindung (Authorization-Code-Flow). Die Organisation wird aus der E-Mail-Domain des Nutzers ermittelt (Home-Realm-Discovery), Nutzer werden just-in-time bereitgestellt, wenn ihre Domain gehostet wird, und das Client-Secret ist write-only (im Ruhezustand versiegelt, nie zurückgegeben).

Sie können SSO erzwingen für eine Organisation (ssoEnforced), um die Passwort-Anmeldung vollständig zu deaktivieren, mit zwei Sicherheitsvorkehrungen, damit Sie sich nicht selbst aussperren: Es wird nur wirksam, solange eine nutzbare SSO-Verbindung besteht, und SYSADMIN-Konten behalten die Passwort-Anmeldung stets als Notzugang (Break-Glass).

Siehe Self-Service-Onboarding & externe Authentifizierung für die vollständige Auth-API und Sicherheit für die tiefgehende Referenz.

Der Mailserver

Standardmäßig ist Goooy eigenständig: Es nimmt eingehende E-Mails über seine eigenen SMTP- (2525) und LMTP- (2526) Listener an, leitet ausgehende über nodemailer weiter, bewertet Spam mit einer integrierten regelbasierten Heuristik und stellt lokal zwischen gehosteten Nutzern zu, sodass interne E-Mail ganz ohne externe Infrastruktur funktioniert.

Für echte Internet-E-Mail aktivieren Sie den Postfix + Dovecot + Rspamd-Stack, und die API wird zum Zustellungs-Hub eines vollständigen Mailservers:

helm upgrade goooy ./deploy/helm/goooy --set mail.enabled=true

Internet ─SMTP:25─▶ Postfix ──milter──▶ Rspamd ──LMTP──▶ api ─┬─▶ Postgres (web UI; spam→Junk)
 clients ─587/465─▶  (MTA, SASL)        (scan+DKIM)           └─▶ Dovecot ─▶ Maildir (IMAP/POP3)

• Postfix nimmt E-Mails für Ihre gehosteten Domains an (live in Postgres nachgeschlagen), scannt über den Rspamd-Milter (SPF/DKIM/DMARC + Spam-Bewertung) und stellt über LMTP an die API zu.
• Die API schreibt die Nachricht nach Postgres (den Webmail-Speicher und legt von Rspamd markierten Spam in Junk ab) und spiegelt sie in Dovecot, damit native IMAP/POP3-Clients sie sehen.
• Ausgehende E-Mails werden zurück über Postfix geleitet, von Rspamd DKIM-signiert.

Anti-Phishing ist integriert: Ergebnisse der Absender-Authentifizierung eingehender E-Mails werden pro Nachricht gespeichert; ein Banner für externe Absender kennzeichnet E-Mails von außerhalb Ihrer Domains; Spoofs der eigenen Domain, die nicht authentifiziert sind, werden mit einer deutlichen Warnung in Junk abgelegt; die Aktionen „Melden” / „Kein Junk” der Nutzer trainieren den Bayes-Filter von Rspamd; und der Reader warnt vor täuschenden Links, Homograph-/Punycode-Hosts und Anzeigename-Identitätsmissbrauch, wobei externe Inhalte standardmäßig blockiert und über einen Proxy geleitet werden.

Sichere Links & Anlagen-Sandboxing. Zwei weitere Schutzmechanismen für eingehende Mail lassen sich pro Organisation unter Admin ▸ Mail-Sicherheit aktivieren (beide standardmäßig aus):

• Sichere Links schreibt jeden Link in eingehender externer Mail um und prüft das Ziel beim Anklicken erneut: URLs auf der Sperrliste erhalten eine Sperrseite, verdächtige (IP-Adressen als Host, eingebettete Zugangsdaten, Punycode-Doppelgänger) eine Warnseite, saubere werden direkt weitergeleitet: jeder Klick wird protokolliert. Gesendete Kopien, interne Mail sowie signierte oder verschlüsselte Nachrichten bleiben unangetastet.
• Anlagen-Sandboxing analysiert eingehende Anhänge statisch, zusätzlich zum immer aktiven Virenscan: anhand des Inhalts erkannte ausführbare Dateien, Office-Makroprojekte, passwortgeschützte und verschachtelte Archive sowie skriptbehaftetes HTML/SVG. Bösartige Mail wird in Junk abgelegt, und jeder markierte Anhang wird unter Quarantäne gestellt (Download gesperrt), bis ein Organisations-Admin ihn freigibt.

Betriebliche Vorsicht: Setzen Sie niemals permit_mynetworks auf einen ins Internet exponierten SMTP-Listener. Das erzeugt ein Open Relay. Die ausgelieferten Konfigurationen trennen genau aus diesem Grund den öffentlichen :25-Port von einem rein internen Submission-Port. Vollständige Details und Grenzen stehen in Mailserver und deploy/mail/README.md.

Native Clients & Geräteverwaltung

Goooy spricht die Standardprotokolle, sodass Ihre Nutzer die Apps behalten, die sie bereits haben. Alle sind an ihren bekannten Roots eingehängt und verwenden HTTP Basic (E-Mail + Passwort), wo das Protokoll es erwartet:

Mobile Outlook-App: Die iOS/Android-Outlook-App benötigt EAS im OAuth-Stil, das Goooy nicht anbietet; raten Sie iPhone-/iPad-Nutzern, stattdessen die integrierte Apple Mail-App zu verwenden.

Mobile Device Management. Geräte, die sich über ActiveSync registrieren, werden erfasst. In der MDM-Konsole können Sie registrierte Geräte auflisten und eine Remote-Löschung anfordern. Das Gerät wird markiert und bei seiner nächsten Synchronisierung gelöscht.

Der Helpdesk

Ein Helpdesk ist eine Workflow-Schicht über einem gemeinsamen Postfach, kein eigenes System. Legen Sie zuerst das gemeinsame Postfach an, teilen Sie es mit den Bearbeitenden und aktivieren Sie darauf unter Admin ▸ Helpdesk den Helpdesk.

• Bearbeitende sind genau die Personen, mit denen das Postfach geteilt ist. Wer nur Lesezugriff hat, kann Tickets öffnen, aber nicht zuweisen, antworten oder den Status ändern.
• Warteschlangen-Einstellungen enthalten das Präfix des Ticketschlüssels (TCK), die Geschäftszeiten, die Ziele für Erstantwort und Lösung in Geschäftsminuten, die Auto-Schließfrist und die Eingangsbestätigung an neue Absender.
• Textbausteine gelten für eine Warteschlange oder organisationsweit.
• KI-Triage ist je Warteschlange optional. Sie schlägt Priorität und Schlagworte vor und verschickt nie von sich aus etwas.

Die Mailzustellung bleibt unberührt: Jede Nachricht landet weiterhin im Posteingang des Postfachs und bleibt über IMAP, ActiveSync, MAPI und JMAP sichtbar. Schalten Sie den Helpdesk ab, bleiben Postfach und Mail exakt so, wie sie waren.

Mail-Authentifizierung & Berichte

SPF, DKIM und DMARC zu veröffentlichen ist Schritt eins; zu wissen, ob sie wirken, ist Schritt zwei. Richten Sie die rua=-Adresse in Ihrem DMARC-Eintrag auf ein Postfach der Domain, und Goooy wertet jeden Aggregatbericht bei der Zustellung aus.

Admin ▸ Mail-Authentifizierung zeigt dann je Domain: die Zustellquote, die SPF- und DKIM-Ausrichtung und die sendenden Quellen, die scheitern. Genau daran erkennen Sie den vergessenen legitimen Absender im Unterschied zu jemandem, der Sie fälscht. SMTP-TLS-Berichte (TLS-RPT) kommen auf demselben Weg und zeigen gescheiterte oder herabgestufte Verbindungen.

Goooy kann außerdem je Domain eine MTA-STS-Richtlinie unter /.well-known/mta-sts.txt hosten, damit andere Anbieter Ihre Mail nicht über eine unverschlüsselte Verbindung übergeben.

Provisionierung mit SCIM und LDAP

Drei Wege, Konten mit Ihrem Verzeichnis im Gleichklang zu halten:

• SCIM 2.0 unter /scim/v2, authentifiziert mit einem Bearer-Token je Organisation. Ihr Identity Provider legt Nutzer und Gruppen an, aktualisiert und deaktiviert sie, wenn Menschen kommen, wechseln und gehen.
• LDAP-/Active-Directory-Synchronisation holt Nutzer und Gruppen planmäßig.
• CSV-Massenimport für eine einmalige Ladung.

Kombinieren Sie das mit SSO je Organisation, damit eine zentrale Sperrung den Zugang überall entzieht, native Clients eingeschlossen.

Migration von einem anderen System

Der Goooy Mover überträgt die Daten eines bestehenden Unternehmens nach Goooy – von einem Live-IMAP-Server oder aus hochgeladenen Exportdateien: Eine Administratorin oder ein Administrator ordnet jedes Quellpostfach einem Goooy-Nutzer zu (fehlende Nutzer werden automatisch bereitgestellt), klickt auf Start, und die Übertragung läuft im Hintergrund mit einer Live-Statusanzeige pro Nutzer. Die Admin-Oberfläche ist Admin ▸ Migrationen.

Was es bewahrt und garantiert:

• Ordnerhierarchie: Bekannte Ordner (Posteingang, Gesendet, Papierkorb, Junk, Archiv) werden ihren Goooy-Rollen zugeordnet; tiefere Ordner werden als untergeordnete Ordner neu angelegt.
• Datum und Status: ursprüngliche Empfangsdaten und Gelesen-/Kennzeichnungsstatus, sodass ein migriertes Postfach wie das Original aussieht.
• Fortsetzbar & idempotent: Es sichert den Fortschritt per Checkpoint, sodass ein Abbruch der API mitten im Batch dort fortsetzt, wo er aufgehört hat, und ein erneuter Lauf nie Duplikate erzeugt (Deduplizierung per Message-ID, oder per UID für Kalender/Kontakte).

Der Live-Server-Weg funktioniert mit Gmail, Microsoft 365, Dovecot, Zimbra und den meisten IMAP-Servern (verwenden Sie ein App-Passwort, wo der Anbieter eines verlangt: der Assistent bietet Ein-Klick-Verbindungsprofile für die gängigen Anbieter). Der Datei-Upload-Weg akzeptiert Outlook .pst (E-Mail + Kalender + Kontakte), .mbox (E-Mail, einschließlich eines Google-Takeout-Exports – der einfachste Weg, ein persönliches Gmail-Konto zu verlassen), .ics (Kalender) und .vcf (Kontakte), wobei das Format automatisch anhand des Dateiinhalts erkannt wird. Der Ablauf ist Quelle → Konten → Nutzer (mit einem Anmeldedaten-Test pro Zeile, oder einem Upload pro Datei) → Ausführen → Live-Dashboard mit Wiederholung pro Zeile und Batch-Pause/-Abbruch. Alle Änderungen werden auditiert. Vollständige Details und die Roadmap (CalDAV/CardDAV, Microsoft 365 Graph, Gmail API, Tenant-zu-Tenant) stehen in Migration.

Mandantenfähigkeit & Isolation

Standardmäßig ist Goooy logisch mandantenfähig: Jede Abfrage wird nach orgId eingegrenzt und durch RBAC geschützt, wobei sich alle Mandanten eine Datenbank teilen. Für strengere Anforderungen gibt ein optionaler Modus mit harter Isolation jedem Mandanten ein eigenes PostgreSQL-Schema oder eine eigene Datenbank:

TENANT_ISOLATION = shared (default) | schema | database

Ein Control-Plane-Katalog löst die richtige Verbindung pro Anfrage auf (req.db), sodass der Standard mit gemeinsamer Datenbank völlig unverändert bleibt, wenn Sie sich nicht dafür entscheiden. So können Sie Datenhaltung pro Mandant oder vertragliche Isolation anbieten, ohne separate Bereitstellungen zu betreiben. Siehe Mandantenfähigkeit.

Sicherheit & Compliance

Eine komprimierte Checkliste. Die maßgebliche Referenz ist Sicherheit.

• Transport. TLS wird am Ingress terminiert (optional automatisiert mit cert-manager). TLS zu den Backing-Stores wird über die URL gesteuert und erfordert keine Codeänderung: ?sslmode=require bei DATABASE_URL, rediss:// für Redis, https:// S3-Endpunkt.

• Header. Helmet auf der API; nginx setzt eine strikte CSP, X-Frame-Options: SAMEORIGIN, Referrer-Policy und eine Permissions-Policy, die Kamera/Mikrofon/Display-Capture auf self beschränkt. CORS ist auf PUBLIC_WEB_URL beschränkt (native Protokollpfade sind bewusst ausgenommen, „korrigieren” Sie das nicht).

• Ende-zu-Ende-Mail-Sicherheit (S/MIME). Jeder Nutzer kann eine selbstsignierte X.509-Identität zum Signieren/Verifizieren (RSA-SHA256) und Verschlüsseln/Entschlüsseln (hybrid RSA-OAEP + AES-256-GCM, mehrere Empfänger) haben; der Private Key wird im Ruhezustand versiegelt und nie im Klartext zurückgegeben.

• E-Mail-Rendering. HTML-E-Mails werden von DOMPurify bereinigt und durch die nginx-CSP eingeschränkt. Behalten Sie beides bei.

• Secrets im Ruhezustand. S/MIME-Keys, SSO-Client-Secrets und Migrationsanmeldedaten werden mit JWT_SECRET per AES-256-GCM versiegelt. Stellen Sie Ihr eigenes Secret bereit; rotieren Sie JWT_SECRET bewusst (es macht versiegelte Werte ungültig).

• Container laufen ohne Root-Rechte unter einem restriktiven Security-Context.

• Datensouveränität. Goooy ist durchgängig selbstgehostet. Sie wählen die Region und den Anbieter für jeden Speicher. Siehe Datensouveränität.

• Aufbewahrung. Richtlinien je Organisation lassen Mail, Dateien und Nachrichten nach einem Zeitplan verfallen, den Sie setzen. Der Durchlauf läuft im Hintergrund und wird protokolliert.

• Legal Hold. Ein Hold auf eine betroffene Person bewahrt deren Daten, überstimmt die Aufbewahrung bis zur Aufhebung und exportiert alles als JSON zur Prüfung.

• Data Loss Prevention. Organisationsweite Prüfung über Mail, Chat und Dateien auf die Muster, die Sie konfigurieren.

Lizenz: AGPL-3.0-or-later.

Backups & Betrieb

• Was zu sichern ist: PostgreSQL (das System of Record) und Ihr S3-Bucket (Datei- und Anhangs-Blobs). Redis ist flüchtig und benötigt kein Backup. Das Chart kann einen nächtlichen pg_dump-CronJob ausführen (backup.enabled=true).
• Health-Probes: Die API stellt /healthz (Liveness) und /readyz (DB-gestützte Readiness) für Kubernetes bereit.
• Skalierung: Die API ist zustandslos (JWT-Auth) und verteilt Echtzeit über Redis-Pub/Sub, sodass sie horizontal skaliert. Aktivieren Sie den HPA (autoscaling.enabled=true, benötigt metrics-server) und ein PodDisruptionBudget für sichere Rollouts.
• Observability: strukturierte JSON-Logs (pino).
• Schemaänderungen: Der API-Container führt beim Start prisma migrate deploy aus, sodass committete Migrationen beim Rollout automatisch angewendet werden.
• Beenden Sie nicht die Ingest-Ports (2525/2526), um sie in einer laufenden Umgebung „freizugeben”. So kommen eingehende E-Mails an.

Self-Service-Anmeldung & Ihre Marketing-Präsenz

Goooy kann einen öffentlichen Self-Service-Anmeldung-Ablauf betreiben, sodass Kunden ihre eigene Organisation erstellen. Er ist standardmäßig deaktiviert. Setzen Sie SELF_SIGNUP_ENABLED=true, um ihn zu aktivieren. Der Endpunkt erstellt atomar eine Organisation, ihre erste Domain und einen ORGADMIN-Nutzer (niemals SYSADMIN) und liefert eine aktive Sitzung zurück. Er ist als Missbrauchsschutz pro IP ratenbegrenzt.

Die mitgelieferte Web-App liefert bereits eine öffentliche /signup-Seite, die diesen Ablauf same-origin ansteuert, sodass Sie sie nicht selbst bauen müssen. Und eine statische Astro-Marketing-Website (apps/marketing) ist als öffentliche Eingangstür enthalten. Aktivieren Sie sie auf einem eigenen Host:

helm upgrade goooy ./deploy/helm/goooy \
  --set marketing.enabled=true \
  --set marketing.host=www.example.com

Ihr „Loslegen”-CTA verweist auf die /signup-Seite der App. Die vollständige externe Auth-API (Login, MFA, SSO, Sitzungen, Domain-Verifizierung), alles, was Sie bräuchten, um stattdessen Ihre eigene Anmelde-Front zu bauen, ist in Self-Service-Onboarding & externe Authentifizierung dokumentiert.

Loslegen

• Neu hier? Lesen Sie das Benutzerhandbuch für die Endnutzersicht auf jede App.
• Sie stellen die Plattform bereit oder integrieren sie? Das Entwicklerhandbuch behandelt die Architektur, die Bereitstellung mit Helm/Docker Compose und die Konfiguration.
• Durchstöbern Sie die Seiten Funktionsübersicht, Sicherheit & Compliance und Self-Hosting.
• Die vollständige technische Referenz (Architektur, Datenmodell, Mailserver, Mandantenfähigkeit, Deployment, Migration und die nativen Client-Protokolle) wird mit dem Produktquellcode ausgeliefert.