ls /pfad/zu/b1gmail/temp/session/ | wc -l
42917
find /pfad/zu/b1gmail/temp/session/ -type f -size 0 | wc -l
39220
-> Das ändert sich natürlich laufend.
ls /pfad/zu/b1gmail/temp/session/ | wc -l
42917
find /pfad/zu/b1gmail/temp/session/ -type f -size 0 | wc -l
39220
-> Das ändert sich natürlich laufend.
Bzgl. IPv6 hab mal im alten Forum geschaut: https://board.b1gmail.com/threads/b1gmail-server-ipv6.15813/
Also bekannt ist, dass BMS mit IPv6 Mails empfangen kann, aber die Auslieferung ausschließlich mit IPv4 erfolgt. Um es ein wenig einzugrenzen: Geht es bei den E-Mails in der Warteschlange um eingehende oder ausgehender oder um beides?
Tatsächlich geht es um beides. Ganz normale Newsletter (z.B. von großen Versandhäusern etc.) verbleiben plötzlich in der Warteschlange, die vorher normal abgearbeitet wurden - und werden zum Teil nicht mehr zugestellt.
DNSBL unter b1gMail > E-Mail > Anti-Spam ist in meinem System noch nie aktiv gewesen, DNSBL ist schon immer direkt im BMS als Zonen angelegt.
Mein Setup ist ja insofern auch nochmal anders, da der BMS auf einem eigenen Server läuft, der per interner IP angebunden ist. Aber genaueres dazu weiß informant
Ich habe gelesen, dass PHP 8.x IPv6 bevorzugt. Könnte sich der BMS hier eventuell "verschlucken"? Kann er eventuell nicht so viele gleichzeitige Verbindungen verarbeiten?
Nach dem Update von PHP 7.4 auf PHP 8.4.24 verbleiben täglich mehr Mails länger in der Warteschleife als vorher. An der prinzipiellen Serverkonfiguration IPv4/IPv6 hat sich nichts geändert, es treten aber im Gegensatz zu vorher vermehrt "Timeout while connecting socket"-Fehler auf. Vor der Umstellung befanden sich meist ca. 10-20 Mails in ruhigen Zeiten in der Queue, aktuell sind es permanent 130-180. Mal von den üblichen Verdächtigen falsch geschriebenen Adressen oder tatsächlich nicht erreichbaren Postfächern abgesehen, bleibt trotzdem eine zu hohe Zahl übrig.
Das sind die früheren und aktuellen Queue-Einstellungen:
Verarbeitungs-Intervall: 300 Sekunden
E-Mail-Zustellversuch-Intervall: 3 Minuten
Maximale E-Mail-Lebensdauer: 48 Stunden
Verarbeitungs-Timeout: 60 Sekunden
Threads (initial / maximal): 5 / 25
Hat jemand zufällig ähnliche Erfahrungen bei der PHP-Umstellung gemacht?
Die Aussage stammt direkt vom Kunden. Sinngemäß: "Es liegt am Nachnamen: Jäger - Testweise habe ich meinen Namen mit ae geschrieben - und es funktioniert." Nachdem ich den Forenbeitrag hier verfasst hatte, habe das selbst nochmal mit einem Test überprüft, konnte Mails problemlos versenden. Daher gehe ich davon aus, dass eventuell das Thunderbird-Setup des Kunden einen Fehler hat, auch wenn er - eigenen Angaben zufolge - mehrere Konten anderer Anbieter mit diesem Client betreibt.
Unabhängig davon, das Umlautproblem bei der Ordnersynchronisation besteht tatsächlich, das konnte ich mehrfach reproduzieren.
Danke patrick für deine schnelle Antwort.
Im b1gMailserver - Git hatte ich dazu schon ein Issue aufgemacht: https://github.com/b1gMail/b1gMailServer/issues/24
Heute kam ein Problem eines Nutzers, der im Nachnamen einen Umlaut hat. Es betrifft scheinbar auch den SMTP, denn der Nutzer konnte mit Thunderbird 153.0.x keine Mails versenden. Grund: Umlaut im Namen (nicht in der E-Mailadresse).
Meine KI meint, dass macOS UTF-8 verwendet, während der b1gMailserver das noch nicht unterstützt.
Könnte sich das patrick eventuell mal ansehen? Danke.
Ist eventuell geplant DMARC‑Enforcement zu implementieren, also die serverseitige Entscheidung über Zustellung, Quarantäne oder Ablehnung basierend auf SPF/DKIM‑Alignment und der veröffentlichten DMARC‑Policy der Absenderdomain? Eine native Unterstützung wäre sehr hilfreich, um Spoofing‑Mails zuverlässig zu blockieren und die Sicherheit weiter zu erhöhen.
Ist das schon bekannt?
Hat der b1gMailServer schon die Möglichkeit implementiert, nur die IP-Adressen beim Zugriff auf POP3/SMTP/IMAP zu speichern? Wenn man "Hinweise loggen" aktiviert, werden zu viele Daten gespeichert, die die Logs nur aufblähen. Eine separate Darstellung oder die Möglichkeit, diese IP-Adressen zu filtern wäre notwendig.
Der Grund meiner Frage: Trotz konservativ eingestellter Abusefilter ist es nicht möglich herauszubekommen, ob ein User mehrere Accounts betreibt, die nur per POP3/SMTP/IMAP zugreifen. Bei der Registrierung werden heute oft Tor- oder VPNs genutzt, das ist auch in Ordnung so. Ich gehe aber davon aus, dass Spammer bei SMTP-Nutzung keine unterschiedlichen VPNs nutzen. Erst kürzlich habe ich per Zufall fast 50 Accounts gesperrt, die ähnliche Muster aufwiesen und innerhlab der Abuseregeln, aber permanent Spam versendet haben. Das ist für die DNSBL-Reputation der eigenen IP-Adressen nicht förderlich.
Kannst du das Verhalten in eine Testumgebung verifizieren und den Debug-Modus einschalten?
Selbst die KI hatte damit Schwierigkeiten den Fehler zu finden. Wurde der Inhalt wieder angezeigt, waren plötzlich die Zertifkate ungültig usw. Scheinbar entspricht das Verfahren und die Struktur, wie S/MIME Zertifikate in b1gMail verwaltet werden, nicht (mehr) so ganz dem heutigen Standard. Ich habe unter Zuhilfenahme der KI eine Lösung gefunden, dazu wurden aber einige Bibliotheken (u.a. auch die smime.class.php) in weiten Teilen geändert. Daher kann ich das hier auch nicht so zur Verfügung stellen.
Eventuell lag es auch an meiner eigenen b1gMil-Instanz, die im Lauf der Jahre immer wieder angepasst und mit Features erweitert wurde, die nicht Standard in b1gMail sind.
Eventuell kannst du ja trotzdem mal prüfen, ob das generell so ist. Bei Actalis kann man sich noch kostenlose (zeitlich befristete) S/MIME-Zertifikate erstellen, falls das jemand testen möchte.
Danke.
Seltsames Verhalten:
E-Mails digital signieren -> funktioniert -> E-Mail kommt lesbar beim Empfänger an
E-Mails nur verschlüsseln -> funktioniert -> E-Mail kommt lesbar beim Empfänger an
E-Mails digital signieren UND verschlüsseln -> funktioniert nicht -> Inhalt kann vom Empfänger nicht gelesen werden (wird nicht angezeigt).
S/MIME-Zertifikate des Kunden sind neu, selbst mit neuen Zertfikaten getestet - gleiches Ergebnis.
Könnte das bitte mal jemand verifizieren?
Ehrlich gesagt, auf ein paar Unbelehrbare sollte man keine Rücksicht mehr nehmen. Jeder seriöse Provider hat heute zumindest DKM/DMARC und SPF aktiviert.
Google, Yahoo und auch GMX setzen seit Anfang 2024 SPF/DKIM/DMARC voraus, damit sie E-Mails überhaupt verarbeiten:
Richtlinien für E-Mail-Absender - Google Workspace-Admin-Hilfe
https://postmaster.gmx.net/de/best-practices#:~:text=Um%20die%20Sicherheit%20und%20Vertraulichkeit,From%2DDomain%20(RFC%205322.
Zu klären wäre aus meiner Sicht, in welchen Fällen
| Bei fehlgeschlagener Prüfung: | E-Mail ablehnen |
greift.
- Received-SPF: SoftFail
- Received-SPF: Fail
- Received-SPF: Pass
- Received-SPF: Neutral
- Received-SPF: None
Wobei ich bei Stichproben festgestellt habe, dass die meisten Spamversender lustigerweise einen korrekten SPF Eintrag gesetzt haben, der mit SPF: Pass quittiert wird.
Danke Sebijk. Das Zertifikat habe ich erstellt und im IMAP -> Apple Push-Service hinterlegt, danach den BMS neu gestartet. In iOS Mitteilungen, Kennzeichen aktiviert, Push für das Konto aktiviert.
Als Gateway steht im b1gMailserver: gateway.push.apple.com - Port 2195. Apple selbst scheint aber mittlerweile eine andere API zu verwenden: https://developer.apple.com/documentation/…equests-to-apns
Beide Gateways habe ich getestet, jedoch ohne Erfolg. Hat das jemand tatsächlich am Laufen?
Ich möchte nochmal ein Thema aufgreifen, das im alten Forum schon diskutiert wurde: https://board.b1gmail.com/threads/imap-i…481/#post-88338
patrick schrieb damals:
"Wir unterstützen IMAP IDLE, die Mail-Anwendung von iOS aber leider nicht.
(Push wird da über eine proprietäre IMAP-Erweiterung XAPPLEPUSHSERVICE realisiert. Um da mitmachen zu dürfen, braucht man ein spezielles Zertifikat von Apple.)"
Mittlerweile kann man unter developer.apple.com verschiedene Zertifikatstypen bzw. Identifier anlegen. Lässt sich damit etwas anfangen, oder gibt es mittlerweile eine andere Lösung?
Bei großen Postfächern steigt b1gZIP (z.B. bei "Alle herunterladen") regelmässig aus, klar, es liegt auch an den eigenen Serverbeschränkungen. Hierfür bräuchte man eine andere Lösung. Wie könnte man das umsetzen?
Ist es möglich, im b1gMailserver eine Whitelist für bestimmte Adressen oder Domains einzurichten? Hat das eventuell jemand sogar in Betrieb?
Wenn wir beim Thema Backup sind: Die zentrale Speicherung aller Mails bzw. Mail-Rumpfdaten in 1 Tabelle ({pre_mails) ist fatal. Das sollte man im Zuge der npassung ebenfalls ändern.
Es könnte aber auch an der mail.class.php liegen. Auf meinem lokalen Testsystem (xampp) schlichen sich beim Mailversand und Empfang Fehler ein, die ich mir nicht erklären konnte. Erst nachdem ich die Version aus der 7.4.0 wieder verwendete, waren die Fehler wieder weg. Habe aber noch nicht herausgefunden, woran das liegt. Aktuell stelle ich Datei für Datei meines Systems auf die OSS-Version um und teste auch noch unter PHP 7.4. Aber das muss ja zumindest mit PHP 7 noch abwärtskompatibel sein. Und solange das nicht funktioniert werde ich nicht umstellen.
Das betrifft noch b1gMail-Version 7.4.0, eventuell ist das in b1gMail 7.4.1 bereits behoben?
Der Import und Einbindung eines CalDAV-Kalenders in MacOS bringt eine unerklärliche Fehlermeldung. Die Verbindung zu meinem System lässt sich problemlos herstellen, der CalDav-Kalender wird auch im MacOS-Kalender angezeigt, allerdings mit einem Warnhinweis:
Dein Kalender konnte nicht aktualisiert werden. Der Kalender "Calendar" konnte aufgrund eines unerwarteten Fehlers nicht aktualisiert werden. Der Zugriff auf "Calendar" im Account "Demo" ist nicht gestattet.
Mit allen anderen Clients (z.B: Thunderbird, Outlook etc.) funktioniert die CalDAV-Verbindung, auch mit iOS 18, nur mit MacOS nicht.
Kurzfristig hat es geholfen, den Schalter "Kalender" im Menü MacOS Kalender > Internetaccounts > (Demo-)Kalender aus und wieder einzuschalten. Bei der nächsten Synchronisation war das Problem aber wieder da.
Termine werden seltsamerweise aber synchronisiert.
MacOS oder CalDAV-Problem?
- SabreDAV Version 3.0.9
„Internes Idle-Protocol“ ist auf 5 Sekunden eingestellt.
Manchmal macht es sich auch so bemerkbar. Ich öffne die iOS Mail App, dann wird die erste Zeile geladen. Beim 2. oder 3. Aktualisierungsversuch wird dann die 2. Zeile angezeigt. Vorschau ist eingestellt auf 2 Zeilen.
Das tritt auch nicht immer auf. Deshalb schwer nachzustellen.