Hi Friedrich,
On 05.07.19 23:15, Friedrich Strohmaier wrote:
Ja, und den postfix neu laden lassen - immer wieder.
OK, wenngleich ich damit erst mal etwas ratlos bin und hoffe, ich habe an
Deinem Config-Auszug nix übersehen.
Was ich Dir generell und um den Fehler evtl. besser eingrenzen zu können,
empfehlen würde:
1) Ersetze mal die ganzen bisher einzelnen smtpd_*_restrictions zumindest
testhalber/temporär durch _eine_ in dieser Art:
smtpd_relay_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_client_access hash:/etc/postfix/access_client,
check_helo_access hash:/etc/postfix/access_helo,
check_sender_access hash:/etc/postfix/access_sender,
check_recipient_access hash:/etc/postfix/access_recipient,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unknown_client_hostname,
reject_unauth_destination,
reject_unauth_pipelining,
reject_invalid_hostname,
reject_rbl_client ix.dnsbl.manitu.net,
reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2,
permit
und
2) splitte Deine bypass_access, wie oben zu sehen, in einzelne Maps auf und
dort dann _nur_ die patterns der jeweils zu prüfenden Information (host
name, envelope sender, helo etc.). Ist m. E. gezielter
konfigurier-/prüfbar, als wenn das alles in einem Topf liegt (gerade wenn
man Fehler wie Deinen untersuchen will).
Und als weiteren Gedanke noch ein Hinweis dazu:
Meine (gekürzte) /etc/postfix/bypass_access:
...
t-online.de OK
# Telekom lt. Website
..
194.25.134.84 OK
...
Das 'OK' bei den accept actions versuche ich generell zu vermeiden - zu
schnell ist man dabei ein open relay. Ich schaue immer, dass ich sowas
verwende:
whitelist:
t-online.de permit_auth_destination,reject
194.25.134.84 permit_auth_destination,reject
blacklist:
example.com reject
HTH und Gruß
Markus
