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
