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