Beiträge von Sebijk

Es gibt sowohl diese https://www.b1gmail.eu/faq-question-list/ als auch das Wiki auf GitHub: https://github.com/b1gMail-OSS/b1gMail/wiki

Was vermisst du denn?

b1gMail 7.4 bietet zwei Speicherarten an. Diese wären:

• Eine Datei pro Objekt (E-Mails werden als Dateiobjekt abgelegt)
• Eine Datei pro Benutzer (eine SQLite-Datenbank/BlobDB pro Nutzer)

Welche nutzt ihr und warum haltet ihr es für die bessere Wahl?

Anmerkung zu eine Datei pro Benutzer:

Diese sollte man nicht nutzen, wenn ein Shared-Hoster die max. Dateigröße beschränkt. Auch bei NAS-Systemen wird es abgeraten, da nicht jeder mit der FileLocking-Methode von SQLite klarkommt.

Dafür hat man nur eine Datei pro Benutzer, während bei eine Datei pro Objekt alles einzeln als Datei abgelegt wird. Bei b1gMail 7.3 und früher gab es auch die Möglichkeit die Daten in der MySQL/MariaDB-Datenbank abzuspeichern.

ja, da MariaDB ursprünglich ein Fork von MySQL war: https://de.wikipedia.org/wiki/MariaDB

das einfachste wäre, zu MariaDB zu wechseln, liefert debian auch mit.

ja, der Bug mit MySQL 8 ist schon länger bekannt: https://github.com/b1gMail-OSS/b1gMail/issues/2

Danke fürs melden. ist behoben.

Ich kann das nachvollziehen, jetzt ist nur die Frage, ob das schon seit 7.4.0 besteht?

Danke. Das ist auch der Grund, warum ich selbst die Google-Integration nicht pflege. An hcaptcha.com hatte ich auch schon gedacht. Altcha scheint ebenfalls interessant.

Das Signaturenplugin für b1gMailServer brauchst du nur, wenn du das Plugin Signaturen nutzt.

Nutzt du CleverMailEncryption? Wenn nein, das besser löschen.

Du wählst einfach unter Artifacts den Installer aus.

Alternativ kann man es auch selbst kompilieren. patrick hat den Prozess sehr einfach gestaltet, worauf auch die Automatisierung der Builds basiert. Man braucht Linux mit installierten Docker. Wenn es nicht in der Linux-Distribution selbst enthalten ist, kann man es auch einfach nachinstallieren, z.B. für Ubuntu: https://docs.docker.com/engine/install…-the-repository

Anschließend ./build.sh im b1gMailServer ausführen und danach bekommt man den b1gMailServer-Installer.

Das BMS-Plugin ist jeweils in den aktuellsten OSS-Versionen von b1gMail enthalten. Dazu muss nach dem Update das Plugin deaktiviert und wieder aktiviert werden, damit aktuellste DB-Änderungen eingespielt werden. Alternativ das BMS-Plugin von b1gMailServer 2.8.3304 veröffentlicht nehmen, dort ist auch das aktuellste Signatur-Plugin enthalten. Das einzigste was ich bisher noch nicht kompilieren konnte, ist das CleverMailEncryption-Plugin für b1gMailServer (scheitert an OpenSSL).

Hallo,

ich habe unter https://github.com/b1gMail/b1gMailServer/issues/20 ein Issue bereits erstellt und habe versucht OpenSSL 3.4.1 zu benutzen, da OpenSSL 1.1.1 seit ein paar Jahren End of Life ist. Hab versucht das mal anzupassen und einen eigenen Branch erstellt: https://github.com/b1gMail-OSS/b1…91d9099e04d51a5

Zuerst habe ich die Buildumgebung auf ubuntu 22.04 angepasst, da eine höhere CMake-Version benötigt wird. Ebenso habe ich den Parameter --libdir=lib hinzugefügt, weil CMake OpenSSL sonst einfach nicht finden will. Die Kompilierung klappt, allerdings müssen die Deprecated-Meldungen angepasst werden und bisher scheint die kompilierte Version nicht lauffähig zu sein, da es bzgl. fehlende OpenSSL-Bibliotheken beklagt.

patrick hat den Buildprozess bei GitHub automatisiert, man kann unter https://github.com/b1gMail/b1gMai…uns/13505674759 den jeweils aktuellen Installer herunterladen (Konto erforderlich bei GitHub).

Tatsächlich sind einige Fehler eingeschlichen beim Einbau des Firmen-Felds, die Korrektur: https://github.com/b1gMail-OSS/b1…3e06740bcd35fc0

Bzgl. der Bestellungsseite:

die problematische Zeile:

$rgTpl->register_resource('prefsdb', array(&$bmPayment, '__tpl_getTemplate', '__tpl_getTimestamp', '__tpl_getSecure', '__tpl_getTrusted'));

wurde zwar mit registerResource ersetzt, allerdings ist der Aufruf ab 3.1 als veraltet deklariert. Eine endgültige Lösung ist aktuell nicht in Sicht, siehe auch: https://www.smarty.net/docs/en/api.register.resource.tpl

Leider hilft mir die Fehlermeldung nicht viel, da ich nicht weiß wo ich suchen muss. Evtl. hilft eine Kompatibilitätsklasse.

Ersetze mal:

include B1GMAIL_DIR . 'serverlib/3rdparty/smarty/Smarty.class.php'; 

durch

include B1GMAIL_DIR . 'serverlib/3rdparty/smarty/SmartyBC.class.php';

ebenso ersetze

class Template extends Smarty {

durch

class Template extends SmartyBC {

ACHTUNG: Ungetestet. lt. Smarty soll aber dies Kompatibilität zu Code leisten, die für eine ältere Smarty-Version programmiert sind.

Wenn du mal Zeit und Lust hast, kannst du mithilfe von Sentry versuchen das ganze zu debuggen

Der Code für die Einbindung in die config.inc.php:

if(defined('B1GMAIL_DIR') && file_exists(B1GMAIL_DIR . 'serverlib/3rdparty/vendor/autoload.php')) {
   include_once(B1GMAIL_DIR . 'serverlib/3rdparty/vendor/autoload.php');
   try {
   \Sentry\init([
       'dsn' => 'http://deineSentryURLwieimProjektangegeben',
       // Specify a fixed sample rate
       'traces_sample_rate' => 1.0,
   ]);
   } catch (Exception $e) {
       error_log('sentry not loaded');
   }
}

Die kommende 7.4.2 wird auch eine Änderung des Plugin-Update bringen: https://github.com/b1gMail-OSS/b1…8815b98c85d0626

Statt eine serialisierte Ausgabe wird nun JSON erwartet. Das erfolgt in Hinblick auch weil die Lücke CVE-2025-1741 auch auf den Plugin-Updater ausgenutzt werden könnte (mit einigen Bedingungen die erfüllt werden müssten). Bei Drittanbieter Plugin die einen eigenen Updater-URL nutzen könnte das problematisch werden, sollte die URL irgendwann nicht mehr existieren und jemand hat sich die Domain gekrallt, um da Schadcode zu verbreiten. Damit es nicht schlagartig funktionsunfähig wird, können Drittanbieter mit der Variable b1gMailVersion die via GET übergeben wird, zusätzlich die b1gMail-Version bestimmen und die Ausgabe für die Version passend herausgeben.

Das Plugin PremiumAccountModul deaktivieren und wieder aktivieren, andernfalls werden DB-Änderungen nicht ausgeführt. Das gleiche gilt auch für den b1gMailServer Adminmodul. Derzeit wird das aktuell nicht automatisch mit dem b1gMail-Update erledigt.

suche in serverlib/payment.class.php nach

function PreparePaymentForm(&$tpl, $title, $amount, $userRow = false)

und ersetze es in

public static function PreparePaymentForm(&$tpl, $title, $amount, $userRow = false)

Zitat von Denny

Code

Fatal error: Uncaught Error: Non-static method BMPayment::PreparePaymentForm() cannot be called statically in /usr/www/users/sendeq/plugins/premiumaccount.plugin.php:1728 Stack trace: #0 /usr/www/users/sendeq/plugins/premiumaccount.plugin.php(1168): PremiumAccountPlugin->_prepareOrderPage() #1 /usr/www/users/sendeq/serverlib/plugin.class.php(1392): PremiumAccountPlugin->UserPrefsPageHandler() #2 /usr/www/users/sendeq/serverlib/common.inc.php(2973): BMPluginInterface->callFunction() #3 /usr/www/users/sendeq/prefs.php(2345): ModuleFunction() #4 {main} thrown in /usr/www/users/sendeq/plugins/premiumaccount.plugin.php on line 1728

welche Version des PremiumAccount-Modul nutzt du? Bei PHP8 muss zwingend die neueste Version aus der OSS-Version eingesetzt werden.

b1gMail 7.4.2 ist angeplant, hauptsächliche Neuerung wird sein: Update auf Smarty5. Ein Branch hierzu existiert bereits: https://github.com/b1gMail-OSS/b1gMail/commits/smarty4. Logischerweise erhöht sich natürlich die Systemanforderung auf mind. PHP 7.2, aber ich habe bereits angekündigt dass 7.4.1 die letzte Version ist, die PHP 5.4 bzw. überhaupt veraltete PHP-Versionen unterstützt. Nachdem CentOS 7 (dass auch PHP 5.4 enthielt) letztes Jahr ausgelaufen ist, ist auch der letzte Grund entfallen, die Unterstützung für veraltete PHP-Versionen aufrechtzuerhalten.

Ansonsten weitere Planungen, falls Zeit dazu ist:

Das neue ACP-Template von ManDal integrieren: https://github.com/b1gMail-OSS/b1gMail/tree/new-acp-template
Teilersetzung von serialize/unserialize, wo es verzichtbar ist insbesondere in Bereichen, wo nicht vertrauenswürdige Daten von externen zum Einsatz kommt.

Hallo zusammen,

welche DNSBL-Listen nutzt ihr? Bisher habe ich ix.dnsbl.manitu.net genutzt, aber das wurde zum 16.01.2025 abgeschaltet: https://hostblogger.de/blog/archives/…ht-zu-Ende.html. Erfahren habe ich das nur über eine Abuse-Meldung.