On Behalf Of Morten P.D. Stevens

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 =

Mit in die smtpd_recipient_restrictions packen

    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,

uceprotect und barracudacentral gehören bei den RBL's wegen der Listing Politik nicht zu meinen Lieblingen, Uceprotect ist in der Postfixliste sehr umstritten und es wird eher vor einem Einsatz abgeraten

    permit  

Das permit am Schluss kannst du dir sparen wer bis dahin durchgekommen ist wird eh angenommen.

Mal ein Beispiel von einem meiner Server der gefühlt gar keinen Spam bekommt

smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, reject_unlisted_recipient, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_sender_login_mismatch, reject_unlisted_sender, permit_sasl_authenticated, reject_unauthenticated_sender_login_mismatch, reject_unauth_destination, check_sender_access hash:/etc/postfix/maps/abzocker, check_recipient_access hash:/etc/postfix/adress_maps/kuendigt, check_sender_access pcre:/etc/postfix/checks/sender_checks.pcre, sleep 1, check_client_access pcre:/etc/postfix/maps/dynip.pcre, check_client_access pcre:/etc/postfix/maps/spamer, check_helo_access pcre:/etc/postfix/helo_checks, check_helo_access hash:/etc/postfix/maps/helo_check, check_recipient_access hash:/etc/postfix/maps/empfaenger, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, # reject_unknown_reverse_client_hostname, # reject_unknown_client_hostname, check_sender_mx_access cidr:/etc/postfix/maps/bogus_mx, check_sender_mx_access hash:/etc/postfix/maps/wildcard_mx, check_sender_access hash:/etc/postfix/maps/access, check_sender_ns_access hash:/etc/postfix/maps/bogus_dns, check_sender_access hash:/etc/postfix/checks/check_backscatterer, check_client_access pcre:/etc/postfix/maps/dialups.grey, check_recipient_access hash:/etc/postfix/roleaccount, check_policy_service inet:127.0.0.1:12525, reject_rbl_client zen.spamhaus.org, reject_rbl_client ix.dnsbl.manitu.net

enthält sehr viele selbst gepflegte maps, dazu wird Amavis im Prequefilter verfahren eingesetzt. Selective Greylisting, Policyd-weight runden das ganze noch ab.

Und mit /etc/init.d/postfix Stopp wird auch noch die letzte Mail abgelehnt *gg

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?

Ich nicht, es gibt genug freie

Mit freundlichen Grüßen

Drießen

-------- Original-Nachricht --------

Datum: Fri, 19 Mar 2010 12:28:54 +0000 Von: "Morten P.D. Stevens" mstevens@imt-systems.com An: "postfix-users@de.postfix.org" postfix-users@de.postfix.org 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 P4@2.8GHz 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: mstevens@imt-systems.com   Sitz der Gesellschaft: Eschborn am Taunus Eingetragen im Handelsregister Frankfurt am Main - HRB 86696 Geschäftsführer: Morten Stevens

---

postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users