Mailversand scheitert nach Update auf ISPconfig_3.2: 554 5.7.1 Service unavailable; Client host [...] blocked using zen.spamhaus.org;

RalphGL

New Member
Nach dem Update von ISPConfig auf 3.2 kommt es beim Mailversand zu Schwierigkeiten. Nachvollziehbar wenn der Mail-Client über einen DSL-Zugang auf den ISPConfig-Mailserver zugreift und der Empfänger ein 1&1-Mailkonto nutzt. Der Fehler, den der sendende MUA (in meinem Fall thunderbird) beim Mailversand meldet. lautet:

Fehler beim Senden der Nachricht: Der Mail-Server antwortete:
554 5.7.1 Service unavailable; Client host [92.117.239.165] blocked using zen.spamhaus.org; https://www.spamhaus.org/query/ip/<hier steht meine dynamische IPv4 hier>
Bitte überprüfen Sie die E-Mail-Adresse des Empfängers "EMPFÄNGER-POSTFACH" und wiederholen Sie den Vorgang.

Sehe ich bei SPAMHAUS.ORG nach finde ich dort die Meldung:
"Outbound Email Policy of 1&1 Versatel Deutschland GmbH for this IP range:

It is the policy of 1&1 Versatel Deutschland GmbH that unauthenticated email sent from this IP address should be sent out only via the designated outbound mail server allocated to 1&1 Versatel Deutschland GmbH customers using SMTP-Auth. To find the hostname of the correct mail server to use, customers should consult the original signup documentation or contact 1&1 Versatel Deutschland GmbH Technical Support. "


Lösungsversuche:

1. Da eine Regel bei SPAMHAUS.ORG für die Nichtannahme der Mail durch den ISPConfig-Mailserver verantwortlich ist, habe ich den Eintrag "zen.spamhaus.org" aus dem Feld "Realtime Blackhole Liste" gelöscht. Leider löst das nicht das Problem. Der Fehler erscheint weiterhin.

2. Das Update hat wohl eine neue /etc/postfix/master.cf geschrieben und zahlreiche Einstellungen geändert. Aber wo sind diese Einstellungen definiert? Wie kann man sie beeinflussen? Und wie kann ich das konkrete Problem lösen?
Unsere Idee war nun, das ISPConfig-Template von master.cf manuell anzupassen, aber leider finden wir in install/tpl/ lediglich debian_postfix.conf.master, dies ist aber keine /etc/postfix/master.cf, sondern eine /etc/postfix/main.cf.

Bin ratlos und sehr dankbar für hilfreiche Tipps!
Ralph
 

RalphGL

New Member
Ja, das steht da. Die Frage ist:

Wie ändere ich es...
a) permanent (damit ISP-Config nicht die geänderte main.cf bei nächster Gelegenheit überschreibt);
b) für unauthenticated email Logins soll die Regel natürlich verwendet werden, nur nicht, wenn ich mich mit Authentifizierung per ssl/tls bei meinem eigenen Mailserver anmelde; dazu müsste der Eintrag doch in master.cf (und nicht in main.cf geändert werden), oder?
c) warum ignoriert ISPConfig den Eintrag "zen.spamhaus.org" aus dem Feld "Realtime Blackhole Liste und wie bekommt man ISPconfig dazu, dass diese Einstellung sich auswirkt?
 

Strontium

Member
Rauslöschen und Postfix neu starten

a) permanent (damit ISP-Config nicht die geänderte main.cf bei nächster Gelegenheit überschreibt);
Wenn du sagst "Dienste neu konfigurieren" beim Update von ISPConfig wird es (vermutlich) überschrieben, deshalb gibts ja auch ein Backup auf /var/backup/ispconfig_host.name_datum/etc.tar.gz
 

florian030

Well-Known Member
Du kopierst aus install/tpl z.B. debian_postfix.conf.master nach /usr/local/ispconfig//server/conf-custom/install und machst dann dort Deine Änderungen.
Wenn Du eine custom-config verwendest, musst Du diese dann aber selber pflegen und ggf. anpassen.
 

GourmetHH

New Member
Als langer Anwender von ISPConfig beginnend mit Version 2.X Ich habe seit dem Update auf 3.2 exakt das gleiche Problem. Habe mich nun einige Zeit mit White-/Blacklisting herumgeschlagen - nichts scheint zu funktionieren. Habe nun aus der main.cf "reject_rbl_client zen.spamhaus.org" gelöscht - damit wird aber auch nichts mehr gegen diese RBL gecheckt. Es wäre schön, wenn es für dieses Problem in ISPConfig Konfigurationsoptionen gäbe bzw. jemand einen Codeschnipsel für die main.cf hätte. Aber im Grunde will ich gar nicht in der Postfix Konfiguration basteln ...
 

florian030

Well-Known Member
Das "Problem" tritt nur auf, wenn der Mail-Client die Mails über den Port 25 verschicken will. Bei Verbindung über STARTTLS nimmst Du einfach Port 587, bei einer über SSL 465.
 

GourmetHH

New Member
Das "Problem" tritt nur auf, wenn der Mail-Client die Mails über den Port 25 verschicken will. Bei Verbindung über STARTTLS nimmst Du einfach Port 587, bei einer über SSL 465.
Das habe ich mir schon gedacht - aber die Endgeräte (IP-Kameras), welches die Mail verschicken sind schon etwas älter und können keinen TLS/SSL-Port - was in dem speziellen Fall auch kein Sicherheitsrisiko darstellen dürfte. Gibts trotzdem einen Hack?
 

RalphGL

New Member
Das "Problem" tritt nur auf, wenn der Mail-Client die Mails über den Port 25 verschicken will. Bei Verbindung über STARTTLS nimmst Du einfach Port 587, bei einer über SSL 465.
Nein, das von mir beschriebene Problem tritt beim Mailversand über Port 587 auf.

Wenn ich das Konzept von Postfix ein bisschen verstanden habe (ich habe kaum Ahnung davon), dann müsste in master.cf eine Regel definiert sein, die von der "Vorgabe" in main.cf abweicht. Deshalb ja meine Frage, wie man eine master.cf ispconfig-update-kompatibel anpassen kann.
 

GourmetHH

New Member
Das "Problem" tritt nur auf, wenn der Mail-Client die Mails über den Port 25 verschicken will. Bei Verbindung über STARTTLS nimmst Du einfach Port 587, bei einer über SSL 465.
Sooo ... das update hatte die main.cf offensichtlich verändert, sonst wäre bei mir das Problem nach dem update auf 3.2 nicht aufgetreten. Die Firmware der betreffenden Geräte konnte ich updaten, so daß die Einlieferung über TLS und SSL nun klappt. Die main.cf habe ich wieder um den Eintrag "reject_rbl_client zen.spamhaus.org" ergänzt. Jetzt läuft wieder alles wie gewünscht - Danke für den Tipp!
 

Werbung

Top