Beiträge von ManDal

Zitat von Sebijk

Ab einer bestimmten Zahl von E-Mails wäre es gut, wenn das im Hintergrund ausgeführt wird und zum Download per Link zur Verfügung gestellt wird. Allerdings kann b1gZip mangels Funktionen aktuell nur neue Archive erzeugen und zum Download bereitstellen, php-zip kann auch vorhandene Archive öffnen und Dateien hinzufügen, was auch eine Unterbrechung ermöglichen würde (z.B. wenn es als php-cron ausgeführt wird).

Das wäre viel besser wenn das ab einer gewissen anzahl ausgewählter E-Mails oder allgemein komplett im Hintergrund ablaufen soll, wichtig ist aber das der Link und die ZIPDatei ein Ablaufdatum hat, z.B. nach 24 stunden (am besten einstellbar machen im ACP) bereinigen.

Zitat von Sebijk

Darum werde ich mich mit der nächsten Veröffentlichung kümmern. Bis dahin empfehle ich zusätzlich eine HTTP BasicAuth Abfrage via Webserver (bei Apache mit .htaccess umsetzbar) im Adminbereich einzubauen.

Betreibe einige Eigenentwicklungen und da prüfe ich beim Login immer ob es von der IP bereits ein Login gab und falls nicht informiere ich die Admin E-Mail-Adresse darüber, wäre eine nette Zusatz Funktion bei der man wenigstens informiert wird wenn doch ein Login stattgefunden hat von einer IP die man nicht kennt (wäre evtl. auch etwas für den LI bereich). Weiter müsste man weg von den SIDs kommen die immer in der URL auftauchen, gibt da elegantere varianten und immer mit dem Backend gegenprüfen anhand einer id / public ip etc... ob der User immer noch der User ist der sich Angemeldet hat.

Das ist eine sehr schlechte idee händisch irgendwelche Tabellen zu kopieren, würde eher schauen das du das jetzige System wieder sauber zum laufen zu bekommen.

Was genau rennt den nicht mehr gut?

Nein das du Meldungen von fehlerhaften imap / pop3 / smtp Anmeldungen wie beim Webmail Login auch in das separate Log schreibst, damit könnte man dann die Übeltäter auch blockieren per Fail2Ban und müsste nicht das b1gmailserver log in ein Textfile umbiegen...

Zitat von Sebijk

Für b1gMail habe ich ein neues Plugin erstellt: Log failed Logins: https://codeberg.org/b1gMail/b1gMai…gins.plugin.php

Damit werden fehlgeschlagene Logins unter logs/b1gmail_failedlogins.log geloggt und kann anschließend weiter verwertet werden, z.B. mit Fail2Ban.

Hatte ich auch bereits auf dem Plan, könntest du evtl. auch fehlerhafte logins über den b1gMailServer Loggen?

Ansonsten passt noch alles?

An alle Datenschutzexperten, würde mich die Tage an das Datenschutz Plugin setzen und da ist die Frage ob noch alles an den Abläufen und Texten die enthalten sind korrekt ist oder ob was fehlt?

Die alten News zum Datenschutz Plugin sind im alten b1gMail Forum ersichtlich:

https://board.b1gmail.com/threads/datenschutz-plugin.16082/

Die Version 2.0.0 ist da mit den folgenden Änderungen:

• PHP 8.2 Support (es wird das ionCube PHP Plugin benötigt!)
• b1gMail 7.4.1 Support
• Es wird für das ACP das neue Tabler.io Template verwendet, falls das ACP nicht auf dem neuen Theme ist wird es zu Darstellungsproblemen kommen.
• Es wird neu pro Installation eine Lizenz benötigt die bei uns bestellt werden kann

Ich weiss eine Plugin Aktivierung ist umständlich da die Plugin in der Vergangenheit teilweise mehrmals verwendet wurden haben wir uns dafür entschieden, wir werden die übertragenen Daten (IP, Domäne und Pfad im Dateisystem) ausschliesslich für die Lizenzprüfung verwenden und sind transparent bei uns im Portal ersichtlich.

Registration und Download über unseren Shop verfügbar:

Warenkorb - OneSystems GmbH

Es gibt ein Update vom ACP, aktualisiert auf Tabler 1.3.2 und einigen kleineren Anpassungen.

Diejenigen die testen wollen können mein die Daten aus meinem Fork holen und ausprobieren, einfach den Ordner src/admin/templates bei eich hochladen (natürlich den jetzigen templates Ordner bei euch weg kopieren), funktioniert mit 7.4.0 und 7.4.1:

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

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

github.com

Zitat von patrick

Ich denke ein Sharding-Ansatz wäre sinnvoller, habe dazu hier im Forum schonmal irgendwann was geschrieben.

Hört sich spannend an.

Wäre es evtl. auch eine Möglichkeit sofern das performant machbar wäre das das in eine SQLite DB ausgelagert wird ähnlich wie die für die E-Mails (eine Datei pro Benutzer)? Ist jetzt nur laut gedacht... weiss aber nicht ob das bezüglich Indexierung etc. überhaupt machbar wäre...

Ich mache komplette Snapshots des Systems auf einen von uns betriebenen Backup Server (falls jemand Proxmox VE betreibt und Interesse hat) und zusätzlich aus der Historie mit rsnapshot, dauert aber ist ja nur eine zweite Kopie und wird in naher Zukunft wegfallen.

Das ding mit den Blobs ist halt cool aber aus meiner Sicht nicht nicht ganz fertig gedacht...

Genau bei Rsync sicherst du ja immer den gesamten Blob, klar immer noch performanter wie 1000ende kleinst Daten aber von der datenmenge und laufzeit wahnsinn...

Wie Backupst du dein System?

Dafür wäre es dann aber sehr hilfreich wenn pro Jahr oder Monat eine Datei da wäre, dann muss dein Backup nur das aktuelle (wo die meisten Veränderungen stattfinden) sichern und nicht immer alles...

Ich würde ich aus Redundanz und auch für die Wartung zwei PMGs bevorzugen da dann immer einer da ist der die die Mails entgegen nimmt (zwei MX Einträge im DNS), da sonst falls der PMG einen neustart braucht (Wartung oder sonst was) keiner mehr die Mails entgegen nimmt und zwischenspeichert. Weiter genau bei so vielen Mails die du erhälst wird die Last in der regel aufgeteilt auf zwei Systeme...

Du musst auch dafür nicht beide Server lizenzieren, einer reicht dafür eigentlich vollkommen aus...

Wäre grundsätzlich bei der SQLite variante nur gefällt mir das Konstrukt nicht das es pro Benutzer eine "Datei" gibt was bei sehr grossen Postfächer aus meiner Sicht gerade bei Backup oder Snapshots einfach jedesmal einen Change gibt und immer alles komplett gesichert wird.

Viel besser wäre es wenn man einstellen könnte das es pro Jahr oder Monat eine neue Datei gibt denn in der regel ist alles was älter wie ein Jahr oder sogar noch weniger ist nur noch als Persönliches Archiv zu betrachten (gelöscht wird ja sowieso nie). Ein Pluspunkt wäre dann noch das man z.B. das aktuelle Jahr auf einem schnelleren Storage betreiben kann und alles ältere auf langsamere Platten oder sogar S3 auslagern könnte, das würde gerade bei grösseren Systemen die Kosten nicht so in die höhe treiben...

Hey, ja nicht ganz in der Grössnordnung habe nur 20-50k Mails pro Tag, wichtig ist das du einen Cluster betreibst und die Nodes selber genügend Ressourcen haben die Mails auch zu verarbeiten.

Diejenigen die hCaptcha anschauen möchten, habe das kurzerhand umgesetzt da es sehr einfach ist reCaptcha dadurch zu ersetzen:

hCaptcha Provider by mkleger · Pull Request #9 · b1gMail-OSS/b1gMail

Copy of reCaptcha and adapted to a better, more reliable provider

github.com

Die Version 2.0.0 ist da mit den folgenden Änderungen:

• PHP 8.2 Support (es wird das ionCube PHP Plugin benötigt!)
• b1gMail 7.4.1 Support
• Es wird neu pro Installation eine Lizenz benötigt die bei uns bestellt werden kann

Ich weiss eine Plugin Aktivierung ist umständlich da die Plugin in der Vergangenheit teilweise mehrmals verwendet wurden haben wir uns dafür entschieden, wir werden die übertragenen Daten (IP, Domäne und Pfad im Dateisystem) ausschliesslich für die Lizenzprüfung verwenden und sind transparent bei uns im Portal ersichtlich.

Registration und Download über unseren Shop verfügbar:

Warenkorb - OneSystems GmbH

Die alten News zum Who’s Online sind im alten b1gMail Forum ersichtlich:

https://board.b1gmail.com/threads/who%E2%80%99s-online.16668/