[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: procmail--Sucheinvertieren



(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 <andy@space.wh1.tu-dresden.de> 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




Reply to: