Mailinglist Archive: opensuse-de (4880 mails)
| < Previous | Next > |
Re: Kasperfilter
- From: Thorsten Haude <linux@xxxxxxxxxxxxxx>
- Date: Sat, 22 Nov 2003 13:05:01 +0100
- Message-id: <20031122120501.GA1276@xxxxxxxxxxxxxxx>
Moin,
* David Haller <david@xxxxxxxxxx> [2003-11-20 02:18]:
>Am Tue, 18 Nov 2003, Thorsten Haude schrieb:
>>* David Haller <david@xxxxxxxxxx> [2003-11-18 01:30]:
>>> Welche unserer procmail vs. Mail::Audit (oder was verwendest du
>>> noch gleich?) Diskussionen meinst du? Wenn du die IIRC letzte
>>> meinst, dann hatte ich da schlicht nix mehr zu zu sagen.
>>
>>Und scheinbar auch nichts mehr zu lesen. Versuch's doch nochmal,
>>vielleicht findest Du ja doch etwas Interessantes.
>
>Ok, sorry. Du verwendest maildrop, nicht Mail::Audit. Da hab ich was
>durcheinandergebracht.
Uh. Nein, wieder falsch, ich benutze beides.
Mail::Audit würde ich allerdings niemandem empfehlen wollen; ich kenne
die Macken jetzt so einigermaßen, so daß ich nicht zwingend umsteigen
muß, aber auch ich werde es nirgends mehr neu installieren.
>>>Mir geht es sonstwo vorbei was du zum filtern verwendest
>>
>>Das geht mir ähnlich, mich stört es nur, daß Newbies Procmail
>>empfohlen wird, als wäre es ein benutzbares Programm.
>
>Benutzbar ist procmail. Ob einfacher oder schwieriger fuer einen
>"Newbie" (der auch kein perl, keine shell usw. kennt!) als maildrop,
>das kann ich nicht beurteilen.
Noch kennt der Newbie keine Shell, die wird er aber über kurz oder
lang brauchen, also hilft die Ähnlichkeit.
>Ist maildrop eigentlich bei der SuSE dabei? Lt. nem 'zgrep maildrop
>SuSE-8.2-ARCHIVES.gz' ist das nicht der Fall. Da man "$NEWBIE" auch
>nicht gleich ne Kompilation an den Hals haengen will, haben wir ein
>Dilemma. Hast du mal angeregt, dass maildrop in der SuSE landet?
Auf meinen SuSEs war das immer dabei, solange ich das Programm
benutze. Wenn die das jetzt nicht mehr liefern, frage ich mich
natürlich bösartig, ob die damit rechnen, am Support für Procmail
mehr Geld zu verdienen als am Support für Maildrop.
>Ich hab mir jetzt maildrop mal gesaugt und kompiliert, aber noch nicht
>installiert. Ich will mir das erstmal genauer anschauen und testen.
Gut!
>[Apropos an die Mitleser: maildrop ist teils in C, teils in C++
>(leicht chaotisch vermengt) geschrieben, sollte also fast so flott
>beim Starten sein wie procmail.
Na, dann will ich mal hoffen, daß es auch darüber eine Statistik geben
wird.
>>> Solange eine Diskussion zwischen uns dabei das Potential hat,
>>> anderen beim Entscheidungsprozess pro oder contra $MAIL_FILTER zu
>>> helfen bin ich dabei. Wenn aber die Argumente ausgetauscht sind,
>>> dann ist es gut. Dann soll sich jeder selbst ein Bild machen.
>>
>>Na, dann tausch mal aus. Als kleinen Anhaltspunkt: Ich hatte eine
>>Lösung für Maildrop gepostet, die so arbeitet wie die beiden Krücken,
>>die Ratti und Du als Kasperfilter einsetzen.
>
>Die kam bei mir erst recht spaet an. Die Eleganz daran kann man der
>nicht absprechen (v.a. wenn der Inhalt von $FROM eine einfache RE auf
>die Relevanten Header ist).
Ne, das ist der Message Envelope Sender, die Regexe stecken in der
Datei, die Du mit lookup einliest.
Was ich mir wahrscheinlich selbst basteln muß ist etwas um Perl's hash
zu ersezten, ich will nämlich den Namen der Mailboxen aussuchen, in
denen Mailinglisten landen.
>>(Wobei ich ehrlicherweise sagen muß, daß ich überrascht war, daß man
>>Procmail tatsächlich dazu bringen kann, Code und Daten so sauber zu
>>trennen wie das Ratti gelungen ist.)
>
>*g* Bei meiner Loesung fehlt ja auch nicht viel, zumal ich alles aus
>den '* 1^0 ...' auch um's "includerc" packen koennte.
Na, ein #include ist wohl kaum das gleich wie Trennung von Code
und Daten.
>Ratti's Loesung ist gut, hat aber den Nachteil formail und fgrep
>aufzurufen (was auf alten Kisten relevant sein kann).
Denk daran nochmal, wenn Du dann mißt, ob Procmail schneller ist
als Maildrop.
>Im Prinzip fehlt procmail ein Substitutionsmechanismus, der sowas wie
>
> * ^Foo: (`perl -e '@_=<>;chomp(@_);print join("|",@_), "\n";' < FILE`)
>
>machen wuerde, wuerde procmail das `` ausfuehren.
Ok, bei Procmail mit inline Perl gebe ich mir nichtmal Mühe: Was
bewirkt diese Zeile?
>Fuer einfache "Anforderungen" muss man (wie ich schon oefter schrieb)
>nicht viel wissen. Das, was die meisten MUAs koennen, dafuer reicht
>ein:
>
>====
>:0 H
>* BEDINGUNG
>mbox-datei
>====
>
>Damit kommen selbst Newbies schnell klar. Interessant wird's, wenn die
>Bedingungen und die Aktionen komplexer werden. Da hat dann maildrop
>wohl Vorteile. Nunja, mir reichen fast immer solche einfachen Regeln...
Wenn ich nur solche einfachen Reglen bräuchte, würde ich auf einen MDA
verzichten und das mit KMail oder so machen. Erst wenn es
komplizierter wird, wird auch interessant.
Procmail ist also nur dann brauchbar, wenn man es nicht braucht.
>>Das ist etwa so, als würde man Anfängern ed(1) statt $EDITOR
>>empfehlen,
>
>Nee, der Vergleich passt net. Nimm vim oder (x)emacs im Vergleich zu
>kedit, kate, gedit, xedit, mcedit und aehnlich simple Editoren.
Das wäre nur dann ein besserer Vergleich, wenn man mit Procmail
deutlich mehr machen könnte als mit Maildrop. Es ist aber umgekehrt.
>>Ganz anders dagegen der Vergleich von zB. NEdit und Vim. Da sind
>>Bedienkonzept so unterschiedlich und in beiden Fällen der
>>Funktionsumfang so groß, daß man sich leicht vorstellen kann, daß
>>einem das eine oder andere gefällt. (EmacsOS, naja...)
>
>*lol* Ja, schwieriger wird der Vergleich zwischen Emacs und Nedit ;)
>Da gibt's kein "k.o."-Kriterium des Modus-basierten editierens wie im
>Vergleich mit vim ;)
Nö, aber Lisp ist da ein adäquater Ersatz.
>[lass uns den Editor-War diesmal auslassen, ok?]
Ooch menno...
>>Ok, wie wär's mit einem Tausch: Ich fixe meinen Msg-ID und Du rätst in
>>Zukunft den armen Newbies zu Maildrop?
>
>Nein. Dazu kenne ich maildrop (noch!) nicht genug. Das musst du also
>noch ne Weile allein machen.
Ich kann warten (hehe).
>Dazu hab ich das figlet.el allerdings noch etwas aufbohren
>muessen[1], aber ich vermute mal, fuer die gleiche Funktionalitaet
>musst du bei vim und nedit auch "Hand anlegen" :)
Ne, ein figlet-Modul gibt es nicht wirklich für NEdit. Ist wohl auch
nicht so kompliziert, daß man es nicht mal eben selbst machen kann.
>>Ansonsten bin ich sicher, eine ähnliche Kurzsichtigkeit bzgl. Msg-IDs
>>an den Tag legen zu können
>
>Bitte nicht. Wer hat das RfC 2822 rausgekruschtelt? Ah, danke Mathias
>Bauer! Bitte lese dir da den genannten Abschnitt 3.6.4 durch. Eine
>gueltige Msg-ID ist auch in deinem Sinne!
Ja klar, ich sehe nur nicht die hohe Priorität.
>>(Mail::Audit-Syntax ist übrigens Perl. Du würdest vermutlich etwa 30
>>Sekunden brauchen, um zu verstehen, wie man da Filter schreibt, die
>>alles in den Schatten stellen, was Procmail zu bieten hat.)
>
>Ja, dafuer ist aber die Performance fuer mich nicht brauchbar ;)
<shrug/> Geht deutlich schneller, als ich die Mails lesen kann, also
stört's mich nicht. Mein Rechner steht eh den längsten Teil des Tages
nur 'rum.
>PS: ich finde es gut, dass du (wie ich bei anderen Sachen) immer
> wieder Alternativen nennst, weiter so! Nur dein "Tonfall" neigt
> manchmal zum poltern ;)
Jepp.
Thorsten
--
Getting a thrill out of some stupid quote is a sign of idiocy.
- turmeric
* David Haller <david@xxxxxxxxxx> [2003-11-20 02:18]:
>Am Tue, 18 Nov 2003, Thorsten Haude schrieb:
>>* David Haller <david@xxxxxxxxxx> [2003-11-18 01:30]:
>>> Welche unserer procmail vs. Mail::Audit (oder was verwendest du
>>> noch gleich?) Diskussionen meinst du? Wenn du die IIRC letzte
>>> meinst, dann hatte ich da schlicht nix mehr zu zu sagen.
>>
>>Und scheinbar auch nichts mehr zu lesen. Versuch's doch nochmal,
>>vielleicht findest Du ja doch etwas Interessantes.
>
>Ok, sorry. Du verwendest maildrop, nicht Mail::Audit. Da hab ich was
>durcheinandergebracht.
Uh. Nein, wieder falsch, ich benutze beides.
Mail::Audit würde ich allerdings niemandem empfehlen wollen; ich kenne
die Macken jetzt so einigermaßen, so daß ich nicht zwingend umsteigen
muß, aber auch ich werde es nirgends mehr neu installieren.
>>>Mir geht es sonstwo vorbei was du zum filtern verwendest
>>
>>Das geht mir ähnlich, mich stört es nur, daß Newbies Procmail
>>empfohlen wird, als wäre es ein benutzbares Programm.
>
>Benutzbar ist procmail. Ob einfacher oder schwieriger fuer einen
>"Newbie" (der auch kein perl, keine shell usw. kennt!) als maildrop,
>das kann ich nicht beurteilen.
Noch kennt der Newbie keine Shell, die wird er aber über kurz oder
lang brauchen, also hilft die Ähnlichkeit.
>Ist maildrop eigentlich bei der SuSE dabei? Lt. nem 'zgrep maildrop
>SuSE-8.2-ARCHIVES.gz' ist das nicht der Fall. Da man "$NEWBIE" auch
>nicht gleich ne Kompilation an den Hals haengen will, haben wir ein
>Dilemma. Hast du mal angeregt, dass maildrop in der SuSE landet?
Auf meinen SuSEs war das immer dabei, solange ich das Programm
benutze. Wenn die das jetzt nicht mehr liefern, frage ich mich
natürlich bösartig, ob die damit rechnen, am Support für Procmail
mehr Geld zu verdienen als am Support für Maildrop.
>Ich hab mir jetzt maildrop mal gesaugt und kompiliert, aber noch nicht
>installiert. Ich will mir das erstmal genauer anschauen und testen.
Gut!
>[Apropos an die Mitleser: maildrop ist teils in C, teils in C++
>(leicht chaotisch vermengt) geschrieben, sollte also fast so flott
>beim Starten sein wie procmail.
Na, dann will ich mal hoffen, daß es auch darüber eine Statistik geben
wird.
>>> Solange eine Diskussion zwischen uns dabei das Potential hat,
>>> anderen beim Entscheidungsprozess pro oder contra $MAIL_FILTER zu
>>> helfen bin ich dabei. Wenn aber die Argumente ausgetauscht sind,
>>> dann ist es gut. Dann soll sich jeder selbst ein Bild machen.
>>
>>Na, dann tausch mal aus. Als kleinen Anhaltspunkt: Ich hatte eine
>>Lösung für Maildrop gepostet, die so arbeitet wie die beiden Krücken,
>>die Ratti und Du als Kasperfilter einsetzen.
>
>Die kam bei mir erst recht spaet an. Die Eleganz daran kann man der
>nicht absprechen (v.a. wenn der Inhalt von $FROM eine einfache RE auf
>die Relevanten Header ist).
Ne, das ist der Message Envelope Sender, die Regexe stecken in der
Datei, die Du mit lookup einliest.
Was ich mir wahrscheinlich selbst basteln muß ist etwas um Perl's hash
zu ersezten, ich will nämlich den Namen der Mailboxen aussuchen, in
denen Mailinglisten landen.
>>(Wobei ich ehrlicherweise sagen muß, daß ich überrascht war, daß man
>>Procmail tatsächlich dazu bringen kann, Code und Daten so sauber zu
>>trennen wie das Ratti gelungen ist.)
>
>*g* Bei meiner Loesung fehlt ja auch nicht viel, zumal ich alles aus
>den '* 1^0 ...' auch um's "includerc" packen koennte.
Na, ein #include ist wohl kaum das gleich wie Trennung von Code
und Daten.
>Ratti's Loesung ist gut, hat aber den Nachteil formail und fgrep
>aufzurufen (was auf alten Kisten relevant sein kann).
Denk daran nochmal, wenn Du dann mißt, ob Procmail schneller ist
als Maildrop.
>Im Prinzip fehlt procmail ein Substitutionsmechanismus, der sowas wie
>
> * ^Foo: (`perl -e '@_=<>;chomp(@_);print join("|",@_), "\n";' < FILE`)
>
>machen wuerde, wuerde procmail das `` ausfuehren.
Ok, bei Procmail mit inline Perl gebe ich mir nichtmal Mühe: Was
bewirkt diese Zeile?
>Fuer einfache "Anforderungen" muss man (wie ich schon oefter schrieb)
>nicht viel wissen. Das, was die meisten MUAs koennen, dafuer reicht
>ein:
>
>====
>:0 H
>* BEDINGUNG
>mbox-datei
>====
>
>Damit kommen selbst Newbies schnell klar. Interessant wird's, wenn die
>Bedingungen und die Aktionen komplexer werden. Da hat dann maildrop
>wohl Vorteile. Nunja, mir reichen fast immer solche einfachen Regeln...
Wenn ich nur solche einfachen Reglen bräuchte, würde ich auf einen MDA
verzichten und das mit KMail oder so machen. Erst wenn es
komplizierter wird, wird auch interessant.
Procmail ist also nur dann brauchbar, wenn man es nicht braucht.
>>Das ist etwa so, als würde man Anfängern ed(1) statt $EDITOR
>>empfehlen,
>
>Nee, der Vergleich passt net. Nimm vim oder (x)emacs im Vergleich zu
>kedit, kate, gedit, xedit, mcedit und aehnlich simple Editoren.
Das wäre nur dann ein besserer Vergleich, wenn man mit Procmail
deutlich mehr machen könnte als mit Maildrop. Es ist aber umgekehrt.
>>Ganz anders dagegen der Vergleich von zB. NEdit und Vim. Da sind
>>Bedienkonzept so unterschiedlich und in beiden Fällen der
>>Funktionsumfang so groß, daß man sich leicht vorstellen kann, daß
>>einem das eine oder andere gefällt. (EmacsOS, naja...)
>
>*lol* Ja, schwieriger wird der Vergleich zwischen Emacs und Nedit ;)
>Da gibt's kein "k.o."-Kriterium des Modus-basierten editierens wie im
>Vergleich mit vim ;)
Nö, aber Lisp ist da ein adäquater Ersatz.
>[lass uns den Editor-War diesmal auslassen, ok?]
Ooch menno...
>>Ok, wie wär's mit einem Tausch: Ich fixe meinen Msg-ID und Du rätst in
>>Zukunft den armen Newbies zu Maildrop?
>
>Nein. Dazu kenne ich maildrop (noch!) nicht genug. Das musst du also
>noch ne Weile allein machen.
Ich kann warten (hehe).
>Dazu hab ich das figlet.el allerdings noch etwas aufbohren
>muessen[1], aber ich vermute mal, fuer die gleiche Funktionalitaet
>musst du bei vim und nedit auch "Hand anlegen" :)
Ne, ein figlet-Modul gibt es nicht wirklich für NEdit. Ist wohl auch
nicht so kompliziert, daß man es nicht mal eben selbst machen kann.
>>Ansonsten bin ich sicher, eine ähnliche Kurzsichtigkeit bzgl. Msg-IDs
>>an den Tag legen zu können
>
>Bitte nicht. Wer hat das RfC 2822 rausgekruschtelt? Ah, danke Mathias
>Bauer! Bitte lese dir da den genannten Abschnitt 3.6.4 durch. Eine
>gueltige Msg-ID ist auch in deinem Sinne!
Ja klar, ich sehe nur nicht die hohe Priorität.
>>(Mail::Audit-Syntax ist übrigens Perl. Du würdest vermutlich etwa 30
>>Sekunden brauchen, um zu verstehen, wie man da Filter schreibt, die
>>alles in den Schatten stellen, was Procmail zu bieten hat.)
>
>Ja, dafuer ist aber die Performance fuer mich nicht brauchbar ;)
<shrug/> Geht deutlich schneller, als ich die Mails lesen kann, also
stört's mich nicht. Mein Rechner steht eh den längsten Teil des Tages
nur 'rum.
>PS: ich finde es gut, dass du (wie ich bei anderen Sachen) immer
> wieder Alternativen nennst, weiter so! Nur dein "Tonfall" neigt
> manchmal zum poltern ;)
Jepp.
Thorsten
--
Getting a thrill out of some stupid quote is a sign of idiocy.
- turmeric
| < Previous | Next > |