Beiträge von patrick

Hetzner Cloud, 4 vCPUs, 16 GB RAM, 160 GB NVMe, 1 GBit/s-Anbindung, statische IP die nicht als Dial-Up klassifiziert ist, keine Investitionskosten, kein Stress mit Hardwarewartung, USV + Klimatisierung, kein Lärm und keine Stromkosten zuhause, 20,11 EUR/Monat + 20% für vollautomatische tägliche Backups ohne Beeinträchtigung des Serverbetriebs

Gibt nun einen weiteren Patch (Build 3300), der SPF-Probleme bei Mails von Domains mit sehr langem SPF-Record behebt (z.B. von Amazon / SES).

core/dns: Increase buffer size · b1gMail/b1gMailServer@f2c64dc

Contribute to b1gMail/b1gMailServer development by creating an account on GitHub.

github.com

COPY-Kommando hatte einen Bug durch das OSS-Refactoring. Fix gibt's hier: https://github.com/b1gMail/b1gMai…runs/4689440930

Dann scheint das Problem zu sein, dass Verschieben nicht klappt. Dein Client verschiebt die Mails, und nutzt nicht die Löschkommandos von IMAP. Hat mit Löschen direkt also erstmal scheinbar nichts zu tun. Ich versuche mal, das hier nachzustellen.

Es ist Sache des Clients, wie er beim Löschen vorgeht. Der IMAP-Server hat Mails noch nie automatisch beim Löschen verschoben.

Die TLS-Negotiation geht ja durch, daran sollte es also nicht liegen. Warum auf MS-Seite die Verbindung beendet wird, kann man so leider nicht sehen. Bekommst du denn eine Fehlermail zurück? Darin sollten sich Details finden lassen.

Zitat von Sebijk

Da patrick ihn aktuell pflegt, sollte man am besten ein Ticket unter https://github.com/b1gMail/b1gMailServer/issues aufmachen.

Bei IMAP erhalten gelöschte Mails ein entsprechendes Flag und werden nicht automatisch in einen Ordner verschoben. Das ist im Protokoll so vorgesehen und war auch schon immer so...

Das war ein Bug in b1gMailServer. Fix: https://github.com/b1gMail/b1gMai…f680734346a63d7

Download: https://github.com/b1gMail/b1gMai…facts/589013212

ManDal: Sein eigener SPF-Record ist in diesem Fall nicht relevant. Der wäre nur interessant, wenn von ihm gesendete Mails nicht zugestellt werden können. In diesem Fall kann er aber Mails der Uni Bamberg nicht empfangen.

Hast du b1gMailServer neu installiert oder den /opt-Ordner rüberkopiert?

Hier als SVG, damit sollte dann alles möglich sein.

Sieht klasse aus! Ich schau mal nach dem Logo...

Die kann man gefahrlos entfernen. Man sollte nur darauf achten, "rmdir" zu verwenden und nicht "rm -r" oder so, um zu vermeiden, dass man das Verzeichnis genau in dem Moment löscht, in dem eine neue Datei darein geschrieben wird.

Habe noch ein paar mehr kleinere Fixes und Optimierungen gepusht.

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!

Zitat von Sebijk

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.