Beiträge von ManDal

Ich habe mein bisheriges Script zur Zertifikatsübernahme für b1gMailServer grundlegend überarbeitet und vollständig auf Python umgestellt.

Die wichtigste Änderung: Die Hostnamen für IMAP, POP3 und SMTP werden jetzt direkt aus den Einstellungen des BMS-Plugins in der Datenbank gelesen. Daraus erstellt beziehungsweise erneuert Certbot ein gemeinsames Zertifikat für die konfigurierten Mailserver-Adressen.

Damit entfällt die bisherige Abhängigkeit von z.B. LiveConfig und den Zertifikatspfaden in der Apache- oder nginx-Konfiguration. Für die Ausstellung wird Certbots Webroot-Verfahren verwendet. Der bestehende Webserver bleibt dabei aktiv und liefert lediglich die Prüfdateien aus.

Zusätzlich habe ich einige Punkte verbessert:

• Prüfung von Zertifikat, Private Key, Hostnamen, Gültigkeit und Zertifikatskette vor der Übernahme
• Aktualisierung und Dienstneustart nur bei tatsächlich geändertem TLS-Material
• Sicherung der bisherigen Zertifikate und Rollback bei Austausch- oder Startfehlern
• Logs und Backups in eigenen Unterordnern
• Python-Installer mit optionaler Einrichtung des täglichen Cronjobs
• Vorschau- und ACME-Testmodus für die Einrichtung

Wichtig für die HTTP-Validierung: Alle im BMS-Plugin hinterlegten Mailserver-Hostnamen müssen über Port 80 die Dateien unter "/.well-known/acme-challenge/" aus dem konfigurierten Webroot ausliefern können. Die Erreichbarkeit der Webmail-Adresse allein reicht dafür nicht aus.

Quellcode, Anleitung und Konfigurationsbeispiele findet ihr hier:

https://git.onesystems.ch/b1gMail/b1gMailServer-TLS-Manager

Rückmeldungen und Erfahrungen mit anderen Installationen sind willkommen.

Ich komme bei deinem Aufbau noch nicht ganz mit bzw. verstehe den Vorteil der zusätzlichen Postfix-Instanz noch nicht.

Wenn sowieso ein PMG eingesetzt wird, würde ich den Mailflow möglichst einfach halten:

• Inbound: Internet > PMG > BMS
• Outbound: BMS > PMG > Internet

Gerade Virenprüfung, Spamfilterung, DKIM, SPF, Filterregeln usw. sind ja eigentlich genau die Aufgaben, die PMG bereits von Haus aus übernimmt. Deshalb erschliesst sich mir noch nicht ganz, was der zusätzliche Postfix in diesem Aufbau übernimmt.

Anders wäre es natürlich, wenn Postfix die Mails nach dem PMG direkt in b1gMail pipet und damit der SMTP-Teil von BMS für eingehende Mails komplett umgangen wird. Dann würde ich den Sinn hinter dem Aufbau halbwegs verstehen.

Falls der Flow aber tatsächlich PMG > Postfix > BMS ist, hätte man aus meiner Sicht einfach einen zusätzlichen MTA mit eigener Queue, Konfiguration und Logs dazwischen, ohne dass ich darin momentan einen wirklichen Vorteil sehe.

Auch Let's Encrypt wäre für mich kein Grund dafür. Ich nutze seit mehr wie 5 Jahren ein kleines Script, das die Zertifikate vom Webserver übernimmt und BMS zur Verfügung stellt. https://git.onesystems.ch/System-Tools/b…src/branch/main

Mich würde daher tatsächlich interessieren, wie dein kompletter Inbound- und Outbound-Mailflow aussieht und welche konkrete Aufgabe Postfix darin übernimmt.

Zitat von SLM

Mit meiner aktuellen BMS-Version 2.8.3306 tritt das Umlautproblem nur unter MacOS auf. Unter iOS 26.6.2 tritt das nicht auf (iPhone 15 Plus).

Alles zurück, unter iOS funktioniert es korrekt. Der Fehler lag bei meinem Testaufbau.

Das eigentliche Problem ist, dass ich aktuell kein macOS-System zum Testen zur Verfügung habe.

SLM  patrick Ich kann das Problem mit den Umlauten bei mir auch unter iOS reproduzieren. Tritt das bei euch unter iOS nicht auf?

Zitat von patrick

Hast du die Apple-Mail-Sache getestet? Eine einfache Konvertierung nach latin1 (wie im PR) hatte bei mir nicht geholfen, da Apple Mail die Umlaute als zwei Zeichen z.B. "¨" (diaeresis) und "u" sendet. Man muss diese Paare erkennen und auf Umlaute zurück mappen, sonst erhält man bei Konvertierung sowas wie "?u" oder "u?", da "¨" nicht auf latin1 gemappt werden kann.

Zu der Pipe-Sache: Ich würde das auf PHP-Seite fixen und nicht das Protokoll bzw. den Parser verkomplizieren. Reicht ein einfaches error_reporting(0) oder init_set-Deaktivierung von display_errors nicht aus?

Bei meinen bisherigen Tests funktioniert die Darstellung der Umlaute auf dem iOS-Gerät grundsätzlich korrekt. Ordner, die in b1gMail mit Umlauten angelegt werden, erscheinen auf dem iOS-Gerät sauber mit dem richtigen Namen.

Ich habe allerdings gerade festgestellt, dass es aktuell nur in diese Richtung funktioniert. Wird ein Ordner mit Umlauten direkt auf dem iOS-Gerät angelegt, wird der Name in b1gMail noch nicht korrekt übernommen.

Da muss ich also nochmals ran, bevor der Fix vollständig ist.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

PR: #27

PHP-Prozesse wiederverwenden (inbound_reuse_process=1)
Ab PHP 8.4 landen oft Deprecation-Meldungen auf stdout und stören das Pipe-Protokoll (RCPT/DATA). Der BMS hat sich dann in fgets festgefahren und den PHP-Prozess abgeschossen. Das ist auf BMS-Seite gehärtet (Timeouts, Rauschen ignorieren, kaputte Worker wegwerfen). Das Protokoll selbst bleibt gleich, PHP 7.4/8.2 sollen weiterlaufen. Die Deprecations in pipe.php/serverlib sind damit nicht weg, der BMS hängt sich nur nicht mehr daran auf.

IMAP-Umlaute (Apple Mail)
Ordnernamen gehen jetzt nach RFC 3501 als modified UTF-7 raus/rein. Speichern weiter passend zu SET NAMES latin1, auch wenn bm60_folders.titel utf8mb4 ist. Webmail-Ordner waren nie das Problem; nach dem Update in Apple Mail einmal die Ordnerliste neu laden.

Zweiter Mail-Server
Nur /serverlib oder nur /plugins zu mounten reicht nicht. Der BMS braucht den b1gMail-Webroot (interface/pipe.php, daneben serverlib/ und plugins/). In der b1gmailserver.cfg kann man das jetzt lokal überschreiben, ohne dass die DB-Werte für alles andere verloren gehen:

selffolder = /mnt/b1gmail/
datafolder = /mnt/b1gmail-data/
php_path   = /usr/bin/php

Den ganzen Baum mounten, nicht serverlib allein. Gehashte Beispiele stehen nach Install/Update in der cfg.

Wichtig: So ein Split-Setup (Web und Mail getrennt) habe ich hier aktuell nicht zum Testen. Das ist also nur der Code-Weg, keine Bestätigung aus dem Betrieb. Wer das so fährt: bitte prüfen, ob pipe.php auf dem Mail-Host erreichbar ist und Zustellung/IMAP damit klappt. Feedback sehr willkommen.

Zusätzlich: wenn logfile gesetzt ist, kann man mit logrotate=1 die Rotation vom BMS anlegen lassen (bei jedem Start, Pfad aus der cfg). Bestehende logfile=-Zeilen werden nicht nochmal angehängt.

Kompatibel mit offiziellem b1gMail 7.4. Tester zu Keep-Alive (PHP 8.4), Apple Mail und vor allem Split-Server wären hilfreich.

Zitat von SLM

ManDal  Sebijk Prüft bitte mal die Anbindung des BMS, wenn man den BMS auf einem zweiten, eigenen Server laufen lässt - oder auf mehreren. Bislang muss man die /serverlib und /plugins - Ordner zusätzlich auf den zweiten Server kopieren. Manuel hat einen Weg gefunden, den /plugins Ordner zu mounten, das funktioniert scheinbar aber nicht mit dem /serverlib - Ordner. Man kann aber auch nicht ständig daran denken, alles zu synchronisieren.

Bisher kam selffolder (und damit der Pfad zu pipe.php / serverlib / PHP-Plugins) immer aus der Datenbank, also vom Webserver. Ein lokaler Eintrag in der b1gmailserver.cfg auf dem Mailserver wurde überschrieben. Deshalb musste man serverlib und plugins kopieren oder syncen – und ein reiner serverlib-Mount reicht nicht, weil pipe.php unter interface/ liegt und relativ ../serverlib plus die PHP-Plugins braucht.

Das ist jetzt angepasst: Werte in /opt/b1gmailserver/b1gmailserver.cfg gelten auf diesem Host und überschreiben die DB.

$Auf dem Mailserver reicht z. B.:

selffolder      = /mnt/b1gmail/
datafolder      = /mnt/b1gmail-data/
php_path        = /usr/bin/php

Gemountet werden sollte der komplette b1gMail-Web-Root (nicht nur serverlib):

/mnt/b1gmail/
  interface/pipe.php
  serverlib/
  plugins/

datafolder (Mailbestand) gehört auf ein gemeinsames NFS.

Im Log steht dann etwas wie: Keeping local selffolder from b1gmailserver.cfg (not using DB value).

Damit entfällt das ständige Synchronisieren der PHP-Ordner; jeder Mailhost zeigt einfach auf seinen lokalen Mount.

Ein solches Setup (Web und Mail getrennt) habe ich hier selbst nicht zum Gegenprüfen. Ob der Mount in der Praxis so durchläuft – inkl. pipe.php, PHP-Plugins und datafolder – müsste noch an einer echten Split-Installation getestet werden. Rückmeldungen dazu wären sehr willkommen.

Zitat von SLM

Eine Bitte habe ich zusätzlich noch: Vergesst bitte nicht das Umlaut-Problem bei E-Mail-Ordnern & Apple Mail. Wenn es möglich wäre noch in einer BMS-Version die man noch unter b1gMail 7.4.x einsetzen kann.

Apple Mail übermittelt die Ordnernamen korrekt als Modified UTF-7 gemäss RFC 3501. Siehe dazu auch GitHub #24. Ein Ordner mit Umlaut kommt beispielsweise als „CREATE Umla&Awg-ut“ beim BMS an.

Das eigentliche Problem lag im BMS. Die per IMAP empfangenen Ordnernamen wurden bisher nicht korrekt in den von der Datenbankverbindung verwendeten Zeichensatz latin1 konvertiert. Dadurch gingen Umlaute beim Erstellen von Ordnern über IMAP verloren. Ordner, die direkt über das Webmail angelegt wurden, waren davon nicht betroffen.

Ich habe die Verarbeitung im BMS entsprechend angepasst. Eingehende Ordnernamen werden nun korrekt aus Modified UTF-7 dekodiert und passend zur latin1-Verbindung gespeichert. Bei LIST und STATUS erfolgt die Konvertierung wieder zurück nach Modified UTF-7, damit Clients wie Apple Mail die Ordnernamen korrekt erhalten.

Ich werde die Änderung aber noch ausführlich mit verschiedenen IMAP-Operationen und Umlauten durchtesten, bevor ich sie freigebe.

Zitat von informant

Also ich habe mal getestet. Mit PHP 7.* klappt es, mit PHP8.2 auch, ab PHP8.4 nicht mehr. Ab hier wird strict genutzt. Im BMS code sind noch alte Codezeilen wo er sich aufhängt und die PHP PIPE Prozesse abbricht. Ich denke und vermute also, dass der Code noch auf PHP8.4 und höher strict angenpasst werden muss (BMS).

Nach etwas nachdenken ist mir eine Idee gekommen. Auf dem einzelnen MAIL SRV liegen ja noch alte PHP Dateien, die habe ich mal mit dne neuen überschrieben, siehe da, es funzt wieder

Das hat meiner Einschätzung nach weniger mit einem strengeren Verhalten von PHP 8.4 zu tun, sondern eher damit, dass die Deprecated-Meldungen an dieser Stelle nicht sauber abgefangen werden.

Soweit ich das aktuell sehe, erwartet der BMS bei der Keep-Alive-Pipe genau eine SMTP-Antwortzeile. Wird zusätzlich eine Deprecated-Meldung ausgegeben, kommen plötzlich mehrere Zeilen zurück. Damit konnte die Verarbeitung bisher nicht umgehen: Der BMS ist an der Stelle durcheinandergekommen bzw. hängengeblieben und hat den PHP-Pipe-Prozess anschliessend abgebrochen.

Die Pipe-Verarbeitung im BMS habe ich deshalb robuster gemacht:

• Lesen und Schreiben auf der Pipe laufen jetzt mit Timeout, der BMS bleibt dort nicht mehr endlos stehen.
• Zeilen, die keine SMTP-Antwort sind (z. B. Deprecated:, Warning:, TypeError), werden übersprungen und ins Queue-Log geschrieben.
• Ein Worker, der hängen bleibt, abstürzt oder unerwartete Ausgaben liefert, wird nicht wiederverwendet, sondern beendet.
• Idle-Prozesse und Worker nach vielen Zustellungen werden zusätzlich recycelt, damit kein PHP-Prozess unbegrenzt weiterläuft.

Wenn so etwas unter PHP 8.4 noch auftritt, sollte im Queue-Log jetzt etwas in dieser Richtung stehen:

Inbound keep-alive pipe produced non-protocol output during RCPT TO: Deprecated: ...

Die eigentlichen Deprecated-Stellen bleiben trotzdem ein Thema, vor allem in b1gMail (pipe.php / serverlib). Die härtere Pipe im BMS fängt die Auswirkungen ab; parallel schaue ich mir die betroffenen Stellen an, damit diese Meldungen gar nicht erst entstehen.

Zitat von patrick

Gibt es irgend ein neues Rate-Limiting-Konzept i.V.m. Argon2-Hashes?

Ich fürchte, dass das ansonsten ein Schuss in den Fuß ist, da Angreifer den Server sonst mit Authentifizierungsversuchen schnell komplett überlasten können, da die Hashes (absichtlich) sehr rechenintensiv sind.

Danke für den Hinweis, der Punkt ist berechtigt.

Es gibt kein komplett neues Rate-Limiting-Konzept nur für Argon2, aber wir haben das bestehende Fail2ban dafür geschärft:

• Vor der teuren Hash-Prüfung (bcrypt/Argon2 bzw. App-Passwort-Prüfung) wird die IP geprüft.
• Ist die IP bereits gebannt → Login wird ohne Hash-Berechnung abgelehnt.
• Bei bereits fehlgeschlagenen Versuchen gibt es zusätzlich eine progressive Verzögerung (ca. 0,5–5 Sekunden) vor der Hash-Verifikation, damit parallele Auth-Versuche den Server nicht so leicht mit CPU-Last fluten.
• Danach greifen weiter die bekannten Mechanismen: kurze Wartezeit nach Fehlversuch und IP-Bann über Fail2ban (im ACP unter b1gMailServer konfigurierbar).

Versteh mich nicht falsch, Postfix ist ein gutes Ding. Gerade die Konfigurierbarkeit über Config-Files und die damit verbundene Nachvollziehbarkeit und Flexibilität sind klare Stärken. Da wird der b1gMailServer vermutlich nie hinkommen, muss er aus meiner Sicht aber auch nicht.

Bei der Integration von Dritttools sehe ich durchaus noch Potenzial. Wenn es konkrete Dinge gibt, die heute nur umständlich über Milter oder externe Konstrukte möglich sind, kann man sich sicher überlegen, wie man solche Integrationen im b1gMailServer künftig sauberer und flexibler gestalten kann.

Zitat von Denny

Ich hatte das seit Umstellung auf PHP 8.3, allerdings liefere ich jetzt endlich über Postfix aus, ist viel bequemer und besser als über b1gmail selbst auszuliefern, da bleibt gar nichts mehr hängen und Signieren, Vieren und Spamprüfung ist direkt viel besser und vor allem immer up2date danke updates

Postfix als MTA ist natürlich eine saubere Lösung. Ich sehe dabei für ein klassisches b1gMail-Setup aber einen kleinen Haken:

Sobald ich neben dem Webmail auch IMAP/POP3 anbieten möchte, brauche ich den b1gMailServer weiterhin. Dann betreibe ich am Ende Postfix und b1gMailServer parallel und verteile die Aufgaben auf zwei Systeme.

Das kann man durchaus so bauen, aber für mich erhöht es erst einmal die Komplexität. Wenn die b1gMail-Queue zuverlässig funktioniert, sehe ich bei meinem Setup mit durchschnittlich 4-5K Mails pro Tag aktuell keinen wirklichen Vorteil darin.

Interessant wäre aber, wie du das bei dir gelöst hast. Läuft der b1gMailServer weiterhin für IMAP/POP3 und Postfix übernimmt nur SMTP beziehungsweise die eigentliche Zustellung?

Kleiner Nachtrag dazu:

Was müsste dem b1gMailServer aus eurer Sicht noch beigebracht oder verbessert werden, damit ihr ihn wieder vollständig für die Mailverarbeitung einsetzen würdet?

Mich würde vor allem interessieren, welche konkrete Funktion euch aktuell fehlt oder wo ihr technisch einen Nachteil gegenüber Postfix seht. Wenn es konkrete Punkte gibt, könnte man sich diese für eine kommende Version durchaus einmal genauer ansehen.

Zitat von Denny

Ich verstehe nicht wie man Sessions überhaupt in Datei speichern kann, lager das doch auf Reddis oder Memcached aus. Ich hab das jetzt seit fast 11 Jahren alles in memcached und ich hatte seither nie wieder irgendein Problem, geht so schnell und alles top damit mit 40K logins am Tag, keine io Probleme, blitzschnell

Memcached oder Redis kann für Sessions durchaus sinnvoll sein, gerade bei mehreren Webservern oder entsprechend hoher Last.

Ich sehe bei 40K Logins pro Tag aber ehrlich gesagt noch keinen zwingenden Grund, deshalb von File-Sessions wegzugehen. Bei vernünftigem lokalen Storage, insbesondere SSD/NVMe, sollte das erst einmal kein nennenswertes I/O- oder Performanceproblem darstellen.

Wenn File-Sessions nachweislich zum Flaschenhals werden, kann man über Redis oder Memcached sprechen. Solange sie aber problemlos funktionieren, würde ich nicht zusätzliche Infrastruktur einführen, nur um ein Problem zu lösen, das in der Praxis gar nicht vorhanden ist.

Das war mein Fehler. Du kannst in der serverlib/version.inc.php die Version wieder auf RC3 zurücksetzen und anschliessend das Update nochmals starten.

Alternativ kannst du unter "Tools > Optimierung > Struktur prüfen" die Datenbankstruktur prüfen und korrigieren lassen.

Wer ALTCHA als Captcha-Provider ausprobieren möchte: Die Unterstützung ist inzwischen im PR für b1gMail 7.5.0 enthalten.

Die Anpassung lässt sich auch mit etwas aufwand unter älteren b1gMail-Versionen verwenden, falls jemand ALTCHA bereits vor dem Update auf 7.5.0 testen oder einsetzen möchte:

Add ALTCHA captcha provider (self-hosted PoW + Cloud fallback) by mkleger · Pull Request #32 · b1gMail-OSS/b1gMail

What Introduces a new captcha provider ALTCHA with two operating modes: Local PoW — self-hosted Proof-of-Work using HMAC-SHA-256, no external services…

github.com

Der b1gMailServer unterstützt jetzt App-Passwörter für IMAP, POP3 und SMTP – analog zu CalDAV/CardDAV/WebDAV in b1gMail.

PR #26

Voraussetzung

Es wird b1gMail 7.5.0-RC4 oder neuer benötigt (App-Passwort-Prefs und ACP-Einstellungen).

Verhalten (Mail-Erzwingung im ACP)

• aus – nur Kontopasswort
• Warnung – Kontopasswort und App-Passwort; bei MFA Hinweis im Log
• MFA: nur App-Passwort – mit aktiver MFA nur App-Passwort
• Strikt – immer nur App-Passwort

App-Passwörter werden im Webmail unter den Einstellungen angelegt (Scopes IMAP/POP3/SMTP erscheinen, sobald die Mail-Unterstützung im ACP aktiviert ist).

Hinweis

Erst nach dem Deploy dieses BMS-Stands im ACP „App-Passwörter für IMAP/POP3/SMTP“ einschalten.

Feedback zu Clients (Thunderbird, Outlook, Smartphone usw.) ist willkommen.

b1gMail 7.5.0-RC4 steht zum Testen bereit.

Aktueller Stand: PR #31 gegen develop-75

GitHub - b1gMail-OSS/b1gMail at develop-75

Run your own email service. For you, your organization — or for everyone. - b1gMail-OSS/b1gMail

github.com

Update von 7.5.0-RC3: Dateien hochladen, danach /setup/update.php aufrufen. Anschließend den setup-Ordner löschen. Browser-Cache leeren. Bei b1gMailServer nach dem Update den Queue-Dienst neu starten.

Mindestens PHP 8.1. Empfohlen: MariaDB (MySQL 8 wird unterstützt).

Änderungen 7.5.0-RC3 → 7.5.0-RC4

Zusammenarbeit / Organizer

• User-to-User-Sharing für Kalender, Adressbuch, E-Mail, Aufgaben, Notizen und Webdisk (Lesen / Lesen+Schreiben)
• Gruppenrechte "Zusammenarbeit" pro Bereich ein- und ausschaltbar
• Mehrere Kalender und Adressbücher (Collections), auch per CalDAV/CardDAV
• Freigaben können verlassen werden; Empfänger werden per E-Mail/Push informiert
• Öffentliche Webdisk-Links (Passwort/Ablauf) bleiben zusätzlich bestehen

App-Passwörter

• App-Passwörter für CalDAV, CardDAV, WebDAV und Mail (b1gMailServer Update PR #26)
• ACP: aus / warnen / erzwingen / streng, Limit pro Benutzer, optionale Laufzeit, HTTPS-Zwang für DAV
• Benutzer verwalten App-Passwörter unter Einstellungen

Tabler-Branding

• Eigenes Logo hell (Login) und dunkel (Sidebar / Dark Mode)
• Eigenes Cover, Copyright ({year}, {title}) und Akzentfarbe
• Favicon nur, wenn extra hochgeladen – ein Logo ersetzt das Favicon nicht mehr
• Logo in der Sidebar zentriert; mobil in einer Zeile mit Menü und Avatar

Oberfläche

• Tabler 1.5.1, Bootstrap 5.3.8, Tabler Icons 3.46.0

Aufräumen / Stabilität

• Web Push: PHP-FPM-Absturz beim Test unter PHP 8.1 behoben
• Inbound-Pipe: Timeouts durch Session-Scan von Web Push behoben
• Scheduler im Core, CleverCron-Jobs werden beim Update übernommen

Hinweise

• Wie immer: Backup, danach setup löschen.

Feedback und Fehler gern hier oder als GitHub-Issue.

Zitat von Sebijk

Wow, vielen Dank, dass du dir so viel Zeit dafür nimmst. Ich freu mich schon richtig, dass man hier einen großen Schritt weiterkommt.

Vielen Dank, das freut mich sehr! 😊 Es steckt einiges an Arbeit drin, aber solche Rückmeldungen motivieren mich, weiterzumachen. Ich freue mich darauf, euch bald mehr zeigen zu können!

App-Passwörter für CalDAV, CardDAV und WebDAV

Für den Zugriff über CalDAV, CardDAV und WebDAV stehen im nächsten RC4 jetzt App-Passwörter zur Verfügung. Damit können Kalender-, Kontakte- und Webdisk-Anwendungen angebunden werden, ohne das eigentliche Kontopasswort zu verwenden.

Die Einstellung, ausschliesslich App-Passwörter für diese Zugriffe zuzulassen, wird je nach Installation unterschiedlich vorbelegt:

• Bei Neuinstallationen ist sie standardmässig aktiviert. Der Zugriff ist damit nur über App-Passwörter möglich.
• Bei Updates bleibt sie zunächst deaktiviert. Das bisherige Kontopasswort wird weiterhin als Fallback akzeptiert, damit bestehende Verbindungen weiter funktionieren. Die ausschliessliche Nutzung von App-Passwörtern kann anschliessend aktiviert werden.

Für einen späteren Schritt ist geplant, App-Passwörter auch auf SMTP, IMAP und POP3 auszuweiten und damit die Einbindung von E-Mail-Programmen ebenfalls abzudecken.

Mit den neuen Funktionen wird b1gMail im Alltag noch praktischer: kürzere Wege, mehr Übersicht und einfachere Zusammenarbeit.

Direkt zum gewünschten Bereich
Kalender, Adressbuch, Aufgabenliste und Notizen sind jetzt direkt in der Hauptnavigation erreichbar. Der Umweg über den Organizer entfällt – so könnt ihr schneller zwischen den Bereichen wechseln.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Mehr Übersicht mit mehreren Kalendern und Adressbüchern
Ihr könnt jetzt verschiedene Kalender und Adressbücher anlegen. Damit lassen sich beispielsweise private und berufliche Termine oder unterschiedliche Kontaktgruppen übersichtlicher voneinander trennen.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Inhalte mit anderen teilen
Ab sofort könnt ihr folgende Inhalte mit anderen Nutzern auf demselben Server teilen:

• E-Mail-Konten und einzelne E-Mail-Ordner
• Kalender
• Adressbücher
• Aufgabenlisten / Aufgaben
• Notizen
• Webdisk und Webdisk-Ordner

Bei jeder Freigabe legt ihr fest, welche Berechtigung gelten soll: nur lesen oder lesen und bearbeiten. So könnt ihr Informationen bereitstellen oder gemeinsam daran arbeiten – passend zu euren Bedürfnissen.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Individuell je Benutzergruppe aktivierbar
Die neuen Funktionen lassen sich für jede Benutzergruppe individuell aktivieren. Administratoren können so gezielt festlegen, welchen Gruppen die Funktionen zur Verfügung stehen.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Ob gemeinsame Terminplanung, geteilte Kontakte oder Dateien fürs Team: Die neuen Funktionen machen den Alltag mit b1gMail noch einfacher. Eine Demo, in der ihr euch selbst ein Bild davon machen könnt, folgt zu einem späteren Zeitpunkt.