Re: RBL schlägt an - remote client steht in whitelist

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

> 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