Den Beitrag habe ich gesehen.
Wir legen nun mit der Implementierung von Milter v6 los, als Basis wird https://github.com/b1gMail-OSS/b1gMailServer verwendet.
Sollen wir das Resultat als PR schicken?
Den Beitrag habe ich gesehen.
Wir legen nun mit der Implementierung von Milter v6 los, als Basis wird https://github.com/b1gMail-OSS/b1gMailServer verwendet.
Sollen wir das Resultat als PR schicken?
Unser Mail-Projekt läuft noch immer auf einem uralten Cluster mit b1gMail 7.3. Die Betriebssysteme darunter haben seit Jahren keinen Support mehr, deshalb haben wir uns für einen kompletten Neuaufbau entschieden.
Momentan sind Proxmox Mail Gateways vorgeschaltet. Die erfüllen unsere Ansprüche aber bei weitem nicht. Deshalb möchten wir künftig rspamd einsetzen, den wir sonst schon auf Dutzenden unserer eigenen Server verwenden.
Das Problem ist der b1gMailServer: Er unterstützt das Milter-Protokoll nur bis Version 2, rspamd setzt aber Version 6 voraus. Wir haben uns deshalb entschieden, Version 6 selbst zu implementieren.
Bevor wir loslegen: Hat sich schon jemand damit beschäftigt? Gibt es vielleicht einen Patch oder Fork, der uns die Arbeit erspart?
Wie stabil ist das bereits? Ich muss meinen Cluster von Version 7.3, der noch unter CentOS 6 mit PHP 5.3 läuft, dringendst mal migrieren.
Da ich um ein Redesign wohl nicht herumkomme, möchte ich gleich mit einem möglichst sauberen Template beginnen.
Hatte ich auch, wollte ein Testsystem aufsetzten, habe die Einstellungen vom alten übernommen.
Nachdem ich nun meine rspamd Lösung soweit am laufen habe habe ich das Problem das nur mit Protokoll Version 2 angefragt wird:
2023-11-17 20:40:09 #1172(rspamd_proxy) <240f5e>; proxy; proxy_accept_socket: accepted milter connection from 1.2.3.4 port 50272
2023-11-17 20:40:09 #1172(rspamd_proxy) <240f5e>; milter; rspamd_milter_process_command: MTA specifies too old protocol: 2, aborting connection
2023-11-17 20:40:09 #1172(rspamd_proxy) <240f5e>; proxy; proxy_milter_error_handler: abnormally closing milter connection from: 1.2.3.4:50272, error: invalid protocol version: 2
2023-11-17 20:40:13 #1172(rspamd_proxy) <7e8130>; proxy; proxy_accept_socket: accepted milter connection from 1.2.3.4 port 50856
2023-11-17 20:40:13 #1172(rspamd_proxy) <7e8130>; milter; rspamd_milter_process_command: MTA specifies too old protocol: 2, aborting connection
2023-11-17 20:40:13 #1172(rspamd_proxy) <7e8130>; proxy; proxy_milter_error_handler: abnormally closing milter connection from: 1.2.3.4:50856, error: invalid protocol version: 2
In https://github.com/b1gMail-OSS/b1…c/smtp/milter.h sehe ich "#define MILTER_VERSION 2"
rspamd lässt sich auch über lua Script nicht dazu bewegen Verbindungen mit Version 2 anzunehmen.
In https://github.com/rspamd/rspamd/…internal.h#L156 steht das nur Version 6 supported ist.
rsapmd ist im "Self-Scan-Modus" konfiguriert
Irgendwer eine Idee?
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?
Seit paar Wochen haben wir plötzlich das Problem das nichts mehr angenommen wird was nicht als Regel erfasst wurde, das System lehnt grundsätzliche alles mit der Meldung: "transaction rejected due to dial-up peer" ab.
Beispiel:
SMTP #3400107 - [149.72.241.110] Disconnected (inbound: 0 / outbound: 0)
SMTP #3400107 - [149.72.241.110] QUIT
SMTP #3400107 - [149.72.241.110] Error: 530 5.7.1 Authentication required
SMTP #3400107 - [149.72.241.110] MAIL (transaction rejected due to dial-up peer)
SMTP #3400107 - [149.72.241.110] MAIL FROM:<bounces+1534741-3e17-kratxyz.de@em5513.spy-casino.info> BODY=8BITMIME
SMTP #3400107 - [149.72.241.110] EHLO wrqvfksz.outbound-mail.sendgrid.net
SMTP #3400107 - [149.72.241.110] TLS negotiation succeeded
SMTP #3400107 - [149.72.241.110] STARTTLS
SMTP #3400107 - [149.72.241.110] EHLO wrqvfksz.outbound-mail.sendgrid.net
SMTP #3400107 - [149.72.241.110] Connected
Die Sender Ranges müssen in Verbindungs-Klassifizierung -> Subnetz-Regeln erst erfasst werden.
Der Standard in den Subnetz-Regeln ist "Nicht vertrauenswürdig".
Unter "Einschränkungen für nicht-vertrauenswürdige Verbindungen" ist folgendes erfasst:
Verbindungs-Verzögerung: 0 Sekunden
Verzögerung bei Fehler: 1 Sekunden
Fehler-Soft-Limit: 10
Fehler-Hard-Limit: 20
Wie kommt das mit dem "dial-up peer" zustande obwohl das niergends erfasst wurde?
Version 2.8.3283
Danke für Tipps!
Ich habe gerade unseren b1gmail Cluster auf neue Hardware migriert und wieder einmal festgestellt, wie viel Müll reinkommt.
Auf unseren anderen Systemen nutzen wir rspamd mit über Jahre erstellten Filtern, die 99% des Spams aller anderen Mailserver stoppen. Würde das gerne mit b1gmailserver koppeln, hat das schon mal jemand gemacht?