-------- Original-Nachricht -------- > Datum: Fri, 19 Mar 2010 12:28:54 +0000 > Von: "Morten P.D. Stevens" <[email protected]> > An: "[email protected]" <[email protected]> > Betreff: [postfix-users] Postfix Antispam Konfiguration
> Hi Leute, > Hallo, > ich habe derzeit das Problem, dass über unsere Server gefühlt zu viel > Spam reinkommt. Pro Woche 10-15 Mails im Spamordner (durch Spamassassin > gefiltert) ist dennoch zu viel. > > Die Konfiguration die ich gleich poste haben wir allerdings schon über > ein halbes Jahr und zu dem Zeitpunkt kam praktisch überhaupt kein Spam > durch. Seit den letzten 2-3 Monaten ist es schlimmer geworden. > > Als Contentfilter nehmen wir SpamAsssassin der seinen Job gut macht. > > smtpd_helo_required = yes > smtpd_delay_reject = yes > > smtpd_helo_restrictions = > permit_mynetworks, > reject_invalid_hostname, > reject_unknown_helo_hostname, > reject_non_fqdn_hostname > > smtpd_recipient_restrictions = > permit_sasl_authenticated, > permit_mynetworks, > reject_invalid_hostname, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unknown_sender_domain, > reject_unknown_reverse_client_hostname, > reject_unknown_recipient_domain, > reject_unauth_pipelining, > reject_unauth_destination, > reject_rbl_client b.barracudacentral.org, > reject_rbl_client zen.spamhaus.org, > reject_rbl_client ix.dnsbl.manitu.net, > reject_rbl_client dnsbl.sorbs.net, > reject_rbl_client dnsbl-1.uceprotect.net, > reject_rbl_client dnsbl-2.uceprotect.net, > reject_rbl_client dnsbl-3.uceprotect.net, > permit > Es ist mir nicht möglich zur Zeit auf die Konfiguration meiner Installation zuzugreifen aber werde das nach der Arbeit nachholen. Meine Konfiguration unterscheidet sich von Deiner in folgenden wesentlichen Punkten. Content Filter: DSPAM Begründung: SpamAssassin ist mir zu langsam und zu Ressourcenintensiv. Auf meinem Test System (ein [email protected] und hyper threading) schaffe ich gut 21 Klassifikationen die Sekunde mit DSPAM. Bei SA ist es aus meinen Erfahrungen jeweils umgekehrt (überspitzt gesagt: 1 Klassifizierung pro 20 Sekunden). Und das DSPAM benötigt bei mir knapp 4MB Speicher. Mit SA schaffe ich das kaum. Delayed reject habe ich ausgeschaltet. Ich will die bösen Jungs so schnell wie möglich von der Leitung haben. RBLs benütze ich NICHT in Postfix. Ist mir zu unsicher. Oder besser gesagt: Ich traue keinen von denen ausschliesslich. Darum habe ich policyd-weight im Einsatz. Das erlaubt mir die ganze RBL listing Problematik ein wenig zu entschärfen. Policyd-weight: Das habe ich erweitert: - Habe GeoIP integriert (das erlaubt mir eine Gewichtung nach Kontinent und/oder Land) - Distanz Berechnung. Das habe ich eingebaut nachdem ich von SNARE (http://www.technologyreview.com/communications/23086/) gelesen habe. - p0f Integration (das erlaubt mir eine Gewichtung nach OS zu machen (aka: MTAs auf Windows XP (ein DESKTOP OS) bekommen bei mir eine höhere Gewichtung (im negativen Sinne) als ein *BSD, Solaris, Linux, Windows 2003 Server, etc). - Gewichtung nach den Regeln von S25R (http://www.gabacho-net.jp/en/anti-spam/). In Postfix habe ich auch bedeutend mehr Restriktionen drin. Ich habe aber nicht alle im Kopf. Müsste die bei Interesse noch posten. Eine solche Restriktion ist, dass ich z.B. nur bestimmten Servern ein Double-Recipient Bounces erlaube. Als Greylisting Lösung habe ich SQLgrey und GROSS. Ja, ja... zwei Lösungen hintereinander. Aber das hat seinen Grund. In GROSS habe ich einige ganz exotische RBLs drin und nur wenn man einen bestimmten Schwellenwert erreicht wird man von GROSS gegreylisted. Als Anti-Virus Werkzeug setze ich Amavisd-New ein mit ClamAV. Bei ClamAV habe ich etliche zusätzliche Signaturen (SaneSecurity, MSRBL, usw...). In Postfix habe ich dann noch so Sachen wie SPF, DKIM (mit openDKIM als milter), DCC (auch als milter), Sender-ID (auch als milter), usw... Aber die blocken nicht so viel ab (aber genug um sie zu benützen und einige bieten ja noch Funktionen an die über Anti-Spam gehen (z.B. DKIM outbound signing)). Und dann noch weitere Kleinigkeiten die aber nicht so unglaublich effektiv sind. Die will ich aber nicht missen. So Sachen wie ein Fail2Ban für die Idioten die innerhalb 5 Minuten es schaffen gleich mehrmals eine Mail an jemanden zu senden den es in der Virtual Tabelle gar nicht gibt. Die werden dann von Port 25 für 10 Minuten gesperrt. usw... Beim ganzen Aufbau war es mir wichtig so viel wie nur möglich auch geclustert laufen lassen zu können. Z.B. sind beide Greylisting Lösungen auf den zwei Servern die bei mir als MX fungieren installiert und die greifen auf die gleiche Datenbasis zurück. Das Gleiche passiert auch bei der Anti-Spam Lösung (DSPAM). usw... Das ist mir besonders wichtig. Ich will keine Insellösung. Es muss etwas sein, dass wachsen kann. > Was könnte man daran noch optimieren? Für Vorschläge wäre ich sehr > offen und dankbar. > > Oder gibt es noch effektivere Blacklists? Es gibt ja teilweise auch > kostenpflichtige Blacklists... hat da jemand mit Erfahrungen? > Du benützt schon eine die Kostenpflichtig wäre -> spamhaus (ab einem bestimmten Volumen). Ich persönlich würde nie und nimmer UCE Protect und Barracuda so in Postfix einsetzen. Die sind meiner Meinung nach alleine betrachtet zu eng gefasst und liesten zu schnell. Ich weiss nicht mehr wer das ist (müsste schnell suchen) aber es gibt da einen Typen der seit Jahren so DNSBLs vergleicht und bei ihm ist Zen und bl.spamcop.net die welche die wenigsten FP haben. Evt könntest Du noch die eine oder andere RHBL benützen? Spamhaus hat neu eine. Was mir bei Dir fehlt sind DNSWL und RHWL. Mit so was wie policyd-weight kannst du das ganz gut integrieren. Was ich Dir noch empfehlen kann aber das nicht OSS ist, ist Mailchannels Traffic Control. Ist zwar kostenpflichtig aber die hatten mal eine Version die für kleine Installationen kostenlos war oder immer noch ist. Ich weiss es nicht, ob sie das noch anbieten. Wie dem auch sei... das Ding ist noch recht interessant. Schau es Dir mal an. Ich habe es dann schlussendlich nicht erworben und stattdessen meine eigene Installation erweitert. Ich habe jetzt nicht alles aufgezählt was ich habe. Es wäre zu Zeitintensiv und ich muss jetzt arbeiten und Code abliefern :) Ach ja. Noch was. Habe so ziemlich jeden Stage in Restriction Classes in Postfix gefasst. Der Grund ist, dass ich in der Lage sein will jedes der Verarbeitungsschritte kontrolliert durchlaufen zu lassen. Bei einzelnen Domänen/Empfängern kann es also gut sein, dass einzelne Schritte nicht durchlaufen werden. Ohne Restriction Classes könnte ich so was nicht auf die Beine stellen (zumindest nicht so einfach). > Vielen Dank für Eure Bemühungen. > > Mit freundlichen Grüßen > > Morten Stevens > // Steve > IMT-Systems GmbH > Helfmann-Park 10 > 65760 Eschborn > > Internet: http://www.imt-systems.com > E-Mail: [email protected] > > Sitz der Gesellschaft: Eschborn am Taunus > Eingetragen im Handelsregister Frankfurt am Main - HRB 86696 > Geschäftsführer: Morten Stevens > > _______________________________________________ > postfix-users mailing list > [email protected] > http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser _______________________________________________ postfix-users mailing list [email protected] http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
