Spam direkt auf dem vServer filtern

Hallo Benny,
SpamAssassin ist ziemlich mächtig, braucht aber auch so einiges an Ressourcen.

Ich habe meinen Postfix um policyd-weight erweitert, und bin soweit ganz zufrieden damit.
PolicyD-Weight schaltet sich direkt in die SMTP-Kommunikation von Postfix ein, d.h. die Mail wird bereits überprüft und gegebenenfalls abgelehnt bevor diese angenommen und in die lokale Queue gestellt wird. Des Weiteren ist PolicyD-Weight äußerst schlank im Vergleich zu Tools wie SpamAssassin.

Ich verwende hier folgende Konfiguration:

/etc/policyd-weight.conf:

$TCP_PORT = 12525;
$BIND_ADDRESS = "10.0.0.1";




$LOCKPATH = "/var/run/policyd-weight/";
$PIDFILE = "/var/run/policyd-weight/policyd-weight.pid";




$ADD_X_HEADER = 1;
$REJECTLEVEL = 2;
$DEFER_LEVEL = 5;




@dnsbl_score = (
        "dnsbl.sorbs.net",              4.25,   -1.5,   "SORBS_NET",
        "pbl.spamhaus.org",             3.25,   0,      "DYN_PBL_SPAMHAUS",
        "dnsbl.njabl.org",              4.25,   -1.5,   "BL_NJABL",
        "bl.spamcop.net",               4.25,   -1.5,   "SPAMCOP",
        "sbl-xbl.spamhaus.org",         4.35,   -1.5,   "SBL_XBL_SPAMHAUS",
        "list.dsbl.org",                4.35,   0,      "DSBL_ORG",
        "ix.dnsbl.manitu.net",          4.35,   0,      "IX_MANITU",
);




@rhsbl_score = (
        "rhsbl.ahbl.org",               1.8,    0,      "AHBL",
        "dsn.rfc-ignorant.org",         3.2,    0,      "DSN_RFCI",
        "postmaster.rfc-ignorant.org",  1,      0,      "PM_RFCI",
        "abuse.rfc-ignorant.org",       1,      0,      "ABUSE_RFCI"
);




$MAXDNSBLHITS = 2;
$MAXDNSBLSCORE = 8;

/etc/postfix/main.cf:

[...]
smtpd_recipient_restrictions = permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination,
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
  reject_unknown_sender_domain,
  check_policy_service inet:10.0.0.1:12525,
  permit
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname
smtpd_helo_required = yes
smtpd_delay_reject = yes

Hallo,
kurz zur IP: Du kannst diese einfach durch die öffentliche IP deines vServer ersetzen, ja (in der policyd-weight.conf und main.cf). Aber dann ist der Policy-Daemon aus dem Internet erreichbar, was ich für keine gute Idee halte. Normalerweise würde man den Daemon an das Loopback-Device (127.0.0.1) binden. Da es bei den Netcup-vServern technisch bedingt aber kein lo-Dev gibt, habe ich mir vom Netcup-Support ein Ethernet-Alias mit einer privaten IP (10.0.0.1) erstellen lassen. Hierauf kann ich nun ohne schlechtes Gewissen meine lokalen Dienste binden lassen, da das 10er-Subnetz nicht ins Internet geroutet wird.

Ansonsten kannst du in den Logs relativ einfach kontrollieren, ob der PolicyD-Weight korrekt arbeitet.

grep policyd-weight /var/log/mail.log

Da sollten dann Zeilen wie
"decided action=550 Your MTA is listed in too many DNSBLs"
oder
"decided action=550 Mail appeared to be SPAM or forged."
oder auch
"decided action=PREPEND X-policyd-weight: ... rate: -7"
zu sehen sein.

Eine kleine Statistik deines PolicyD-Weight kannst du dir mit folgenden drei Befehlen basteln:

grep -c 'Your MTA is listed in too many DNSBLs' /var/log/mail.log
grep -c 'Mail appeared to be SPAM or forged' /var/log/mail.log
grep -c 'decided action=PREPEND X-policyd-weight' /var/log/mail.log

Die erste Zahl gibt dir an, wie viele Mails auf Grund von RBL-DNS geblockt wurden.
Die zweite Zahl sind die Mails, die wegen einer zu hohen Spam-Score abgelehnt wurden.
Und die dritte Zahl sind alle akzeptierten Mails.
Achja, und nicht wundern, wenn die Summe der ersten beiden Zahlen deutlich größer sein sollte als die dritte; bei mir liegt das Verhältnis Spam:Ham bei 9:1.

Tach,

Zitat

Theoretisch sollte sich noch mehr Spam dadurch blocken lassen, dass man Spamassassin parallel laufen lässt, richtig? Wobei... Kann man dann sicherstellen, dass Spamassassin nach policyd-weight läuft?

SpamAssassin macht nur dann Sinn, wenn in den Mails Spam zu finden ist, die durch den PolicyD-Weight durchlaufen, und anschließend in deinem Postfach landen.

Ich verwende hierfür nicht direkt den SpamAssassin, sondern AmavisD-new. Amavis ist ein Daemon wie PolicyD-Weight auch, der den Mail-Inhalt (PolicyD-Weight sieht den Inhalt noch nicht) durch diverse Filter jagt, nachdem die Mail bereits lokal angenommen wurde. So kann Amavis die Mail z.B. durch den SpamAssassin laufen lassen und mit ClamAV nach Viren checken, wobei letzteres bei mir nicht wirklich was gebracht hat. Der Amavis-Daemon bringt hierbei seine eigenen SpamAssassin-Routinen mit, d.h. es muss kein weiter SpamD o.ä. installiert/gestartet werden.
Wenn nun der PolicyD-Weight eine Mail ablehnt, dann kommt diese erst gar nicht in die lokale Mail-Queue, d.h. Amavis/SpamAssassin bekommt diese auch gar nicht zu sehen.

Wenn der AmavisD-new korrekt läuft, braucht's folgende Zeile in der main.cf:

content_filter = amavis:[10.0.0.1]:10024

Und dann noch in der master.cf folgendes anhängen:

amavis unix - - n - 2 smtp
  -o smtp_tls_security_level=none -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes




10.0.0.1:10025 inet n - n - - smtpd
  -o content_filter=
  -o local_recipient_maps=
  -o relay_recipient_maps=
  -o smtpd_tls_security_level=none
  -o smtpd_restriction_classes=
  -o smtpd_client_restrictions=permit_mynetworks,reject
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o mynetworks=10.0.0.0/16
  -o strict_rfc821_envelopes=yes
  -o smtpd_error_sleep_time=0
  -o smtpd_soft_error_limit=1001
  -o smtpd_hard_error_limit=1000

Spätestens hierfür würde ich aber unbedingt eine nicht-öffentliche IP-Adresse verwenden. Nicht das noch jemand auf die Idee kommt, seine Mails über deinen Amavis zu checken.

Zitat

Weisst du zufällig, ob der "Versender" einer abgewiesenen Mail eine Nachricht darüber bekommt?

Das ganze läuft so ab: Irgendein SMTP-Client will die Mail bei dir abliefern. Dies wird aber idR. nie eine natürliche Person mit dem Thunderbird sein, sondern der SMTP-Server eines ISPs (z.B. GMX). Eine SMTP-Verbindung sieht so aus:

1.) Begrüßung mittels EHLO
2.) MAIL FROM:Absender
3.) RCPT TO:Empfänger
4.) DATA
5.) Übermittlung der eigentlichen Mail.

Der PolicyD-Weight ist nun bei Punkt 3 dazwischen geschaltet, d.h. wenn dieser die Mail ablehnt, dann geschieht dies, bevor der Mail-Inhalt überhaupt übertragen wird. Der Rechner, der die Mail einliefert, weiß also, dass die Mail nicht zugestellt wurde und wird dies dem ursprünglichen Empfänger mitteilen.

Anders sieht es nun bei SpamAssassin aus. Dieser Content-Filter wertet die E-Mail erst aus, nachdem diese vollständig übertragen wurde. Für den einliefernden Mail-Client ist die Mail-Übertragung mit dem Übersenden des Mail-Inhalts erledigt. Was danach mit der Mail passiert, also ob diese z.B. von einem SpamAssassin als Spam markiert wird, davon weiß der Mail-Client nichts.

Daher niemals den Amavis/SpamAssassin Mails direkt löschen lassen.

Der PolicyD-Weight meldet das Ablehnen der Mail aber an den einliefernden Mail-Client, d.h. der Absender wird darüber auch informiert.

PS:

Zitat

Mal schauen, aber ich glaube das filtert schon fast alles (bis auf Newsletter) raus.

Newsletter sind auch kein Spam im klassischen Sinne.

PPS: Meine aktuelle Statistik von heute:
RBL rejected: 168
Spam rejected: 52
Ham accepted: 16
Von 236 Mails sind also nur 16 erwünscht, macht einen Spam-Anteil von über 93 Prozent.

n'Abend,
was die Weiterleitung z.B. von GMX-Mails angeht, so wirst du mit PolicyD-Weight keinerlei Erfolg haben. Denn die Kennzeichen einer Spam-Mail würden sich in diesem Fall ja ausschließlich im Inhalt der Mail befinden, und den sieht PolicyD-Weight nicht. Dieser beurteilt nur die SMTP-Kommunikation mit dem Mail-Clienten, hier also mit dem SMTP-Server von GMX. Und dieser verhält sich natürlich absolut standardkonform und ist auch in keiner RBL geblacklistet, daher werden alle GMX-Mails durchgehen.

Du müsstest in dem Fall also die Mails bei GMX bereits nach Spam-Filtern. Aber selbst der Filter in der Freemail-Variante funktioniert bei mir recht gut, kann mich nicht beschweren.

SpamAssassin könnte übrigens dann auch bei den GMX-Mails noch etwas herausholen, da dieser eben den Inhalt der Mail auf Spam-Auffälligkeiten hin untersucht.

Ansonsten: Wer braucht GMX&Co: eigene Domain, eigener Mail-Server, eigene Spam-Filter und gut ist.
Und wenn nachname.tld noch frei ist, vorname@nachname.tld kommt immer gut.

Zitat

Die Mails müssen ja auch irgendwo lokal auf dem Server liegen, richtig? Wo liegen die denn? Da köntne man sie ja immer schön "wegsichern" (wenn man eh nur sinnvolle aufhebt).

Kannst du tun. Wo du Mails aber liegen, lässt sich pauschal nicht sagen. Ich lasse meine in einem Maildir innerhalb meines Home-Directorys ablegen.

main.cf:

home_mailbox = Maildir/

Zitat

Und kann man so ne Art "Filterung" der Mails, wie in eMailprogrammen üblich, auch schon serverseitig machen? So dass z.B. alle Mails die "Benny" in Betreff haben in einen Ordner "privat" abgelegt würden?

Geht selbstverständlich auch. Für Maildir fällt mir spontan einfach procmail ein.

Dazu im Home-Directory eine Datei ".forward" mit folgendem Inhalt anlegen:

| /usr/bin/procmail

Interessant ist nun die Datei ".procmailrc" in deinem Home-Directory. Hier mal ein Beispiel, wie diese bei mir aussieht:

PATH=/bin:/usr/bin
SHELL=/bin/bash
HOME=/home/david
MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR
TRASH=$MAILDIR/.Trash
JUNK=$MAILDIR/.Junk




:0
* ^X-Spam-Flag: YES
$JUNK/




:0
* ^From:*.mailings@gmx.*\.(de|net)
$TRASH/




:0
* ^From:.*@ebay\.(de|com)
$MAILDIR/.eBay/




:0
* ^To:.*@edv-froehlich\.(de|biz)
$MAILDIR/.EDV/




:0
$DEFAULT/

Was macht das Ganze? Mails, die von SpamAssassin als Spam eingestuft werden, in den Junk-Ordner verschieben, GMX-Werbung in den Papierkorb, und eBay bzw. Firmenmails in die entsprechenden Unterordner. Lässt sich individuell anpassen und läuft wie geschmiert.

n'Abend,
achja, die guten alten RegExps (reguläre Ausdrücke).
Dazu gibt's aber per Google&Co. gaanz viel Info-Material. Und ansonsten lässt sich das auch quasi per Reverse Engineering aufbröseln, wenn man sich den Text von mir anschaut, was diese Regeln machen. Und zu guter letzt gibt's auch jede Menge Procmail-Howtos im Netz zu finden.

Ansonsten hat jeder Benutzer, der ein Mail-Konto hat, braucht seine eigene procmailrc-Datei. Filtern kannst du aber sowohl nach An (To), Von (From), und auch nach jedem beliebigen anderen Feld im Mail-Header.

In meinem Fall habe ich einen (Mail-)Benutzer pro "real existierender Person". Soll heißen ich habe nur ein einziges Mail-Konto, aber mit verschiedenen Unterordnern. Mails an mich mit verschiedenen (To-)Adressen lasse ich über die Procmail-Regeln in die entsprechenden Ordner schieben.

Aber wie gesagt, dazu (Procmail) solltest du auch reichlich Infos und Howtos im Internet finden.

Dann melde ich mich hiermit für heute auch mal ab, damit das mit dem "schönen Abend" auch tatsächlich noch was wird.

Hallo,
ein letzter Nachschlag für heute noch.

Also ich verwende bei mir Maildir-Verzeichnisse für meine Mails. Abrufen tue ich die dann mit dem Courier POP3 bzw. IMAP4 Daemon.

Wenn du bei dir gar keinen Maildir-Eintrag hast, werden deine Mails wahrscheinlich im MBox-Format abgespeichert. Ob sich damit Procmail auch benutzen lässt weiß ich nicht.

Ansonsten ist die normale Prozedur bei mir so:
Neuen (Mail-)Benutzer anlegen, mit "maildirmake" das Maildir-Verzeichnis im Home-Directory des neuen Users anlegen, und mit "chown" den Eigentümer zuweisen.
Anschließend eben Procmail einrichten.

So hat dann jeder User sein eigenes Maildir-Verzeichnis, seine eigenen Unterordner und auch seine eigenen Procmail-Filter.

Natürlich gibt es hierfür auch etliche andere Ansätze, z.B. virtuelle Mailkonten, so dass du nicht für jeden Mail-User einen eigenen Unix-User anlegen musst, uvm.. Ich hab mich eben einfach für diesen Weg entschieden.

Ansonsten einfach bisschen Googeln nach Postfix Howtos.

Hallo Benny,

Zitat

Das ist ein anderer Ansatz als bei dir, richtig? Mit "Home"-Verzeichnis meintest du auch das jeweilige Homeverzeichnis des Unix-Users dem ein Mailkonto zugeordnet war? (ich frage wegen der .forward- und .procmailrc-Files)

Das hast du korrekt erkannt. Ich habe keine virtuellen Mail-Konten, sondern für jedes Mail-Konto einen eigenen Unix-User inkl. Home-Dir. Und darin liegt dann meine procmailrc.

In sofern muss ich an dieser Stelle nun endgültig passen, mit virtuellen Mailkonten habe ich mich noch nicht beschäftigt. Diese Abschnitte habe ich in den jeweiligen Howtos einfach übersprungen.

Aber es sollte sicherlich auch die Möglichkeit geben, Procmail in virtuelle Mailkonten einzubetten. Was das "Wie" angeht, bin ich nun aber überfragt.

Dann dir auch noch viel Spass mit dieser neuen Woche, vielleicht findest du ja irgendwo im Netz noch eine passende Howto.
BTW: Nur noch eine Abiturs-Klausur in Sicht, juhu.

Hi,

hab noch zwei Wochen dann fangen bei mir die Abiprüfungen (Grundkurse) an

Gruß,

Stefan

Hi Benny,

auf dem Mailserver von meinem Kollegen verwende ich zufällig auch amavis.

Die Configdateien liegen hier:

/etc/amavis/conf.d

In dem Ordner sind mehrere vorhanden, einfach mal durchgucken; hoffe, das hilft dir.

Gruß,

Stefan