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.
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?