nicht angemeldet
Moin!
Brauchst du wirklich Relay-Domains?
Der Server soll für unterschiedliche Domains E-Mails in Empfang nehmen - die Angaben aus meinem schlauen Buch dazu habe ich so verstanden, dass relay_domains die Angabe dafür ist, was der Server alles anehmen soll - genauso habe ich das hier verstanden.
Naja, die Doku sagt: "What destination domains (and subdomains thereof) this system will relay mail to."
"will relay mail to." Also Weiterleitung mit diesem Mailserver als Zwischenstation. Mag vielleicht auf das gleiche hinauslaufen, hat aber die Absicht, die Mails auch wieder per SMTP loszuwerden.
Schlauer scheint mir mydestination. "The list of domains that are delivered via the $local_transport mail delivery transport."
Kann man bei mydestination die Daten aus der MySQL-Datenbank holen?
Klar kann man.
Alle Restrictions sollten unter smtpd_recipient_restrictions zusammengelegt werden. Postfix sollte sowieso erst dann prüfen, ob die Bedingungen eingehalten sind, wenn der SMTP-Dialog vor dem Versand der Mailinhalte steht.
Warum alles unter recipient zusammenfasen?
Weil die Wirkungsweise der Filter dann, wenn es aufgeteilt ist, unübersichtlicher wird, und u.U. dadurch unerwünschte Nebenwirkungen auftreten.
Postfix prüft nacheinander die Bedingungen der Gruppen smtpd_client_restrictions, *_helo_*, *_sender_*, *_recipient_* (und *_data_*, header_checks, body_checks als Inhaltskontrolle - die anzuwenden solltest du allerdings nach Möglichkeit vermeiden, weil das bedeutet, dass der Spam empfangen werden muß, um ihn zu prüfen).
Tritt in einer der Bedingungsgruppen eine Ablehnung auf (REJECT), wird der Test der weiteren Bedingungen abgebrochen, und die Mail abgelehnt. Tritt in einer der Bedingungen eine Akzeptanz (OK) auf, der der Test der weiteren Bedingungen dieser Gruppe abgebrochen, und mit der nächsten Gruppe weitergemacht.
Dadurch kann es passieren, dass du zwar weiter vorne in der Prüfungskette den Empfang erlaubst, dir aber in einer späteren Gruppe der Mailempfang trotzdem verweigert wird, weil eine ganz andere Bedingung es zufällig verbietet.
Steckst du alle Bedingungen in nur eine einzige (schlauerweise eben die letzte) Gruppe, wird in dieser schön der Reihenfolge nach alles geprüft. Und wenn ein Text OK ergibt, dann ist das wirklich endgültig OK und führt zum Empfang.
Natürlich gibt es Szenarien und Filterkonfigurationen, die eine Aufteilung auf verschiedene Gruppen erfordern. Aber sowas setzt du besser erst ein, wenn du weißt, was in Postfix intern abläuft. :)
Zumal: Man kann Spam eben auch filtern, wenn man sowas nicht einsetzt.
Zumal Postfix die Fehler durch stmpd_delay_reject eh erst nach dem Erhalt von rcpt to zurückweist...
Das ist zwar richtig, aber eben nur ein Randdetail.
Diese beiden Zeilen sehen mir stark nach einer entsprechenden Grey-/Blacklist aus:
check_policy_service unix:private/postgrey,
Greylisting erkennst du korrekt. Dazu gibts diverse Policy-Daemons, dieser hier ist der bei Gentoo verfügbare "mail-filter/postgrey" (erhältlich unter http://isg.ee.ethz.ch/tools/postgrey/).
Greylisting ist eine der zwei erfolgreichsten Waffen gegen blöden Spam. Die andere Waffe ist eine strenge Prüfung der Angabe HELO.
Intelligenteren Spam kriegt man leider so einfach nicht weg, da benötigt man dann schon etwas härtere Dinge wie Blacklisten etc. Weil dafür meist echte Mailserver eingesetzt werden, die Greylisting einfach durch erneuten Versand überwinden, und logischerweise auch sinnvolle HELO-Angaben machen.
check_recipient_access hash:/etc/postfix/spamfilter-lookup
Das ist der benutzerabhängige Teil weiterer Filterungen. Da habe ich vier unterschiedlich harte Filter definiert, die abhängig von der Zieladresse noch zusätzlich zum Einsatz kommen. Mal auszugsweise (die anderen Klassen schalten ein oder mehrere Zeilen inaktiv durch Vorsetzen von "warn_if_reject"):
Restriction Classes Definitions
smtpd_restriction_classes = sammeladdr, userlevel3, userlevel2, userlevel1
Filterregeln fuer Sammeladdressen: Extrem streng, filtern auch
Kollateralschaeden wie Bounces (FROM: <>) heraus.
sammeladdr = check_client_access hash:/etc/postfix/ip-domain-whitelist,
check_policy_service unix:private/spf2policy,
reject_rbl_client relays.ordb.org,
reject_rbl_client sbl-xbl.spamhaus.org,
check_client_access hash:/etc/postfix/ip-domain-blacklist,
check_sender_access hash:/etc/postfix/mailfrom-blacklist,
check_sender_access hash:/etc/postfix/sammeladdr-blacklist
So etwas habe ich derzeit aber noch nicht implementiert - da muss ich mal schauen, was ich da noch mache. Ich hätte soweiso gerne, dass sich diese Features Postfach-individuell aktivieren oder deaktivieren lassen...
Da du den Lookup, welche der definierten Filterklassen eingesetzt werden soll, auch aus einer Datenbank auslesen kannst, sollte das kein großes Problem sein. Bei mir steht die Angabe in einer schlichten Postfix-Hashdatei, weil ich seinerzeit das nicht ins LDAP integrieren wollte. Und so häufig ändert sich das auch nicht.
- Sven Rautenberg
"Love your nation - respect the others."