Beiträge von patrick

Die Mail mit der ID 98.120.000 liegt in 98/12/00/00.msg

ID 99.999.999 in 99/99/99/99.msg

ID 100.000.000 in 10/00/00/00/0.msg

Es geht also dann in Ordner 10/ weiter.

Zitat von Denny

Ich habe optimize auskommentiert das dauert halt immer, kann man ja danach noch machen, genau wie ich beim user löschen jetzt aktuell die spamindex nicht mit lösche, dauert auch immer. Das letzte mal habe ich die Kisten 0:00 ausgemacht und 05:00 morgens war das update von 7.2 auf 7.4 durch dabei war das lange Update bei b1gmail 7.3 und das auf 7.4 dauert nur paar Minuten, ich weiß ja nicht wie lange es dann auf 7.4.1 dauert aber bestimmt nicht lange

Die OPTIMIZE-Schritte kann man auch ruhig komplett aus dem Updater rauswerfen, denke ich. Kann ja jeder selbst entscheiden, wie und wann er mal die Tabellen optimieren lässt.

Vermute mal das liegt an der Verwendung von Windows, da dort Ausführungsrechte (chmod +x) nicht abgebildet werden können und dann den Weg nicht mit ins Ziel-Image finden...

Edit: Habe mal eine Änderung gepusht, die das beheben könnte...

Zitat von SLM

Verstehe ich. Das DB-Update könnte man aber auch manuell durchführen, wenn man die SQL-Anweisungen zur Verfügung hat. Damit könnte man zumindest den Fortschritt selbst steuern, eventuell ja schon vorbereiten, während man dann das Script updatet.

Das betrifft Systeme nicht die nur wenige Nutzer haben. Bei mir klingeln sämtliche Kanäle, wenn das System mal ne halbe Stunde nicht zur Verfügug steht.

Oft gibt es leider keine statischen Queries für das Update sondern es handlet sich um kompizierte Logik (z.B. wenn Daten konvertiert werden müssen). Ansonsten stimme ich zu, dass man zumindest für die 'ALTER TABLE'-Queries im Updater auch eine Liste ausgeben könnte.

Ein DB-Update im Hintergrund ist schwierig, da der neue Code ja schon das geänderte Schema vorausetzt. Man müsste die Änderungen dann immer abwärtskompatibel halten und bis zum Abschluss die vorherige Version weiter betreiben. Gerade wenn Backfilling neuer Felder nötig ist, ist das u.U. nicht ganz trivial, da die Daten während des Updatevorgangs weiterhin "lebendig" sind und sich verändern...

Ein möglicher Schritt zu einem stabileren Update wäre es aber, eine Kommandozeilen-Version des Updaters zu erstellen, die nicht durch Timeouts etc beeinträchtigt wird und nicht von einer Browsersitzung abhängt. Bei etwaigen Fehlern könnte man weiterhin ein Token ausgeben, mit dem die Fortsetzung möglich ist (was auch schon beim Web-Updater eine realisierbare Sache wäre).

Ich würde das Feld einfach weglassen, handhabe ich mittlerweile eigentlich überall so und habe noch keine Nachteile bemerkt. Man muss die Anrede in Schriftverkehr dann halt generisch halten, was aber meistens kein Problem ist.

Zitat von braechtli

OK, ich denke es liegt an den RBL's, offenbar war der lokale Resolver ausgefallen und es wurde der von cloudflare verwendet, vermutlich blockte da Spamhaus wegen zu vielen Anfragen über public resolvers.

Wie bringt man b1gmailserver dazu RBL Anfragen zu loggen?

In den Debug-Logs sollte das genauer stehen.

Ich kenne diese Spezifikation: https://github.com/avar/sendmail-…er-protocol.txt

Weiß jemand, wo man die Specs für neuere Versionen bekommt?

Moin,

da gibt's nun ein Docker-Compose-Projekt, mit dem das recht einfach gehen sollte. Schaut euch mal die aktuelle Readme an.

Zitat von Loadbox

Hallo zusammen!

gibt es eigentlich bis jetzt eine Möglichkeit DKIM zu nutzen mit B1gmail oss?

wenn ja würde ich mich über Infos freuen

Ja, per OpenDKIM, genau wie in der letzten proprietären Version.

Die aktuelle OSS-Version von b1gMailServer läuft auch mit der letzten nicht-OSS-Version von b1gMail.

Da wird geprüft, ob der Reverse-DNS-Eintrag der IP-Adresse des Servers auf der Gegenseite auch dem HELO-Hostnamen entspricht. Mit dem Absender der Mail hat das erstmal nicht zu tun, nur mit korrekter Konfiguration der Gegenseite, sowohl bzgl. Mailserver-Config als auch bzgl. DNS.

Hetzner Cloud, 4 vCPUs, 16 GB RAM, 160 GB NVMe, 1 GBit/s-Anbindung, statische IP die nicht als Dial-Up klassifiziert ist, keine Investitionskosten, kein Stress mit Hardwarewartung, USV + Klimatisierung, kein Lärm und keine Stromkosten zuhause, 20,11 EUR/Monat + 20% für vollautomatische tägliche Backups ohne Beeinträchtigung des Serverbetriebs

Gibt nun einen weiteren Patch (Build 3300), der SPF-Probleme bei Mails von Domains mit sehr langem SPF-Record behebt (z.B. von Amazon / SES).

core/dns: Increase buffer size · b1gMail/b1gMailServer@f2c64dc

Contribute to b1gMail/b1gMailServer development by creating an account on GitHub.

github.com

COPY-Kommando hatte einen Bug durch das OSS-Refactoring. Fix gibt's hier: https://github.com/b1gMail/b1gMai…runs/4689440930

Dann scheint das Problem zu sein, dass Verschieben nicht klappt. Dein Client verschiebt die Mails, und nutzt nicht die Löschkommandos von IMAP. Hat mit Löschen direkt also erstmal scheinbar nichts zu tun. Ich versuche mal, das hier nachzustellen.

Es ist Sache des Clients, wie er beim Löschen vorgeht. Der IMAP-Server hat Mails noch nie automatisch beim Löschen verschoben.

Die TLS-Negotiation geht ja durch, daran sollte es also nicht liegen. Warum auf MS-Seite die Verbindung beendet wird, kann man so leider nicht sehen. Bekommst du denn eine Fehlermail zurück? Darin sollten sich Details finden lassen.

Zitat von Sebijk

Da patrick ihn aktuell pflegt, sollte man am besten ein Ticket unter https://github.com/b1gMail/b1gMailServer/issues aufmachen.

Bei IMAP erhalten gelöschte Mails ein entsprechendes Flag und werden nicht automatisch in einen Ordner verschoben. Das ist im Protokoll so vorgesehen und war auch schon immer so...