Thomas Fankhauser wrote:
Deine Konfig kann zusammengefasst werden zu:
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_rbl_client zombie.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client dialup.blacklist.jippg.org reject_unverified_recipient
Meinst du damit dass es nicht nötig ist, smtpd_recipient_restrictions,
smtpd_helo_restrictions und
smtpd_sender_restrictions zu brauchen. So dass nur eine dieser angegeben werden muss?
Es ist auf jeden Fall einfacher und du siehst die Reihenfolge der Checks. Ansonsten wird ei Sache etwas komplizierter: smtp Dialog läuft nach folgendem Muster ab: connect from... helo/ehlo mail from rcpt to data... Die in Postfix verfügbaren smtpd_*_restrictions sind analog dazu benannt: smtpd_client_restrictions smtpd_helo_restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_data_restrictions smtpd_end_of_data_restrictions smtpd_recipient_restrictions hat als einzige die Vorgabe, dass dort "reject_unauth_destionation, reject etc." auftauchen muss. Alle anderen sind leer. Du kannst die Checks sehr präzise setzen mit der Auffächerung, aber auf Kosten einer komplizierteren Konfiguration. Der Default ist ohnehin, dass erst nach rcpt to der Client abgewiesen wird, da früher einige Clients Probleme damit hatten, direkt abgewiesen zu werden. Zusätzlich bekommt man die Absender/Empfänger/Helo-Angaben im Log. Jeder smtpd_*_restriction wird durchlaufen, bis entweder ein Check "OK/permit" oder "4xx/5xx/reject" Du hattest z.B. in smtpd_sender_restrictions permit_mynetworks vorgeschaltet, aber kein permit_sasl_authenticated. Dies stand aber bei smtpd_recipient_restrictions, wenn ich mich recht erinnere. Ich nehme an, das war nicht gewollt.
In zen.spamhaus.org ist enthalten: cbl, sbl, xbl, dynalist, opm
Damit werden nur die Mails abgeprüft, die hinter den Blacklists stehen. Du kannst das noch auf deine Relay_domains einschränken, wenn du statt reject_unverified_recipient diesen check verwendest:
Was bringt mir das für Vorteile?
Dass der Check nur für die Relay_domains verwendet wird, aber nicht für lokale Domains in $mydestination, wo Postfix die gültigen Empfänger aus /etc/passwd und /etc/aliases selbst bestimmen kann.
check_recipient_access hash:/etc/postfix/relay_verify
/etc/postfix/relay_verify: digelec.com reject_unverified_recipient daniels.ch reject_unverified_recipient
Cache das Ergebnis mit: address_verify_map = btree:/etc/postfix/verify_db
Hab festgestellt dass bei jedem eintreffen einer Mail, der Postfix erst einen 450 4.4.1 Recipient address rejected: unverified address: Address verification in progress Fehler ausgibt. Damit ist doch auch gerade schon ein 'Greylisting' erreicht!?
Greylisting verwendet ein anderes Prinzip, hier geht es um Empfängervalidierung. Greylistig prüft, ob der Client sich wie ein Server verhält. Eine ähnliche Funktion hat reject_unverified_sender, wo geprüft wird, ob der verantwortliche Server diese Absenderadresse als gültig kennt. Ich habe bei mir festgestellt, dass es eine Menge Ärger durch falsche Adressen gibt. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org