Beiträge von patrick

    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,

    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:

    1. https://github.com/b1gMail/b1gMai…insdk/tccme.cpp Das bMS-Plugin für CleverMailEncryption (kennen vielleicht einige noch)
    2. 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.