Mailinglist Archive: opensuse-de (4880 mails)

< Previous Next >
Re: Kasperfilter
  • From: David Haller <david@xxxxxxxxxx>
  • Date: Sun, 23 Nov 2003 03:49:03 +0100
  • Message-id: <20031123024902.GB1368@xxxxxxxxxxxxxxxxxx>
Hallo Thorsten,

Am Sat, 22 Nov 2003, Thorsten Haude schrieb:
>* 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.

Mann, du machst's einem aber auch schwer! Poeser Pursche tu!

[..]
>>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.

Ok. Die "Aehnlichkeit" der Syntax zu shell/perl etc. ist ein Vorteil.

>>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.

Das ist dann aber noch nicht allzu lange ;) Als ich konkret ein
Filter-Programm brauchte, war's jedenfalls defitiv noch nicht auf der
SuSE dabei...

dh@slarty[1]: ~ (0)$ zgrep maildrop /.../SuSE-6.2-ARCHIVES.gz
dh@slarty[1]: ~ (1)$

Hm. Wann kam die 7.1 raus? Da war maildrop dann offenbar dabei...

Apropos, ich muss mal mein Archiv von ARCHIVE.gz/INDEX.gz/ls-lR.gz-Dateien
vervollstaendigen ;)

>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.

Jo, is seltsam, dass es scheinbar nicht mehr dabei ist...

>>Ich hab mir jetzt maildrop mal gesaugt und kompiliert, aber noch nicht
>>installiert. Ich will mir das erstmal genauer anschauen und testen.
>
>Gut!

Gell?

>>[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.

Ok, mach ich dann, wenn moeglich. Wg. libstdc++ duerfte es aber nen
Tick langsamer bei starten sein...

Mehr Sorgen macht mir eh das chaotische Vermengen von C und C++...

>>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,

Also nicht (auch) der "From: "-Header? Dann ist die Variable aber
irrefuehrend benamst.

>die Regexe stecken in der Datei, die Du mit lookup einliest.

Ja, das war schon klar.

Ich dachte, dass in $FROM sowas wie:

'(From |X-Envelope-From: |From: |Sender: )'

drinsteckt, auf die dann die aus der Datei eingelesen REs gematcht
werden.

[..]
>>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.

Ja, klar.

>>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?

Garnix, denn das `` geht in procmail nicht :) Ich schrieb ja: procmail
"*fehlt*" sowas wie...

Der perl-Befehl bastelt einfach aus zeilenweise in einer Datei "FILE"
abgelegten REs eine "grosse" RE:

^Foo: (zeile1|zeile2|...|zeileN)

Was der perl-Befehl macht kannst du leicht mittels einem:

echo -e 'a\nb\nc' | perl -e '@_=<>;chomp(@_);print join("|",@_);'

nachvollziehen. Das ', "\n"' am Ende ist flasch, war aber ja eh nur
"meta-code" ;)

Und jetzt pack das Ergebnis noch in umgebende () und du hast eine
egrep-RE ;)

Aber wie gesagt: _das_ geht in procmail nicht, dass man teil-REs aus
einer Datei so einliest. Wenn es das gaebe, das waere schon praktisch,
eben z.B. fuer ein killfile:

:0
* ^From: (`perl -e ... < killfile`)
/dev/null

Wobei man eigentlich das `perl ...` intern erledigen sollte, is ja
eigentlich kein Aufwand, ist ja nur ein "tr '\n' '|'" oder so...

>>[lass uns den Editor-War diesmal auslassen, ok?]
>
>Ooch menno...

XEmacs RULEZ!!!!

>>>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).

Gut.

>>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.

Jep.

,----[ ~/.xemacs/lisp/sh-cmd.el ]
| (defun figlet-on-region () (interactive)
| (shell-command-on-region (region-beginning) (region-end) "figlet" t))
|
| (defun figlet-on-region-with-font (font)
| (interactive list (read-from-minibuffer "Font: "))
| (setq command (concat "figlet -f " font))
| (shell-command-on-region (region-beginning) (region-end) command t))
`----

Das ist IMO sogar wenn man kein eLisp kenn noch halbwegs
nachvollziehbar ;) Den interaktiven Kram und die Variablendefinition
musst du eben auf die passenden Makros usw. umbiegen...

>>>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.

Ich schon.

>>>(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.

Bei mir kommen Mails halt "im Schwung" rein, da meine Kiste nur
laeuft, wenn ich auch davor sitze... Und online bin ich dann auch
nicht oft... Kurz, da sind dann halt gern mal 300-500 Mails in der
queue, und da ist dann die Verarbeitungszeit pro Mail dann doch
interessant...

>>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.

*g* Wegen mir kannst du ja ruhig "rumpoltern", ich kenn das ja von dir
und hab auch keine Probleme damit :) Andere kennen / moegen das aber
weniger... Generell waere es u.U. passender, wenn du hier versuchst,
das poltern etwas zu reduzieren ;)

-dnh, der ja auch ab und an mal etwas deutlicher wird :)

--
} Some time ago, ISawAGN for the Mind::Reader package. Still can't find it
} on CPAN. -- } Satya and Rik
The DrillImpenetrableMatter() and ExtractNonexistentInfo() functions are still
giving all kinds of trouble. Let's not even speak about Coherentify().

< Previous Next >
This Thread
Follow Ups