(Hab das zwar gestern mittag schonmal geschickt, scheint aber nicht
durchgekommen zu sein. Also once again...)
On 2004.05.27 14:56, Dirk Prösdorf wrote:
Andreas Schmidt [EMAIL PROTECTED] wrote:
ich will procmail nach ganzen Woertern filtern lassen, die _nicht_
vorhanden
sind. Fuer einzelne Zeichen ist das klar, das geht ohne weiteres
mit
[^verbotene_zeichen]
Aber wie sieht das fuer ganze Woerter aus, die Teil eines
Suchstrings
sind?
Mal abgesehen davon, dass ich Tools wie SpamAssassin für die
Spamsuche
als wesentlich evektiver halte als unbedingt eine Procmailregel,
Im allgemeinen stimme ich Dir da schon zu, mein Spamschutz ist
entsprechend
komplex:
Ich hole Mail von einem externen Account und sortiere schon mal die
Sachen
aus, die vom dort laufenden Filter markiert worden sind. Dann laeuft
bei mir
bogofilter, was dort durchkommt, geht durch spamassassin (und wird
gegebenenfalls bogofilter auch beigebracht). Erst danach setzen die
eigenen
procmail-rules ein.
Der Grund, warum ich nicht alles gleich per sa-learn an spamassassin
weiterreiche, ist, dass die Spams, die durchkommen, oft recht
hinterhaeltig
gestaltet worden sind. Die Sache mit der riesigen Liste unsinniger
Woerter vor
und/oder hinter dem Werbetext, gerne auch im Attachement oder in ge-
fake-ten
HTML-Tags ist ja schon ein alter Hut. Trotzdem bilde ich mir ein, dass
Bayes-
Filter dadurch verwirrt werden koennten.
Noch schlimmer sind die Spams, die eine Liste von irrelevanten
Sprichwoertern,
Witze oder andere echte Texte enthalten. Hier sind die Woerter in
einem
realen Kontext, wie sie eben auch in jeder regulaeren Mail stehen
koennten.
Wenn es sich bei diesen Texten nicht gerade um Nigeria-Stories,
Aktienangebote etc. handelt, mag ich solche
Mails eigentlich eher nicht an spamassassin verfuettern.
In diesen Faellen, denke ich, kommt man IMHO mit ein paar (OK, sind in
den
letzten Monaten schon ein paar mehr geworden :-) procmail-rules besser.
Grundannahme ist, dass alles moegliche Fake sein kann -- bis auf die
URL,
schliesslich wollen die Leute ja etwas verkaufen. Und mit ein bisschen
Aufwand
kann man doch auf regular expressions kommen, die allgemein genug sind,
um
sowohl Spamaufkommen als auch Kolateralschaeden weitestg(debian|foo|
bar)ehend
zu reduzieren. Na gut, gibt zwar auch false positives, aber da der von
den
procmail-rules entdeckte Spam ja nicht sofort nach /dev/null kommt,
ist der
Schaden auch nicht so gross...
kannst
Du mit ! auf das Nichtzutreffen einer Regel testen (siehe unten).
daher etwas wie
:0B
* $http://([^/]*\.)*${TLD}(NOT debian)*\.${TLD}
$SPAM
|:0B
|* !(debian|foo|bar)
|* $http://([^/]*\.)*${TLD}(\.[^/]+)*\.${TLD}
|$SPAM
Das hatte ich auch schon gemacht. Hatte gestern sogar dafuer eine
Begruendung
auf der Zunge, warum ich diese Variante nciht fuer optimal halte, bin
mir aber
nicht sicher, ob die wirklich so plausibel ist.
Das Problem ist ja, dass gelegentlich auch Spam an die Liste geschickt
wird.
Die Sachen haben dann also genau wie alle anderen Mails den Stempel
der
Liste, mit dem Link zur FAQ.
Fehler koennen jetzt dadurch auftreten, dass procmail eben nicht wie
cat mail | egrep -v (debian|foo|bar) | egrep $SPAMRULE
zeilenweise arbeitet, sondern alle Regeln auf die gesamte Mail
angewandt
werden. Die erste Regel wuerde also den Link zur FAQ finden und deshalb
No
match ergeben; der Spam kaeme daher durch.
Es waere daher sinnvoller, wenn man mit nur einer einzigen Regel
auskommen
koennte. Notfalls waere also wohl wirklich so etwas wie
$http://([^/]*\.)*${TLD}\.([^d][^e][^b][^i][^a][^n]).*\.${TLD}
guenstiger -- wobei das doch recht unelegant aussieht.
Schoenen Gruss,
Andreas
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
