Beiträge von informant

Wir erhielten oft die Anfrage, ob es ein Zusatzfeld für Rechnungs eMail Adresse geben wird und dazu als Option ein Feld Für eine Kundenindividuelle ID/Kennung zu dieser Rechnung, da viele automatisiert arbeiten. Das wäre noch ein gutes Feature, das die Rechnung an die abweichende Rechnungs eMail geht mit Zusatzfeld persönliche Kennung die auf der Rechnung mit ausgegeben wird/im Rechngseditor dann nutzbar ist.

Sperrlimit eMail Info für bezahl KDs, bei 70 80 90% vor Erreichen des Limits and die eigene eMail sowie wenn vorhanden an alt. eMail Adresse. Aktivierbart in der Gruppen Option.,

Eine Tabelle für alle eMails eines Nutzer, statt alle eMails in einer MAIL Tabelle für alle Nutzer.

Also ich habe mal getestet. Mit PHP 7.* klappt es, mit PHP8.2 auch, ab PHP8.4 nicht mehr. Ab hier wird strict genutzt. Im BMS code sind noch alte Codezeilen wo er sich aufhängt und die PHP PIPE Prozesse abbricht. Ich denke und vermute also, dass der Code noch auf PHP8.4 und höher strict angenpasst werden muss (BMS).

Nach etwas nachdenken ist mir eine Idee gekommen. Auf dem einzelnen MAIL SRV liegen ja noch alte PHP Dateien, die habe ich mal mit dne neuen überschrieben, siehe da, es funzt wieder

Zitat von Sebijk

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!

Zitat von Sebijk

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.

• Alle Dateien von Benutzern, die innerhalb der letzten 24 Minuten auf deiner Website waren, bleiben garantiert liegen.
• Nur die Dateien von Benutzern, die länger als 24 Minuten inaktiv sind, werden beim nächsten GC-Durchlauf gelöscht.

2. Dein Besucheraufkommen (Traffic)

• Wenig Traffic: Wenn deine Website nur alle paar Stunden aufgerufen wird, triggert der Garbage Collector selten. Es kann sein, dass der Ordner zeitweise auf ein paar tausend Dateien anwächst, bevor der nächste "Putzdienst" anspringt.
• Hoher Traffic: Bei konstant vielen Besuchern wird die 0,1 %-Chance sehr oft getroffen. Der Ordner wird quasi durchgehend sauber gehalten. Es liegen dann fast nur noch die Sessions der aktuell aktiven Nutzer im Ordner.

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!

Zitat von ManDal

Meine 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:

Code

dig +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.

Alles anzeigen

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

Zitat von patrick

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.