ManDal Zur Info: Das Umlaut-Problem ist unter iOS nicht vorhanden. Aufgefallen ist es unter MacOS Tahoe. Dazu benötigt man tatsächlich einen Apple-Rechner mit Apple Mail.
PHP8.4.24 + b1gmailServer 2.8.3306 - Warteschleifeneinträge
-
ManDal Ja genau, das Anlegen unter Apple Mail war bei mir das Problem.
-
-
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).
-
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.
-
- Offizieller Beitrag
Bzgl. Umlautprobleme: Ich kann das bei Thunderbird bestätigen, aber das kommt nicht immer vor. Meist konnte ich es reproduzieren, wenn Thunderbird so eingestellt ist, dass es mit Linux zusammen startet, dann hatten Ordner Umlautfehler gehabt. Schließt man dann Thunderbird vollständig und startet es neu, dann geht es wieder. Genauer habe ich es mir jedoch nicht angeschaut.
Ich bin ohnehin dafür den latin1 bzw den ISO-Support zu streichen, da es einfach nur einen Mehraufwand bedeutet und alte b1gMail-Installation, die nicht in UTF-8 konvertiert worden sind, eben noch aus der kommerziellen Zeit stammen. Irgendwo muss man einen Schlussstrich ziehen. D.h. in Zukunft sollte mit eine native UTF-8-Datenbankanbindung gearbeitet werden.
-
Bzgl. Umlautprobleme: Ich kann das bei Thunderbird bestätigen, aber das kommt nicht immer vor. Meist konnte ich es reproduzieren, wenn Thunderbird so eingestellt ist, dass es mit Linux zusammen startet, dann hatten Ordner Umlautfehler gehabt. Schließt man dann Thunderbird vollständig und startet es neu, dann geht es wieder. Genauer habe ich es mir jedoch nicht angeschaut.
Ich bin ohnehin dafür den latin1 bzw den ISO-Support zu streichen, da es einfach nur einen Mehraufwand bedeutet und alte b1gMail-Installation, die nicht in UTF-8 konvertiert worden sind, eben noch aus der kommerziellen Zeit stammen. Irgendwo muss man einen Schlussstrich ziehen. D.h. in Zukunft sollte mit eine native UTF-8-Datenbankanbindung gearbeitet werden.s
Da stimme ich zu, man müsste aber die Folgen davon für b1gMailServer analysieren. (Kann heutzutage vmtl. ein sauber geprompteter Agent in ein paar Minuten de-risken :))
ManDal Kannst du deinen PR ggf. aufteilen in Encoding-Teil und den Inbound-Keepalive-Parsing-Part bzw. die anderen Änderungen? Zu letzterem bin ich nämlich wie gesagt nicht sicher, ob das der richtige Weg ist. Dann könnten wir die Encoding-Sache unabhängig davon angehen.
-
Alles anzeigen
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:Codeselffolder = /mnt/b1gmail/ datafolder = /mnt/b1gmail-data/ php_path = /usr/bin/phpDen 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.
Vielen Dank ManDal - gibt es davon auch eine kompilierte Version für Linux/Debian? Ich muss gestehen dass ich keine Ahnung habe, welche Version man aus dem Git-Repository nehmen muss und wie man eine funktionsfähige Version baut.
-
versuche die mal b1gmailserver
-
versuche die mal b1gmailserver
Merci für den Link. Enthält die Version b1gmailserver-2.8.3313 die genannten Änderungen? Ist die Version bereits im Einsatz und gab es Auffälligkeiten?
-
die Version nutze ich persönlich! hat den neuen Patch für imap und smtp mit drin! von Mandal habe bisher keinerlei Probleme damit
-
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.
iops haben oder nicht haben, damals hatte ich noch HDD - das hat mir ständig die Server ausgelastet mit SSD ist das auch kein Thema mehr..
Cool. Wie machst du das mit der Kundenverwaltung von IMAP/POP3/SMTP? Das läuft doch nur über den BMS?
Tatsächlich nur inbound teilweise outbound (da teste ich gerade), IMAP etc bleibt beim b1gmailserver - allerdings ist das Handling mit Viren, SPAM, DKIM etc viel einfacher mit Postfix und PMG daher habe ich mich dazu entschlossen einen eigenen Server für alle meine Dienste aufzusetzen, ist damit auch besser skalierbar, lässt sich auch schön mit Certbot alles machen - PMG ist so geil, filtert so gut und wenn doch mal ne Welle durchkommt kannst du so einfach Filter erstellen um die zu blocken... kann ich nur empfehlen und ist wirklich nicht schwer einzurichten auf Debian
Incoming Mails (24 hours)
- Incoming Mails: 611882
- Junk Mails (59.17%): 362025
- Spam Mails (6.97%): 42675
- SPF rejects (35.04%): 214406
- Bounces (1.18%): 7244
- Virus Mails (0.00%): 0 -
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.
-
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.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!