Beiträge von SLM

    Wir haben heute den b1gmailserver auf meinem System aktualisiert.

    Die Fehlermeldungen in iOS (siehe Screenshots) treten aktuell nicht mehr auf patrick  Sebijk. Das ist schon mal eine wesentliche Verbesserung!

    Mir ist aber noch folgendes aufgefallen:

    Löscht, verschiebt man im UCP, in der App oder in einem anderen Client eine Mail, oder markiert sie z.B. als Gelesen, dauert es (gefühlt) eine Ewigkeit, bis die Änderung dann auch in iOS ankommt bzw. übernommen wird.

    Könnt ihr ja gerne selbst mal testen. Die Frage ist, liegt es am b1gmailserver, an der Datenbank oder an etwas anderem?

    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).

    Danke. Genügt es, wenn man zuerst die Option "Run Build" wählt und anschließend "Archive artifacts! -> Artifact download URL wählt um das File dann herunterzuladen? Wie verhält es sich mit dem BMSAdmin-Plugin und dem Signature-Plugin?

    Sorry für meine Fragen.

    Der fehler scheint etwas mit SSL Zertifikaten zu tun zu haben, schaltet man SSL ab in iOS Mails und nutzt unsichere Ports funktioniert der abruf bei mir 1a

    Das kann ja aber nicht die Lösung sein. Und Apple sollte das eigentlich in den Griff bekommen. Werden bei dir alle Mails synchronisiert? Bei mir fehlen hin und wieder welche die im UCP zu sehen sind - so wie es auch viele User beschreiben.

    Seit iOS 18 hat Apple Probleme mit IMAP, eine Lösung ist aktuell nicht in Sicht. Die Foren sind voll von solchen Beiträgen. Mails werden z.T. in der Mail App nicht angezeigt, beim Abruf zeigt iOS oft Fehlermeldungen an.

    Mittlerweile melden sich bei mir deshalb vermehrt Kunden, denen ich das Problem dann erklären muss und auf entsprechende Beiträge verweise.

    Trotzdem meine Frage, eventuell auch an patrick: Kann ausgeschlossen werden, dass der b1gMailserver hier ein Problem hat?

    Zu den Screenshots: Meist lassen sich die Meldungen durch mehrmaliges nachladen von E-Mails austricksen. Dass manche E-Mails nicht synchronisiert werden, lässt sich tatsächlich nicht ändern.

    Als ich Firma und Taxid damals in das System integriert hatte, waren das Kann-, aber keine Muss-Felder. Sie werden zwar immer angezeigt, aber die Eingabe ist optional. Wo liegt das Problem gerade?

    SLM
    24. Februar 2022 um 17:17

    Danke für den Hinweis, bislang ist mir das noch nicht aufgefallen. Vor längerem wurde schon mal eine DNSBL-Liste abgeschaltet, das hat man direkt am Verhalten des b1gMailservers mitbekommen. Von der Abschaltung ix.dnsbl.manitu.net war bislang nichts zu spüren.

    Aktuell setze ich noch bl.spamcop.net. sowie list.dnswl.org. ein.

    Bin gespannt, was sonst noch zur Verfügung steht.

    Ich kann die OSS Version nicht so einfach über meine Version 7.4.0 (PL 2) drüberbügeln, da ich im Lauf der Jahre, in denen nicht weiter entwickelt wurde, einige Anpassungen vorgenommen habe. Beim Vergleich der Dateien und Verzeichnisse ist mir gerade aufgefallen, dass z.B. die Datei /serverlib/b1gmailmodul.class.php nicht mehr vorhanden ist.

    Ist die Datei nun überflüssig oder wurden die Funktionen in andere Dateien integriert? Aus dem Repository geht diesbezüglich nichts hervor, zumindest habe ich dazu nichts gefunden. Betrifft das eventuell auch noch andere Dateien?

    Anm.: Gerade habe ich nochmal die Versionen 7.3 und 7.4 verglichen. Ich glaube die Datei wurde damals schon ersetzt und ist nur ein Überbleibsel.


    PS: Hab den Beitrag aus Versehen hier geschrieben, kann gelöscht werden: b1gMail 7.4.1 Patch Level 1

    Den Vergleich mit Postfix kann ich nicht bieten, mein System läuft ausschließlich auf dem b1gMailserver. Debug-Logs sind normalerweise aus, hab sie jetzt zum Test mal angemacht. Sonst ballert mir das innerhalb kürzester Zeit die Logfiles zu.

    SMTP#2413375 - [199.16.156.151] MAIL (transaction rejected due to forged HELO hostname, spring-chicken-al.twitter.com != spring-chicken-al.x.com)Heute, 12:22:46
    SMTP#2413375 - [199.16.156.151] MAIL FROM:<n0901c63e9d-36d9dfcc9d02455b-twitter-meine===mailaddy.de@bounce.x.com>Heute, 12:22:46
    SMTP#2413375 - [199.16.156.151] EHLO spring-chicken-al.x.comHeute, 12:22:45
    SMTP#2413375 - [199.16.156.151] EHLO spring-chicken-al.x.comHeute, 12:22:44


    Ah.. es scheint als hätte die ein EHLO/HELO Problem. Hab das mal dem X-Support gemeldet.

    Danke für den Tipp mit dem Debug-Modus, daran hatte ich nicht mehr gedacht.

    Hat jemand von euch evtl. auch das Problem, dass sein System keine Mails von x.com (ehem. Twitter) durchstellt? Mails @twitter.com kommen problemlos an, jedoch keine Mails von der neuen Domain x.com. Könnte das evtl. auch ein b1gMailserver-Problem sein patrick ?

    Meine Empfangs-Regeln im ACP habe ich geprüft.

    Ja, ich habe sie für die mobile Oberfläche auch im Einsatz. Geht natürlich nur mit der OSS-Variante, weil die 7.4-Version kein Plugin-Hook für die mobile Oberfläche dafür hat.

    Danke für die Info. Der Filehandler ist, soweit ich das erkennen kann leicht auch für die 7.4.0 noch nachrüstbar:


    Code
        serverlib/plugin.class.php:
        
        /**
        * user page handler for mobile interface.
        */
       public function FileHandlerMobile($file, $action)
       {
       }


    Code
    m/alle PHP-Dateien:
    
    /**
     * file handler for modules
     */
    ModuleFunction('FileHandlerMobile',
    	array(substr(__FILE__, strlen(__DIR__)+1),
    	isset($_REQUEST['action']) ? $_REQUEST['action'] : ''));


    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Kannst du uns eventuell nen Tipp geben, was am 2fa-Plugin und ggfls. noch an der mobilen Version angepasst werden muss damit das funktioniert? Geht ja nur ums Login. Die Aktivierung soll weiterhin nur im UCP möglich sein.

    Dann wäre das System zumindest ein Stück weit sicherer. Wäre echt toll..

    Hi Sebijk,

    das Problem hat sich beim warten auf eine Antwort von selbst gelöst. Plötzlich - einige Stunden nachdem ich es aufgegeben habe - wurde die Warteschlange abgearbeitet. Ich kann nicht mehr Nachvollziehen warum das so ist. Schade.

    Update: Ich sehe es hängen wenige Mails nun wieder in der Warteschlange mit dem Fehler: Inbound pipe: b1gMail pipe rejected message data (keep-alive: 1).

    Aber andere werden Zugestellt. Langsam werd ich irre =)

    LG,
    PhiGi

    Prüf mal deine Grundeinstellungen, Wir haben damit gute Erfahrungen gemacht:

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Sebijk Wichtig wäre es, die Datenbankarchitektur bzw. die Archtitektur, wie Daten gespeichert werden in Angriff zu nehmen. Aktuell werden z.B. die E-Mails (bzw. die Verweise) für alle User in der Tabelle _mails gespeichert. Das kann größeren Systemen Probleme verursachen, von eventuellen Datenbank-Crashs bei Ausfällen ganz zu schweigen. Man kann dem Kunden in dieser Form auch schlecht ein eigenes Backup anbieten (könnte man z.B. optional, gegen Aufpreis).

    Im alten Forum hatten wir mit patrick und informant schon mal darüber diskutiert. Welche Lösungen hier sinnvoll sind, darüber sollten wir sprechen. Eventuell pro User eine Tabelle / Datenbank oder welche Möglichkeiten auch immer. Vorschläge sind hier gerne willkommen.

    Ganz wichtig: Ein Update der SabreDAV-Integration. Die aktuelle Version macht wirklich Probleme bei Terminen, wenn man das über verschiedenen Geräte hinweg synchronisiert und managed.

    Ich hatte es schon mehrfach erwähnt: ich kann nicht programmieren. Wenn es aber jemand gibt der das mal in Angriff nehmen will, unterstütze ich wo ich kann.

    Meine aktualisierte Planungen für b1gMail 7.5:

    Kernprodukt sollte die E-Mail sein....

    Es wäre m.E. sinnvoll wenn man b1gMail, im Speziellen auch die Funktion E-Mail, unter Sicherheitsaspekten weiter entwickelt. Wenn man b1gMail mit Anbietern wie Proton oder Tuta vergleicht - die mittlerweile Millionen von Usern verzeichnen, fehlt uns etwas Entscheidendes, die Verschlüsselungsmöglichkeit. Dazu gibt es verschiedene Ansatzpunkte:

    - Vollständige Integration von PGP für den Mailaustausch
    - Daten verschlüsselt speichern, sowohl die Files als auch die Inhalte der Datenbank

    Tuta fährt hier einen sehr interessanten Ansatz, nämlich auch Open Source.

    Zumindest diskutabel, wie ich finde.

    Die letzte Version von Martin ist die 2.4.0 und funktioniert bis android-targetSdkVersion 31 (=Android 12). Hab meine Version schon an API 33 / Android 13 Stückweise angepasst. Ist aber alles nicht so einfach wenn man keine Ahnung hat :D

    Im Firebase Menü unter Cloud Messaging wird mir nun auch das angezeigt:

    Falls Sie bisher die HTTP API oder XMPP API (Legacy, wurde am 20.06.2023 verworfen) genutzt haben, müssen Sie bis zum 20.06.2024 zur aktuellen Firebase Cloud Messaging API (HTTP v1) migrieren.

    Die Legacy Api verwende ich scheinbar auch. Hab im Script bzw. in der App schon nachgesehen, wie das implementiert ist, werde aber noch nicht schlau draus. Eventuell können wir das ja zusammen angehen und herausfinden? Bis Juni 2024 ist nicht mehr so viel Zeit.