Habe noch ein paar mehr kleinere Fixes und Optimierungen gepusht.
Beiträge von patrick
-
-
Hi,
ich habe einen Fehler gefunden, der beim Code-Cleanup entstanden ist und damit zu tun haben könnte.
Den Fix gibt's hier: https://github.com/b1gMail/b1gMai…4b8f7903127fc80
Außerdem behebt das auch ein Problem, bei dem iOS-Geräte den Gelesen-Status von Mails teilweise nicht richtig synchronisieren konnten.
Viele Grüße
Patrick
-
You'll have to open the .pro file (in "src/") in Qt Creator.
-
Hi,
da ich recht viel im Code ändern musste, kann das natürlich sein, auch wenn ich es bisher auf meiner Seite nicht beobachten kann (ich setze die OSS-Version selbst ein für mein Mailsystem).
Um die Sache zu analysieren, wäre es nützlich, wenn du Debug-Logs einer solchen Sitzung mit den vielen FETCH-Kommandos aufzeichnen und mir senden könntest. Insbesondere das genaue FETCH-Kommando wäre interessant. Auch wäre es wichtig zu wissen, welcher Client in dem Fall verwendet wird.
Viele Grüße
Patrick
-
Hallo zusammen,
einer der größten Schwachpunkte von b1gMail ist m.E. die fehlende horizontale Skalierbarkeit. Bei großen Setups ist oft die Datenbank der Flaschenhals, da alle Mail-Metadaten in einer einzigen Tabelle gespeichert werden.
Eine Idee, dies mit relativ wenig Aufwand zu lösen, wäre es, mehrere Datenbankserver zu unterstützen. Jedem Benutzer wird dann ein Datenbankserver zugeordnet. Die Mails (und ggf. auch andere Daten wie Ordner, Termine, Adressen, ...) würden dann auf dem jeweiligen Server abgelegt. So wird die Last verteilt und man kommt mit mehreren günstigen, kleinen Servern aus. Außerdem kann man nach Bedarf neue Server hinzufügen.
Der Admin könnte im ACP entsprechend die Zugangsdaten mehrerer "Shard"-Server hinterlegen und dann festlegen, nach welcher Strategie ein Benutzer bei Registrierung einem Shard zugeordnet werden soll.
Was dazu m.E. nötig wäre:
- Shard-Administrationsbereich zum Anlegen von neuen Servern und Konfiguration der Sharding-Strategie.
- Alle Orte, an denen auf die bm60_mails-Tabelle zugegriffen wird, müssten durch ein $userShard-Objekt erfolgen, statt durch das zentrale/globale $db-Objekt.
- Code vom ACP / cron.php, der User-übergreifende Aktionen in der bm60_mails-Tabelle durchführt, muss entsprechend überarbeitet werden.
- Entsprechende Anpassung von b1gMailServer, ggf. z-push-Plugin.
Ich wollte diese Idee, die ich eigentlich in einer b1gMail-Folgeversion (7.5, 8.0?) implementieren wollte, nur mal hier lassen, falls sich jemand daran wagen will.
Viele Grüße
Patrick
-
Hallo zusammen,
den Quellcode der Toolbox gibt es nun hier: https://github.com/b1gMail/BMToolbox
Viele Grüße
Patrick
-
Hallo zusammen,
ich habe den Quellcode vom b1gMail Plugin Builder (dem Tool zum Erstellen der .bmplugin-Dateien) sowohl in einer Commandline-Version (nützlich für Scripts, automatische Builds etc) als auch in der aus dem Plugin-SDK bekannten GUI-Version auf GitHub veröffentlicht: https://github.com/b1gMail/BMPluginBuilder
Viele Grüße
Patrick
Edit: Bitte ggf. nach "Entwicklung" verschieben - Danke!
-
Hallo patrick,
es müsste nur das Feld login in der Tabelle bm60_aliase abgefragt werden und nur wenn yes steht, soll Alias-Login gestattet sein, siehe auch https://github.com/b1gMail-OSS/b1…51306320ace11c4
Ungetestet: https://github.com/b1gMail/b1gMai…d962a7e314c2fcf
Das Installer-Binary mit der Änderung kann man übrigens aus dem GitHub-Actions-Lauf zu dem Commit herunterladen: https://github.com/b1gMail/b1gMai…runs/3979055396 - unten bei Artifacts.
-
Moin,
das Plugin-Interface ist ja nun auch Open Source: https://github.com/b1gMail/b1gMai…n/src/pluginsdk Darin findet man auch die Dokumentation für entsprechende Schnittstellen.
Dort gibt es einen Header "bmsplugin.h", den man braucht, um eigene Plugins zu bauen. Beispiele für funktionierende Plugin gibt's dann z.B. hier:
- https://github.com/b1gMail/b1gMai…insdk/tccme.cpp Das bMS-Plugin für CleverMailEncryption (kennen vielleicht einige noch)
- https://github.com/b1gMail/b1gMai…k/signature.cpp Das bMS-Plugin für das Signatur-Plugin
-
Moin,
wenn du mir die technischen Details zur Alias-Login-Funktion zusammenfassen könntest (oder den Commit schicken kannst, in dem es auf b1gMail-Seite implementiert wird), kann ich mal schauen, ob dafür b1gMailServer-Änderungen nötig sind, und ob ich diese ggf. einbauen kann.
Bezüglich des b1gMailServer ist eine der wichtigsten Aufgaben, die Abhängigkeiten (OpenSSL, pcre, etc) aktuell zu halten, um eventuelle Sicherheitslücken zu schließen. Dabei reicht es häufig, im Dockerfile die entsprechenden Versionsnummern/URLs anzupassen und die Build-Nummer in src/buildno zu erhöhen. Solange man auf der gleichen Hauptversionsummer von OpenSSL bleibt, gibt es meist API-Kompatibilität, sodass man keine Änderungen am Quellcode vornehmen muss.