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.