Gelöst: RBL schlägt an - remote client steht in whitelist
Friedrich Strohmaier
frieder at wueste-welle.de
Mo Jul 22 14:48:35 CEST 2019
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:
>>> 1) 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:
> 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).
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.
--
Friedrich Strohmaier
Koordination AK-Technik
***
Freies Radio Wüste Welle
für Tübingen/Reutlingen
http://www.wueste-welle.de
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 195 bytes
Beschreibung: OpenPGP digital signature
URL : <https://de.postfix.org/pipermail/postfix-users/attachments/20190722/c0ca7cbc/attachment.sig>
Mehr Informationen über die Mailingliste postfix-users