Bitte den Text eindeutig als KI-generiert bezeichnen.
Den Text hab ich aus meiner Doku so generieren lassen, wir sind doch intern oder ist der Thread extern lesbar? Weil die Daten sind aus meiner Doku nur aufgearbeitet durch KI bzgl. struktureller Ansicht. Sofern der Thread öffentlich ist, dann werd ich das zukünftig kennzeichnen, intern braucht man das nicht, wenn es keine reine KI Ausgabe ist. Satz für KI Aufarbeitung ist als Hinweistext hinzugefgt worden!
Das Problem mit den Sessions kenne ich. Ich hatte da ein Skript am laufen, dass diese Einträge in dem Session-Ordner monatlich löscht. Mittlerweile hab ich den Ordner nur noch als tmpfs eingebunden, so dass es spätestens mit dem Restart leer ist.
das die sessions gecleant werden stellt man in der php ini ein^^ sonst schmeißt du ja alle einfach raus
cleaning alle 1000 aufrufe sollte man machen. das ist ideal.
########################################################################
Mit deinen Einstellungen (gc_probability = 1 und gc_divisor = 1000) hat jeder 1.000ste Seitenaufruf (0,1 % Chance) das Recht, den Ordner komplett nach abgelaufenen Sessions zu durchsuchen und diese zu löschen.
Wie viele Dateien letztendlich im Ordner liegen bleiben, bestimmen zwei Faktoren:
1. Die Lebensdauer der Sessions (session.gc_maxlifetime)
Standardmäßig löscht PHP nur Sessions, die älter als 1440 Sekunden (24 Minuten) sind.
2. Dein Besucheraufkommen (Traffic)
Fazit
Wenn deine Website nicht gerade zehntausende aktive Nutzer gleichzeitig hat, werden weit weniger als 35.000 Dateien im Ordner liegen bleiben. Bei normalen Websites sinkt die Zahl meist auf ein paar Hundert bis wenige Tausend aktive Sessions.
Möchtest du den Befehl wissen, mit dem du die genaue Anzahl der aktuell angesammelten Session-Dateien im Ordner auslesen kannst, um den Vorher-Nachher-Vergleich zu sehen?
Hinweis. Dieser Text wurde aus meiner Dokumentation durch eine KI aufgearbeitet, damit er für Euch leichter verständlich ist!
Alles anzeigenMeine technische Einschätzung:
"Timeout while connecting socket" kommt vom b1gMailServer-Queue-Dienst beim Aufbau der ausgehenden TCP-Verbindung zum Ziel-MX/Relay, nicht von PHP oder pipe.php. Die PHP-Version steuert die SMTP-Verbindung nach aussen nicht.
Unsere bisherigen Änderungen an Auth/pipe.php würden eher Fehler im Bereich Pipe/Inbound verursachen, nicht diesen Connect-Timeout.
Eine stark wachsende Queue kann entstehen durch:
- Zielserver, die Verbindungsversuche einfach „droppen“
- mehrere MX-/A-Records × 60 s Timeout pro Versuch
- blockierte Worker durch hängende Outbound-Verbindungen
Ich würde testweise ein betroffenes Ziel direkt vom Server prüfen:
Codedig +short MX beispiel.ch nc -vz -w 5 mx1.beispiel.ch 25 time nc -vz -w 65 <IP> 25
Sind immer dieselben Domains/IPs betroffen und dauert der Connect tatsächlich ~60 Sekunden?
Rein der Wechsel PHP 7.4 > 8.4 sollte diesen TCP-Connect-Timeout normalerweise nicht verursachen.
Hi Netzwerkebene passt alles bei Claus, ich vermute das es etwas mit PHP zu tun hat, da PHP 8 ja strikter agiert als php 7 und damit ggf, einiges an verbindungen oder TLS anders anfasst. Oder im B1GMailServer selber ist im Zusammenhang mit php 8 etwas anders, was noch angepasst werden muss.
Claus sein System wurde komplett auf die neue Debian Trixie umgstellt, also nicht nur PHP. Aber Systemseitig ist alles getestet. Ich habe zum Test PHP7 parallel getestet, damit geht es. Nur PHP 8 nicht. Daher ein Zusammenhang B1GMSzu PHP8.
Was du machst ist verboten! Das filtern die auch raus, Ist eine Frage bis die dich sperren. So als Info...
Das ist möglich, ich prüfe, daran hab ich garnicht gedacht. Danke
Ich verstehe leider nicht, was du damit bezwecken willst.
Die landen in der Queue aber können nicht zugesellt werden. Daher würd ich die dann gleich blocken per Filter, da zu 99% auch kein Empfänger enthalten sind, zumindest das was ich bisher gesehen habe. Wenn der leer ist udn ein Empfänger vorhanden ist stellt er Sie zu. Oft kommt das von Mailing Servern. Daher hatte ich die Frage gestellt.
ps: Denny warum baust du dir das nicht so wie du willst oder machst nen extra Thread dazu im Thema: gewünnschte Features oder so...?
Akso einen Filter für MAIL FROM:<> delete erstellen? Denn Bounce Filter erkennt das ja nicht.
Hi es kommen ja immer wieder Anfragen mit MAIL FROM:<> an. Könnte man die nicht gleich im BMS blocken/ablehnen?
Hat jmd, eine Lösung gefunden? Wir leider bisher nicht.
Welcher Fehler steht denn im Log bei B1G? Hast du die cron.php im cronjob aktiviert alle 5 Minuten abruf? Catchall = *.domain.endung ?
MfG
Fehlerhafte sind normalerweise lt. Norm auch nicht vorhandene. Jedoch wird dann der EIngang an eMail sum >= 90% schrumpfen, da soviele keinen SPF haben lt. Statisik.
gibt es doch schon.
B1GmailServer => SMTP => Sender Policy Framework (SPF) => letzter Haken
MfG
Hast du ggf. ein anderes Plugin installiert was User verschieben kann? Wenn nein dann speichert dein ACP die Daten nicht korrekt in der DB. Schau doch mal nach dem speichern im ACP ob der Eintrag in der DB korrekt ist.
Also ext 4 kann 64.000 Unterordner pro Ordner, dh in einem ordner 64k darin in jedem weitere 64k darin weiter 64k usw. also da hast du noch viel viel viel Platz 
Was wichtig und ein bereits mehrfach angesprochenes Thema ist, dass die mails Tabelle pro Nutzer sein sollte, da diese die einzige Grenze und Problematik bei großen Instanzen ist, welche oft zu Problemen führt. Das jedoch aufsplitten ist nicht so einfach, haben wir ja schon mit Patrick und Co im Forum mal diskutiert. Wobei mir die Idee gekommen ist, ob man ggf, parallel 2 GGleisig baut, die alte mails Tabelle bis Stand x und ab Version y pro User eine Mails Tabelle und die alte als Lesezugriff einliest, Habe mir den Code dazuz noch nciht genau angechaut. Der BMS müsste daraufhin dann jedoch abenfalls angepasst werden. Dazu sopllten wir ggf. nochmal einen Thread eröffnen und alles sammeln was diese Problematik angeht.
Das ist ja nicht das Endlimit 
Kenne Systeme die sind schon weit drüber^^ Wie kommst du denn auf das Endlimit und das es danach nicht mehr geht?
Ne wie ich geschrieben habe, ist das derzeit so nicht nutzbar, der Zugriff ist scheinbar anders, TCP geht irgendwie nicht mehr.
Sofern die Storage nicht per nfs oder Netzwerk oder sonstiges eingebundne ist kann man das machen, sobald Netzwerk im Spiel ist geht das nicht, da sqllite das nicht unterstützt!
DH direkt attachet via SAS Kabel o.ä. klappt problemlos.
Hoffe diese Info hilft euch^^
clamav lauscht schon immer auf tcp 3310^^
Ich habe bisher keine Idee es zum laufen zu bekommen. Versuche das schon seit meinem Post hier im Forum. Workarounds klappen leider nicht. Alternative für Singel Server Systeme habe ich bisher keine gefunden, und größere könnten den Proxmox Mail GW nutzen.
ClamAV läuft aktuell im Debian nicht mehr mit TCP zusammen, B1G bekomtm keien Verbindung merh zu ClamAV da dort was geändert wurde in einem Update. Die Infos aus dem Netz greifen alle nicht.
Die eMail Adressen sind mit IDs versehen, damit arbeitet das ganze B1G System. Da kann man ncith einfach drin hin und her exportieren. Wenn dann soltlest du alle Daten aus Kundenspeziefischen Tabellen löschen und alle importieren, dann klappt das auch. Besser wäre es aberm wenn du was imporieren willst, das du das mit einer CreateUser Funktion machst, dann werden alle Daten korrekt in den DBs angelegt. Einfach nen Script schreiben und die exportierte Datei damit einlesen.
