RBL schlägt an - remote client steht in whitelist
Hallo Leute,
das ist meine erste Mail an diese Liste.
Die meisten postfix-Kenntnisse habe ich von einem Workshop für Libreoffice Admins mit Patrick in München. Ich hoffe, Patrick, ich mach' Dir keine Schande. ;o))
Jetzt zu meinem Anliegen:
Unser Postfix schert sich nicht darum, dass ich ihm die t-online mailouts in meiner bypass_access als gut gekennzeichnet habe. Mails von diesen fängt immer wieder mal der hostkarma Blacklistdienst ab.
Logmeldung:
Jul 5 00:22:16 tesla postfix/smtpd[6725]: connect from mailout09.t-online.de[194.25.134.84] Jul 5 00:22:16 tesla postfix/smtpd[6725]: NOQUEUE: reject: RCPT from mailout09.t-online.de[194.25.134.84]: 554 5.7.1 Service unavailable; Client host [194.25.134.84] blocked using hostkarma.junkemailfilter.com; Black listed at hostkarma http://ipadmin.junkemailfilter.com/remove.php?ip=194.25.134.84; from=fxxxxxxxxxxxx@t-online.de to=fyyyyy@wueste-welle.de proto=ESMTP helo=<mailout09.t-online.de>
# postconf -n | grep restrictions smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/bypass_access reject_unauth_pipelining reject_unknown_client_hostname smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated check_helo_access hash:/etc/postfix/bypass_access reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_helo_hostname smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_recipient_access hash:/etc/postfix/bypass_access reject_unauth_destination reject_unauth_pipelining reject_non_fqdn_recipient reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_recipient_domain reject_unlisted_recipient reject_unknown_address reject_rbl_client ix.dnsbl.manitu.net reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2 smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated check_sender_access hash:/etc/postfix/bypass_access reject_non_fqdn_sender reject_unknown_sender_domain reject_unverified_sender
Meine (gekürzte) /etc/postfix/bypass_access: ... t-online.de OK
# Telekom lt. Website .. 194.25.134.84 OK ...
Was hindert den postfix die Auswertung der bypass_access in meinem Sinne auszuführen? Weitere Anregungen, Kritik oder RTFM sind hochwillkommen.
Reichen die Auszüge oder wird mehr gebraucht?
Gruß
Hallo Friedrich,
On 05.07.19 01:42, Friedrich Strohmaier wrote:
Unser Postfix schert sich nicht darum, dass ich ihm die t-online mailouts in meiner bypass_access als gut gekennzeichnet habe.
nur zur Sicherheit: die Map hast Du aber gebaut, oder?
Gruß Markus
Hi Markus, *,
Am 05.07.19 um 22:17 schrieb Markus Winkler:> On 05.07.19 01:42, Friedrich Strohmaier wrote:
Unser Postfix schert sich nicht darum, dass ich ihm die t-online mailouts in meiner bypass_access als gut gekennzeichnet habe.
nur zur Sicherheit: die Map hast Du aber gebaut, oder?
Ja, und den postfix neu laden lassen - immer wieder.
Gruß
Hi Friedrich,
On 05.07.19 23:15, Friedrich Strohmaier wrote:
Ja, und den postfix neu laden lassen - immer wieder.
OK, wenngleich ich damit erst mal etwas ratlos bin und hoffe, ich habe an Deinem Config-Auszug nix übersehen.
Was ich Dir generell und um den Fehler evtl. besser eingrenzen zu können, empfehlen würde:
1) Ersetze mal die ganzen bisher einzelnen smtpd_*_restrictions zumindest testhalber/temporär durch _eine_ in dieser Art:
smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access hash:/etc/postfix/access_client, check_helo_access hash:/etc/postfix/access_helo, check_sender_access hash:/etc/postfix/access_sender, check_recipient_access hash:/etc/postfix/access_recipient, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unknown_client_hostname, reject_unauth_destination, reject_unauth_pipelining, reject_invalid_hostname, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2, permit
und
2) splitte Deine bypass_access, wie oben zu sehen, in einzelne Maps auf und dort dann _nur_ die patterns der jeweils zu prüfenden Information (host name, envelope sender, helo etc.). Ist m. E. gezielter konfigurier-/prüfbar, als wenn das alles in einem Topf liegt (gerade wenn man Fehler wie Deinen untersuchen will).
Und als weiteren Gedanke noch ein Hinweis dazu:
Meine (gekürzte) /etc/postfix/bypass_access: ... t-online.de OK
# Telekom lt. Website .. 194.25.134.84 OK ...
Das 'OK' bei den accept actions versuche ich generell zu vermeiden - zu schnell ist man dabei ein open relay. Ich schaue immer, dass ich sowas verwende:
whitelist:
t-online.de permit_auth_destination,reject 194.25.134.84 permit_auth_destination,reject
blacklist:
example.com reject
HTH und Gruß Markus
Hi Markus, *,
hat bisschen gedauert - da ist was dazwischengekommen - sorry..
Am 06.07.19 um 11:21 schrieb Markus Winkler:
On 05.07.19 23:15, Friedrich Strohmaier wrote:
Ja, und den postfix neu laden lassen - immer wieder.
OK, wenngleich ich damit erst mal etwas ratlos bin
so gehts mir auch ;o))
und hoffe, ich habe an Deinem Config-Auszug nix übersehen.
Was ich Dir generell und um den Fehler evtl. besser eingrenzen zu können, empfehlen würde:
- Ersetze mal die ganzen bisher einzelnen smtpd_*_restrictions zumindest
testhalber/temporär durch _eine_ in dieser Art:
smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access hash:/etc/postfix/access_client, check_helo_access hash:/etc/postfix/access_helo, check_sender_access hash:/etc/postfix/access_sender, check_recipient_access hash:/etc/postfix/access_recipient, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unknown_client_hostname, reject_unauth_destination, reject_unauth_pipelining, reject_invalid_hostname, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2, permit
nun ja, an dem Mailserver hängt einiges dran und ich fürchte mit einer so weitreichenden Änderung ein Problem durch das nächste zu ersetzen..
Wenn ich mal einen guten Tag und vergessen habe, dass ich in dieser Sache ein Feigling bin, dann.. :o))
und
- splitte Deine bypass_access, wie oben zu sehen, in einzelne Maps auf und
dort dann _nur_ die patterns der jeweils zu prüfenden Information (host name, envelope sender, helo etc.). Ist m. E. gezielter konfigurier-/prüfbar, als wenn das alles in einem Topf liegt (gerade wenn man Fehler wie Deinen untersuchen will).
nun ja ich gebe freimütig zu, dass die "Mischung" genau darin ihre Ursache hat, dass die verschiedenen Blöcke bei Einzelbehandlung nicht die Ergebnisse brachten, die ich erwartet hatte. Ich versteh' wohl nicht gut genug, was genau da behandelt wird.
Wenn ich im Workshop richtig aufgepasst habe, ist es so, dass innerhalb der Blöcke die Bedingungen strikt nach Reihenfolge abgearbeitet werden. Das hat bei meiner Schrotflintenmethode bislang recht gut funktioniert. ;o))
Nochmal zur Erinnerung der Block, der für mich nicht nachvollziehbares Zeug macht:
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_recipient_access hash:/etc/postfix/bypass_access reject_unauth_destination reject_unauth_pipelining reject_non_fqdn_recipient reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_recipient_domain reject_unlisted_recipient reject_unknown_address reject_rbl_client ix.dnsbl.manitu.net reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2
Ich versteh' nicht, was das Whitelisting an früher Stelle verhindert, aber später die Blacklist zuschlagen lässt. Insgeheim hatte ich gehofft, dass ich nur Tomaten auf den Augen habe und weitere Augenpaare einen offensichtlichen Fehler sehen.
[..]
Das 'OK' bei den accept actions versuche ich generell zu vermeiden - zu schnell ist man dabei ein open relay. Ich schaue immer, dass ich sowas verwende:
whitelist:
t-online.de permit_auth_destination,reject 194.25.134.84 permit_auth_destination,reject
blacklist:
example.com reject
Danke für den Tipp. Werde nachforschen, ob mein betagter Postfix 2.9.6 das schon kann.
HTH
auf jeden Fall, auch wenn sich der Tomatenverdacht nicht bestätigt hat :-\
Vielen Danke für's Mitdenken und nochmal sorry für den Verzug
Hi Friedrich,
danke für die Infos.
Und zuerst ein Hinweis zu meiner vorigen Mail:
On 20.07.19 00:22, Friedrich Strohmaier wrote:
- Ersetze mal die ganzen bisher einzelnen smtpd_*_restrictions zumindest
testhalber/temporär durch _eine_ in dieser Art:
smtpd_relay_restrictions =
[...]
und da Du schreibst:
mein betagter Postfix 2.9.6
smtpd_relay_restrictions gibt es erst ab 2.10. Falls Du das also doch mal testen solltest und bei dieser Postfix-Version bleibst, dann bitte durch smtpd_recipient_restrictions ersetzen.
nun ja, an dem Mailserver hängt einiges dran und ich fürchte mit einer so weitreichenden Änderung ein Problem durch das nächste zu ersetzen..
Naja, das ist eigentlich unkritisch. Aber die Entscheidung musst Du natürlich selbst treffen. ;-)
Nochmal zur Erinnerung der Block, der für mich nicht nachvollziehbares Zeug macht:
Gut, das Du's noch mal aufführst, denn ...
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_recipient_access hash:/etc/postfix/bypass_access reject_unauth_destination reject_unauth_pipelining reject_non_fqdn_recipient reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_recipient_domain reject_unlisted_recipient reject_unknown_address reject_rbl_client ix.dnsbl.manitu.net reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2
Ich versteh' nicht, was das Whitelisting an früher Stelle verhindert, aber später die Blacklist zuschlagen lässt.
... ich glaube, ich habe in Deiner ursprünglichen Mail etwas übersehen, was mit meiner Empfehlung aus meiner letzten zu tun hat und was mir tatsächlich erst jetzt aufgefallen ist (betriebsblind, da ich diese separaten smtpd_*_restrictions einfach seit ewigen Zeiten nicht mehr verwende):
Du hast in Deinen smtpd_recipient_restrictions ja ausschließlich check_recipient_access (Check auf Empfängeradresse) drin, am Ende dieses Blocks allerdings zwei RBL-Checks, die jedoch Clients abfragen. Damit hast Du (_nur_ innerhalb der smtpd_recipient_restrictions wohlgemerkt!) diese beiden Client-Whitelists nicht drin:
t-online.de OK 194.25.134.84 OK
da Du nämlich vor den RBL-Abfragen gar nicht auf Clients checkst (check_client_access). Damit führt, wenn einer der genannten Clients auf der RBL steht, dies zum REJECT in diesem Restrictions-Block und somit zum beobachteten:
reject: RCPT from mailout09.t-online.de[194.25.134.84]: 554 5.7.1 Service unavailable; Client host [194.25.134.84] blocked using hostkarma.junkemailfilter.com;
Lösung:
Verfrachte (verschiebe!) diesen beiden Zeilen aus dem o. g. smtpd_recipient_restrictions-Block:
reject_rbl_client ix.dnsbl.manitu.net reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2
folgendermaßen in diesen:
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/bypass_access reject_unauth_pipelining reject_unknown_client_hostname reject_rbl_client ix.dnsbl.manitu.net <------- reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2 <-------
Nach einem postfix reload sollte das nun wie gewünscht funktionieren.
Du kannst das korrekte Verhalten übrigens mit XCLIENT testen:
Einfach mal ein
smtpd_authorized_xclient_hosts = localhost
in die main.cf, dann kannst Du von Deinem Server aus lokal anhand dieser Readme:
http://www.postfix.org/XCLIENT_README.html
den Mailempfang von einem T-Online-Host aus simulieren und schauen, ob die Restrictions nun wie gewünscht greifen (ggf. sogar mal gezielt vor und nach der Änderung).
Übrigens:
whitelist:
t-online.de permit_auth_destination,reject 194.25.134.84 permit_auth_destination,reject
blacklist: example.com reject
Danke für den Tipp. Werde nachforschen, ob mein betagter Postfix 2.9.6 das schon kann.
Das kann der. ;-)
Meine Empfehlung hinsichtlich Eindampfen auf nur noch smtpd_recipient_restrictions bleibt - auch damit wäre nämlich dieses Problem beseitigt worden. Es ist wirklich kein Risiko dabei. ;-)
Viel Erfolg und viele Grüße Markus
Hi Markus, *,
Am 20.07.19 um 18:12 schrieb Markus Winkler:
Hi Friedrich,
danke für die Infos.
Und zuerst ein Hinweis zu meiner vorigen Mail:
On 20.07.19 00:22, Friedrich Strohmaier wrote:
- Ersetze mal die ganzen bisher einzelnen smtpd_*_restrictions zumindest
testhalber/temporär durch _eine_ in dieser Art:
smtpd_relay_restrictions =
[...]
und da Du schreibst:
mein betagter Postfix 2.9.6
smtpd_relay_restrictions gibt es erst ab 2.10. Falls Du das also doch mal testen solltest und bei dieser Postfix-Version bleibst, dann bitte durch smtpd_recipient_restrictions ersetzen.
O.K. Danke für die Info.
[..]
Gut, das Du's noch mal aufführst, denn ...
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_recipient_access hash:/etc/postfix/bypass_access reject_unauth_destination reject_unauth_pipelining reject_non_fqdn_recipient reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_recipient_domain reject_unlisted_recipient reject_unknown_address reject_rbl_client ix.dnsbl.manitu.net reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2
Ich versteh' nicht, was das Whitelisting an früher Stelle verhindert, aber später die Blacklist zuschlagen lässt.
[..]
Du hast in Deinen smtpd_recipient_restrictions ja ausschließlich check_recipient_access (Check auf Empfängeradresse) drin, am Ende dieses Blocks allerdings zwei RBL-Checks, die jedoch Clients abfragen. Damit hast Du (_nur_ innerhalb der smtpd_recipient_restrictions wohlgemerkt!) diese beiden Client-Whitelists nicht drin:
t-online.de OK 194.25.134.84 OK
da Du nämlich vor den RBL-Abfragen gar nicht auf Clients checkst (check_client_access). Damit führt, wenn einer der genannten Clients auf der RBL steht, dies zum REJECT in diesem Restrictions-Block und somit zum beobachteten:
reject: RCPT from mailout09.t-online.de[194.25.134.84]: 554 5.7.1 Service unavailable; Client host [194.25.134.84] blocked using hostkarma.junkemailfilter.com;
Lösung:
Verfrachte (verschiebe!) diesen beiden Zeilen aus dem o. g. smtpd_recipient_restrictions-Block:
reject_rbl_client ix.dnsbl.manitu.net reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2
folgendermaßen in diesen:
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/bypass_access reject_unauth_pipelining reject_unknown_client_hostname reject_rbl_client ix.dnsbl.manitu.net <------- reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2 <-------
Nach einem postfix reload sollte das nun wie gewünscht funktionieren.
Super! Habe ich als erste Sofortmaßnahme eingebaut. Ein erster kurzer Test lief durch. Dann waren es also doch die Tomaten :o))
Du kannst das korrekte Verhalten übrigens mit XCLIENT testen:
Einfach mal ein
smtpd_authorized_xclient_hosts = localhost
in die main.cf, dann kannst Du von Deinem Server aus lokal anhand dieser Readme:
den Mailempfang von einem T-Online-Host aus simulieren und schauen, ob die Restrictions nun wie gewünscht greifen (ggf. sogar mal gezielt vor und nach der Änderung).
Ui, das klingt interessant - da nehm' ich mir mal einen "statt Fernsehabend" Zeit, um das anzuschauen.
Übrigens:
whitelist:
t-online.de permit_auth_destination,reject 194.25.134.84 permit_auth_destination,reject
blacklist: example.com reject
Danke für den Tipp. Werde nachforschen, ob mein betagter Postfix 2.9.6 das schon kann.
Das kann der. ;-)
Gut!
Meine Empfehlung hinsichtlich Eindampfen auf nur noch smtpd_recipient_restrictions bleibt - auch damit wäre nämlich dieses Problem beseitigt worden. Es ist wirklich kein Risiko dabei. ;-)
Du hast mich überzeugt - ich werde das so in Angriff nehmen.
Der Weg in eine überschaubarere Konfiguration ist geebnet und vor allem das Problem gelöst!
Vielen Dank für Deine Hilfe.
participants (2)
-
Friedrich Strohmaier -
Markus Winkler