Mal eine grundlegende Frage an die Experten hier: Was haltet ihr für die beste Methode, um Postfix mit SpamAssassin zusammenarbeiten zu lassen? Ich kenne bis jetzt diese 3 Möglichkeiten:
1. Direkt per spamd (http://wiki.apache.org/spamassassin/Int ... dInPostfix)
2. Postfix -> procmail -> SpamAssassin
3. Postfix / MailSanner / SpamAssassin
Ein Setup wie [3.] hatte ich auf einem anderen Server schon mal am Laufen, hat auch ganz gut funktioniert, aber hat warscheinlich auch den größten Overhead. Daher war mir nun eigentlich [1.] ganz sympathisch, allerdings heisst "This configuration does not allow rejecting messages within the SMTP transaction" ja wohl offenbar, dass ich policyd-weight nicht einsetzen kann, oder? Und auch kein Greylisting? Für [2.] hab ein ein Beispiel-procmailrc Skript, dessen Inhalt ich allerdings nur grob verstehe, da ich kein procmail-Experte bin. Sollte aber funktionieren.
In meiner ehemaligen MailScanner-Konfiguration hatte ich zusätzlich ClamAV eingebunden, von dem ich aber inzwischen meine, ihn komplett weglassen zu können, wenn ich per Postfix body_check bereits alle Mails mit potenziell gefährlich Anhängen rausfiltere. Oder?
Um noch einen Schritt weiter zu gehen - braucht man SpamAssassin überhaupt? Und zwar frage ich das, wenn ich gleichzeitig bereits policyd-weight und postgrey (+Standard-Checks von Postfix) im Einsatz habe. Nach dem, was ich gelesen habe, blocken die beiden bereits rund 90% Prozent des Spams. Das wäre für mich ok, wenn/weil dadurch gleichzeitig die Gefahr von False Positives durch SpamAssassin sinkt.
Tipps, Hinweise, Meinungen, Erfahrungen?
Postfix + SpamAssassin: Best Practice?
-
- Project Manager
- Posts: 11183
- Joined: 2003-02-27 01:00
- Location: Hamburg
Re: Postfix + SpamAssassin: Best Practice?
Meiner Erfahrung nach, reicht policyd-weight allein vollkommen aus. Greylisting erzeugt mir zuviel false positives, da nicht leider alle Mailserver(-Admins) damit umgehen können/wollen. Spamassassin ist mir zu ressourcenlastig, weshalb diese Aufgabe der User bei Bedarf selbst lokal erledigen muss. Alles IMHO, versteht sich ;)
-
- Posts: 2138
- Joined: 2002-12-15 00:10
- Location: Bergheim
Re: Postfix + SpamAssassin: Best Practice?
Du hast amavisd vergessen. Das ist meiner Meinung nach die beste Lösung.
Es ist resourcenschonend, flexibel und bindet einen Virenscanner direkt mit ein.
Es ist resourcenschonend, flexibel und bindet einen Virenscanner direkt mit ein.
-
- Posts: 538
- Joined: 2005-09-02 11:12
Re: Postfix + SpamAssassin: Best Practice?
policyd-weight und dahinter amavisd mit Virenscanner und SA.. die wenigen Mails die noch durch PW kommen werden normalerweise vom SA richtig getaggt.
Last edited by rootsvr on 2007-09-25 12:11, edited 1 time in total.
-
- Posts: 695
- Joined: 2005-09-16 00:06
- Location: Berlin-Reinickendorf
Re: Postfix + SpamAssassin: Best Practice?
ACK. Ich fahre seit einigen Monaten auch ausschließlich mit policyd-weight mit Prüfung des FQDN des Absenders. Viel mehr Spam ist auch nicht durchgekommen als vorher.Joe User wrote:Meiner Erfahrung nach, reicht policyd-weight allein vollkommen aus. Greylisting erzeugt mir zuviel false positives, da nicht leider alle Mailserver(-Admins) damit umgehen können/wollen. Spamassassin ist mir zu ressourcenlastig, weshalb diese Aufgabe der User bei Bedarf selbst lokal erledigen muss. Alles IMHO, versteht sich ;)
Vor allem ist diese vorgehensweise ressourcenschonend.
-
- Administrator
- Posts: 2641
- Joined: 2004-01-21 17:44
Re: Postfix + SpamAssassin: Best Practice?
Von mir favorisierte Lösung: Policyd-weight und eine restriktive Postfix-Konfiguration, dazu SpamAssassin und ClamAV per amavisd-new mit MySQL-Steuerung. Da so um die 300-400 UCEs täglich noch am PW vorbeischlüpfen, komme ich um einen Textmuster-Filter nicht drumherum. Der Virenscanner ist da eher ein Beruhigungsargument für die Kundschaft
(wobei ich auf IMAP und POP3 nach Möglichkeit TLS- oder SSL-verschlüsselt zugreifen lasse, so dass ein Content Scanner auf dem Client-Rechner normalerweise nicht mitschnüffeln kann).
Vorteil: Ich kann pro (virtuellem) User individuell festlegen, ob auf Viren oder Spam geprüft werden soll. Außerdem kann ich so auch die Bayes-Lerndaten pro virtuellem User in der Datenbank halten.
Nachteil: policyd-weight und die restriktive Postfix-Konfiguration fangen zwar schon eine ganze Menge ab, allerdings muss man sehr aktiv White Lists pflegen, da einige größere Unternehmen wie 3,2,1... z. B. ein grottiges Mail-Setup haben.
Vorteil: Ich kann pro (virtuellem) User individuell festlegen, ob auf Viren oder Spam geprüft werden soll. Außerdem kann ich so auch die Bayes-Lerndaten pro virtuellem User in der Datenbank halten.
Nachteil: policyd-weight und die restriktive Postfix-Konfiguration fangen zwar schon eine ganze Menge ab, allerdings muss man sehr aktiv White Lists pflegen, da einige größere Unternehmen wie 3,2,1... z. B. ein grottiges Mail-Setup haben.