Postfix Spamfilter

rolapp

Fan vom SSF
Ich wollte mal von Den Experten und Euch wissen wir Ihr die Spamfilterung handhabt?
Mal kurz aufgelistet was ich bis jetzt gemacht habe.

Mein System Ubuntu 14.04 mit ISPConfig, Postfix, Postgrey, Amavis, Spamassassin, Dovcot und Sieve

In Postfix ist noch DKIM und SPF Auswertung intergriert

unter smtpd_recipient_restrictions habe ich noch folgendes eingetragen
reject_unauth_destination
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unknown_sender_domain
reject_unknown_recipient_domain

Die Spamfilterverwaltung (Black and Whitelist, Spamregeln, DKIM ) erfolgt über ISPConfig, Spammassassin steht per default auf autolearn.

dann lasse ich noch nachts einen cron laufen
Code:
1 3  * * *   amavis   /usr/bin/sa-learn --spam --dbpath /var/lib/amavis/.spamassassin/ --dir /var/vmail/*/*/Maildir/.Junk/cur/*
Der lernt auch fleißig.

Da ich teilweise noch Spam bekomme, bringt es jetzt was noch reject_rbl_client in smtpd_recipient_restrictions einzufügen.
Wenn ja welche würdet Ihr empfehlen.
Die hier sind mir schon bekannt
reject_rbl_client zen.spamhaus.org
reject_rbl_client ix.dnsbl.manitu.net
reject_rbl_client bl.spamcop.net
Mal Danke im Voraus
 
Also bei mir kommpt standartmässig folgendes zum Einsatz:

-- Amavis ( AV und spama. )
-- DKIMS
-- Postgray
-- SPF
-- DNSBL ( die von dir genutzen )

Fahre damit bisher ganz gut spamfrei :)
 
Dann sieht das doch bei mir schon mal nicht schlecht aus.
Ich hatte noch einen kleinen Fehler drin mein Cron ist als root gelaufen, dadurch konnte amavis nicht auf die bayes Datenbank zugreifen. Mal schauen kann nur besser werden.

Danke für die Antwort
 
Hallo,

ich setze ebenfalls ISPConfig3 mit Amavis ein. SPF ist gesetzt. DKIM verwende ich aktuell nicht. Mit ISPConfig 3.1 soll endlich nativer Support für DKIM pro Domain kommen. Postgrey habe ich in den letzten zwei Wochen mal wieder ausprobiert und musste Feststellen, dass es immer noch Mailserver gibt die das nicht korrekt handeln. Greylisting war in Woche 6/7 aktiv und ist jetzt wieder deaktiviert. DNSBL habe ich ebenfalls keine. Alle paar Wochen trainiere ich den Spamfilter neu. Dank ~25000 Mails im Spam-Ordner trifft Spamassassin inzwischen ganz gut.
 

Attachments

  • mailgraph.png
    mailgraph.png
    20.9 KB · Views: 218
Ich verwende sqlgrey fürs Greylisting, ClamAV und Spamassassin per Milter-Schnittstelle angebunden. Im Dovecot läuft Sieve und filtert Spams direkt in einen Spamfilter aus, außerdem habe ich in Dovecot das antispam Plugin installiert (damit werden Mails neu als SPAM/HAM angelernt, wenn sie in den SPam-Ordner verschoben oder raus verschoben werden). Außerdem läuft um Mitternacht ein kleines Script, welches einen Spamstatus per Mail verschickt, sofern an dem Tag neue Mails in den Spamfilter sortiert wurden,
 
Im Dovecot läuft Sieve und filtert Spams direkt in einen Spamfilter aus, außerdem habe ich in Dovecot das antispam Plugin installiert (damit werden Mails neu als SPAM/HAM angelernt, wenn sie in den SPam-Ordner verschoben oder raus verschoben werden)
Dovecot und Sieve läuft ja schon bei mir, das Anti Spam Plugin werde ich mir mal anschauen, das hört sich ganz brauchbar an.

Danton Danke für den Tipp
 
Man kann auch ohne Spamassassin und Co auskommen, indem man Postfix vernünftig konfiguriert:
Code:
allow_percent_hack = no
disable_vrfy_command = yes
mynetworks_style = host
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = ix.dnsbl.manitu.net cbl.abuseat.org zen.spamhaus.org
postscreen_greet_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_enable = yes
show_user_unknown_table_name = no
smtpd_client_restrictions =
  sleep 1,
#  reject_unknown_reverse_client_hostname,
  permit
smtpd_data_restrictions =
  reject_unauth_pipelining,
  permit
smtpd_etrn_restrictions =
  reject
smtpd_helo_required = yes
smtpd_helo_restrictions =
  reject_invalid_helo_hostname,
  reject_non_fqdn_helo_hostname,
  permit
smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
  check_recipient_mx_access cidr:/usr/local/etc/postfix/mx_access,
  check_recipient_access pcre:/usr/local/etc/postfix/recipient_checks.pcre,
  permit
smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  defer_unauth_destination,
  permit
smtpd_sender_restrictions =
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  permit
strict_rfc821_envelopes = yes
Allein damit bleiben >99% der Spams draussen und ob man sich für die letzten <1% die Performanceeinbussen und Sicherheitsrisiken von Spamassassin, Amavis, ClamAV und Co antun will...
 
Allein damit bleiben >99% der Spams draussen und ob man sich für die letzten <1% die Performanceeinbussen und Sicherheitsrisiken von Spamassassin, Amavis, ClamAV und Co antun will...

Das konnte ich jetzt so auch feststellen.
Was meinst Du jetzt mit Sicherheitsrisiken ?
 
Sicherheitsrisiken:
ClamAV lässt sich beispielsweise recht zuverlässig mit Archiven jedweder Art austricksen und dank einiger zusätzlicher Bugs in ClamAV lässt sich auch ein System (mindestens jedoch der clamav-User) übernehmen. Diese Tricks und Bugs sind seit Jahren bekannt (auch den ClamAV-Devs) und werden dennoch nicht gefixt. Dadurch schleppt allein ClamAV mit seinen Abhängigkeiten derzeit weit über 20 altbekannte sicherheitsrelevante Bugs ins System.

Spamassassin lässt sich seit Ewigkeiten DoSen, keine Ahnung inwieweit die Details öffentlich bekannt sind, in entsprechenden Kreisen ist es längst antik.

Amavis kombiniert obiges üblicherweise mit weiteren Bugs und ist damit quasi schon ein Worst-Case.

etc...
 
Ich habe in den letzten 2 h mal nach Problemen mit ClamAV, Spamassassin und Amavis gesucht - und das Ergebnis ist tatsächlich erschreckend.

Amavis und Spamassassin scheinen auch gerne mal spontan abzuleben. Um damit umgehen zu können, muss man sie (z.B. mit Monit) überwachen, und ggf. neu starten. Das alles erscheint mir overkill, für meinen Mini-Server.
 
Back
Top