On Friday 14 November 2003 20:35, Rafael Kolless wrote:

Ich hatte dieses Problem auch mit einem falschen DMA-Modus. Ich habe dann in der /etc/sysconfig/hardware bei dem Brenner fest udma2 eingetragen, dann lief alles wieder.

Hm, als ich DMA abgeschaltet hatte, hat er sich gar nicht gerührt (input/ output error), dann hab ich DMA/16 angeschaltet und dann hat er immerhin angefangen...

Ich habe immer Fehlermeldungen vom SMTP-Server erhalten und KMail meinte der Versand war nicht erfolgreich. Das Problem liegt wohl am SMTP von suse@nitwit.de, er meldet immer: Hi. This is the qmail-send program at mx06.ispgateway.de. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <suse@nitwit.de>: This message is looping: it already has my Delivered-To line. (#5.4.6) Am Samstag, 15. November 2003 20:21 schrieb Rafael Kolless:

Am Freitag, 14. November 2003 09:57 schrieb suse@nitwit.de:

...

On Friday 14 November 2003 20:35, Rafael Kolless wrote:

...

Ich hatte dieses Problem auch mit einem falschen DMA-Modus. Ich habe dann in der /etc/sysconfig/hardware bei dem Brenner fest udma2 eingetragen, dann lief alles wieder.

Hm, als ich DMA abgeschaltet hatte, hat er sich gar nicht gerührt (input/ output error), dann hab ich DMA/16 angeschaltet und dann hat er immerhin angefangen...

DMA/16 entspricht dem Standard-DMA. UDMA2 ist DMA/33, dann sollte das Einfrieren von KDE aka K3B vorbei sein.

Yast2 zeigt übrigends diesen Modus nicht unbedingt bei allen CD-Laufwerken als zur Auswahl an, ist aber erst seit der 9.0 so.

-- www.pinguin-and-knights.org 2003 by Lontro

Aber sonst geht es dir gut? Besuch doch mal einen guten Therapeuten.

Hi, * Am 14.11.2003 (23:38) schrieb suse@nitwit.de:

Nein, das Problem liegt in deiner debilen, völlig verpickelt-hoffnungenslos-doofen Birne.

Was soll daß? Hat Rafael Dir irgendetwas getan?? -sa -- sa at programmers-world dot com http://www.livingit.de Boomarks online: http://www.mobile-bookmarks.info Soon available in english Mail geschrieben: Sonntag, den 16. November 2003 um 00:44

Am Samstag, 15. November 2003 09:01 schrieb suse@nitwit.de:

Inzw. läuft die Kiste übrigens ganz gut. Mein erster PCI-Slot schein

Das interessiert hier wohl niemanden mehr! Rüdiger

Am Samstag, 15. November 2003 12:45 schrieb suse@nitwit.de:

On Sunday 16 November 2003 09:17, Rüdiger Meier wrote:

...

Das interessiert hier wohl niemanden mehr!

Haha, ja, genau das ist der Punkt :->

Versuch mal drüber nachzudenken :->

Den Satz kenne ich, aber aus einem anderen "Forum" Deine Reaktion ist mir völlig unverständlich, hat es Dich genervt, dass ich die Mailer-Daemon-Meldung hier gepostet habe? Eigentlich wollte ich damit erreichen, dass Du die Meldung mitbekommst, denn direkt konnte ich sie dir ja nicht schicken. Aber da habe ich wohl zu weit gedacht. -- www.pinguin-and-knights.org 2003 by Lontro

On Sunday 16 November 2003 15:06, Stefan Onken wrote:

er ist so. Nicht weiter rueber nachdenken, Kill File anschmeissen ^^^^^^^^^ und Thema durch. Immerhin kann er ein Touret Syndrom gut simulieren ^^^^^^^^^^

Genau, Onken und wenn du es jetzt schon schaffen würdest, nur das kill file "anzuschmeissen" (und nicht vergessen, es auch wirklich zu machen) *und* die Fresse zu halten, dann wärst du erwachsen. Und vielleicht sogar ein klein wenig intelligent. Typischer Talkshow-Trottel. Arschloch (Ärtze - Schrei nach Liebe)

Andreas Hergesell am Montag, 17. November 2003 12:16:

So suse@nitwit.de jetzt reichts.

Am Montag, 17. November 2003 11:55 schrieb suse@nitwit.de:

...

Typischer Talkshow-Trottel.

Arschloch (Ärtze - Schrei nach Liebe)

*PLONK*

Andreas

Toll, der Troll schafft es ja in Rekordzeit, in diversen Killfiles zu landen. Ich glaub, so schnell war noch keiner. -- Gruß MaxX 8-)

Moin, Am Mo, den 17.11.2003 schrieb Hans-Robert Wagner um 18:52:

warum plonkt ihr nicht leise?

Weil man gelegentlich eine tote Krähe beim Kornfeld aufhängen muß, damit andere Krähen begreifen, daß der lange schwarze Stock nicht nur Bumm macht, sondern auch Aua. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

Hi, * Am 17.11.2003 (11:55) schrieb suse@nitwit.de:

Typischer Talkshow-Trottel.

Arschloch (Ärtze - Schrei nach Liebe)

____ _ ___ _ _ _ __ __/\_| _ \| | / _ \| \ | | |/ /_/\__ \ / |_) | | | | | | \| | ' /\ / /_ _\ __/| |__| |_| | |\ | . \/_ _\ \/ |_| |_____\___/|_| \_|_|\_\ \/ -- sa at programmers-world dot com http://www.livingit.de Boomarks online: http://www.mobile-bookmarks.info Soon available in english Mail geschrieben: Montag, den 17. November 2003 um 12:25

Am Montag, 17. November 2003 14:28 schrieb Michael Raab:

* suse@nitwit.de postete am 17. Nov. 2003 folgendes:

...

On Sunday 16 November 2003 15:06, Stefan Onken wrote:

Ihr beiden luser tragt euren Schrott woanders aus!! mfg Juergen

* David Haller textete am 17.11.03:

Am Mon, 17 Nov 2003, Juergen Jaeckel schrieb:

...

Am Montag, 17. November 2003 14:28 schrieb Michael Raab:

...

* suse@nitwit.de postete am 17. Nov. 2003 folgendes:

...

On Sunday 16 November 2003 15:06, Stefan Onken wrote:

Ihr beiden luser tragt euren Schrott woanders aus!!

Watt? Wer bist du denn?

Einer der drei Namen zitiert und die dann als "Ihr beiden" tituliert und "Loser" fast richtig geschrieben hat. Ab damit nach suse-talk. cu flo -- Wenn der grosse kasper das höhrt, hüpft er vor Wut aus dem Suppentopfhäuschen und nimmt die allergrösste Grobpatsche mit. Dann macht der grosse Kasper Klöpfchen, klöpfchen , immer auf das hohle , hohle Köpfchen. [WoKo in dag°]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo David Am Montag, 17. November 2003 17:27 schrieb David Haller:

Hallo,

Am Mon, 17 Nov 2003, Juergen Jaeckel schrieb:

...

Am Montag, 17. November 2003 14:28 schrieb Michael Raab:

...

* suse@nitwit.de postete am 17. Nov. 2003 folgendes:

...

On Sunday 16 November 2003 15:06, Stefan Onken wrote:

Ihr beiden luser tragt euren Schrott woanders aus!!

Watt? Wer bist du denn? Wahrscheinlich auch ein l-User *LoL*

CU Thorsten - -- Thorsten Körner | http://www.123tkShop.org openSource e-Commerce | http://www.123tk.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/uRV+s5R35vLkl/cRApAtAKCO9Bcryo3X9CK0r65SISt2NhxjywCgjzTE VMJVJM1lcrt2HugZP3e7cbA= =8JuS -----END PGP SIGNATURE-----

On Sunday 16 November 2003 15:06, Stefan Onken wrote:

und Thema durch. Immerhin kann er ein Touret Syndrom gut simulieren

Der Hinweis mit der Psychotherapie war übrigens ernst gemeint. Das hast du noch nicht so ganz verstanden... Im Gegensatz zu dir soll das gar keine halbstarke Beleidung eines in die Ecke Gedrängten sein. Und schon gar keine Verspottung von Menschen, die darunter zu leiden haben. Ein Tourett (sicher ein Tippfehler) Syndrom ist keine lustige Sache, Onken, solche Sprüche geben mir auf der ganzen Linie Recht - aber gut, das wusste ich vorher auch schon :-> Du würdest dich gut als Selbstmordattentäter oder Soldat von George Bush machen. Arschloch

Am 17.11.2003 um 13:04 Uhr schrieb Thorsten Körner:

...

Arschloch Interessante Grußformel und Absenderangabe

*LOL* Sorry - ich glaub', dass war die erste wirklich sinnvolle Antwort an den Absender @nitwit.de. DANKE Thorsten. Ich muss mich wohl jetzt auch einmal mit killfiles auseinandersetzen ;-) cu PeeGee

* Rafael Kolless <rafael@mondoria.de>:

Am Samstag, 15. November 2003 12:45 schrieb suse@nitwit.de:

...

Versuch mal drüber nachzudenken :->

Den Satz kenne ich, aber aus einem anderen "Forum"

Der Satz lautet "Denkt' mal drüber nach!". ;) SCNR Andreas -- Last Exit autoexec.bac => echo y | format c:

On Sun, 16 Nov 2003 19:10:25 +0100 Joerg Rossdeutscher <ratti@gesindel.de> wrote:

Zu guter Letzt muß man nur noch die Datei ~/.plonk mit Adressen füllen:

cat ~/.plonk timo@nitwit.de marcel-stein@arcor.de suse@nitwit.de

Sollte man nicht die gesamte Domain nitwit.de (mit Subdomains) sperren? Die gehört nämlich unserem TvD. Von den verbalen Entgleisungen einer bestimmten Person erfahre ich seit gestern nur noch durch die Reaktion anderer: Ich habe "nitwit.de" als Spammer eingetragen.

...und Ruhe ist.

... bis er wieder seine Mailadresse ändert. Gruß, Steffen

Hallo Jörg, hallo Liste, * Jörg Rossdeutscher <ratti@gesindel.de> [2003-11-16 21:03] schrieb:

Weiter mit einem Ausschnitt aus meiner ~/.procmailrc:

PLONK=/home/ratti/.plonk :0: * ? (formail -x From: -x Sender: -x Reply-To: -x Received: | fgrep -iqf $PLONK) /home/ratti/plonk

Das ist aber ein Absenderfilter. Die unnötigen Diskussionen, die von diesen Leuten angestoßen werden und die i.d.R. als lästiges Rauschen betrachtet werden, filterst Du damit nicht aus. IMHO müsste man da noch die Kopfzeilen In-Reply-To: und References: irgendwie integrieren. Allerdings sehe ich nicht, wie sich das in deinen Einzeiler aufnehmen lässt, *ohne* dass es zu vielen false-positives kommt und man mit der manuellen Korrektur des Filterergebnisses mehr Arbeit hat als ganz ohne Filter. Am 31. Oktober 2003 habe ich unter dem Betreff "Vier Emailfilter mit procmail" einige alternative Lösungen vorgestellt, die ich nach langer Entwicklung für ausgereift halte. (Klar, das muss natürlich jeder für sich beurteilen.) Darunter neben einem Absenderfilter auch einen Threadfilter, der auf Basis von Message-IDs funkioniert. Leider erhielt ich wegen der beiden Megathreads um Boykott-Briefe und den Verkauf von SuSE damals kein Feedback :-(

Im Klartext: Alle Mailadressen, die in ~/.plonk stehen, schicken ihre Post in die Datei ~/plonk. Die lese ich i.d.R. nicht. Gelegentlich mache ich ein

cat ~/plonk >> /var/spool/mail/ratti rm ~/plonk

(Achtung, /var/spool/mail/ratti darf nicht in Benutzung sein) und schaue, ob ein Wunder geschehen ist. Bisher hat sich aber nix ereignet, was mich an meiner religiösen Enthaltsamkeit zweifeln lässt.

Wenn du damit meinst, dass sich die Insassen deines Killfiles (s.u.) darin richtig wohl fühlen, kann ich dir nur bestätigen, dass das auch bei mir so ist. Sämtliche `Bewährungsauflagen' wurden bisher gebrochen, so dass ich mein Urteil nun in ... äh ... lebenslänglich umgewandelt habe ... hehehe.

Zu guter Letzt muß man nur noch die Datei ~/.plonk mit Adressen füllen:

cat ~/.plonk timo@nitwit.de marcel-stein@arcor.de suse@nitwit.de

...und Ruhe ist.

Gute Ausgangsbasis. Full ACK!

Das schöne an diesem Verfahren ist, daß man nicht dauernd in der .procmailrc rumwurschteln muss und durch Tippfehler seine Mails ins Nirvana schickt - man muss nur den Kram in der .plonk-Datei ändern.

Das ist auch bei meiner Lösung so. Eigentlich sollte überall die Komplexität von der Konfiguration getrennt sein. Ein hehrer Anspruch, ich weiß... Gruß, Mathias -- Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich. Grundgesetz, Artikel 10, Abs. 1 Infos rund um Email-Verschlüsselung --> www.gnupp.de Mein OpenPGP-Schlüssel 0x3B458473 --> blackhole.pca.dfn.de

Guten Morgen Antje und Liste, * Antje M. Bendrich <list@bendrich.de> [2003-11-16 23:50] schrieb: [Diskussion über killauthor-feature]

Man nehme mutt und lege sich "delete-subthread" auf eine persönlich genehme Taste -- sofern die Standardkombination ESC d nicht zusagt.

Die Luxusvariante ließe sich erreichen, indem Mails der Bewohner des (Pseudo-)Killfiles von mutt in einer ekligen Farbe dargestellt werden, damit man das ESC d fast reflexartig ausführt.

Fast relexartig drücke ich Esc+F+a um den Absender ins Killfile zu befördern, Esc+F+d um Mails der Absender-Domain oder Esc+F+t um Emails eines Threads auszufiltern. Das geht mit mutt natürlich prima: ---------- schnipp ---------- macro index <esc>Fa "<pipe-message>senderfilter.sh --add<enter>" \ "Filtere Nachrichten mit Absender aus" macro index <esc>Fd "<pipe-message>domainfilter.sh --add<enter>" \ "Filtere (Absender-)Domain aus" macro index <esc>Ft "<pipe-message>threadfilter.sh --add<enter>" \ "Filtere Diskussionsfaden (Thread) aus" ---------- schnapp ---------- Die Skripte extrahieren Adresse, Domain bzw. Message-ID und setzen sie (evtl. nach einem manuellen Bearbeitungsschritt) auf die entsprechenden Kill-Listen. Vielleicht gibt es auch bei KMail die Möglichkeit die aktuelle oder alle markierte Emails durch eine Pipe zu schicken. Die Anpassung meiner Procmail-Filter kann dann ein Cronjob, ein Makefile, o.ä. ganz nach persönlichem Gusto erledigen.

Zusammen mit einer gewissen Portion Gelassenheit sollte sich die Liste dann trotz etwas Handarbeit recht gut genießen lassen.

Klar. Trotzdem ist mir eine breiter einsetzbare, sprich MUA-unabhängige Lösung lieber. Äußerst strapaziert wird meine Gelassenheit nämlich dann, wenn ich bei mehrtägigen Threads, die ich einmal als unnötig eingestuft habe, an Folgetagen immer noch Reste (Subthreads) entfernen darf. Damit will ich mich einfach nicht mehr beschäftigen müssen; das soll gefälligst die Technik machen!

Gruß, Ant"tief durchatmen, ESC d"je

Mach ich :-) Mathias -- Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich. Grundgesetz, Artikel 10, Abs. 1 Infos rund um Email-Verschlüsselung --> www.gnupp.de Mein OpenPGP-Schlüssel 0x3B458473 --> blackhole.pca.dfn.de

Am Sonntag, 16. November 2003 22:51 schrieb Thomas Preissler:

Hallo Mathias,

* Mathias schrieb am 16.11.2003: [killauthor-Feature]

...

Am 31. Oktober 2003 habe ich unter dem Betreff "Vier Emailfilter mit procmail" einige alternative Lösungen vorgestellt, die ich nach langer Entwicklung für ausgereift halte. (Klar, das muss natürlich jeder für sich beurteilen.) Darunter neben einem Absenderfilter auch einen Threadfilter, der auf Basis von Message-IDs funkioniert.

Hört sich gut an. Hab auch schon diejenige Mail gefunden - werds mir gleich reinziehen. Feedback kriegst Du bestimmt!

Äh..... Ich will Euch ja nicht zu nahe Treten... Aber wollt Ihr wirklich auf mein sinnloses "Gsalbader" Verzichten??? <<<=== KasperL ...oder Schrat mein name ......Waldschrat! SCNR Thilo -- http://www.chef-de-cuisine.de http://www.gasthof-linde.de

Michael Schulz schrieb:

Thilo Alfred Bätzig schrieb am 16.11.2003 um 23:33:30 +0100:

Hallo Thilo,

...

Am Sonntag, 16. November 2003 22:51 schrieb Thomas Preissler:

...

Hallo Mathias,

* Mathias schrieb am 16.11.2003: [killauthor-Feature]

...

Am 31. Oktober 2003 habe ich unter dem Betreff "Vier Emailfilter mit procmail" einige alternative Lösungen vorgestellt, die ich nach langer Entwicklung für ausgereift halte. (Klar, das muss natürlich jeder für sich beurteilen.) Darunter neben einem Absenderfilter auch einen Threadfilter, der auf Basis von Message-IDs funkioniert.

Hört sich gut an. Hab auch schon diejenige Mail gefunden - werds mir gleich reinziehen. Feedback kriegst Du bestimmt!

Äh..... Ich will Euch ja nicht zu nahe Treten... Aber wollt Ihr wirklich auf mein sinnloses "Gsalbader" Verzichten??? <<<=== KasperL

...oder Schrat mein name ......Waldschrat!

deshalb sollst Du ja auch gefaelligst nach -talk? Also wirds bald.

Michael

Ich überlege gerade, ob ich die Liste wieder abbestelle. Ich komme nach Hause und habe annähernd 180E-Mails alleine in diesem Postfach. 90% davon tragen den Betreff Kasperfilter. Also halte ich erst mal ganz lange die Entf-Taste gedrückt und nehme in Kauf, auch E-Mails zu löschen, die interessant gewesen wären.... Grüße. Christian P.S. Jetzt kommt wahrscheinl. "Sorry für den Spam in den Sorry für den Spam E-Mails...

Christian Schramm am Montag, 17. November 2003 20:39:

Ich überlege gerade, ob ich die Liste wieder abbestelle. Ich komme nach Hause und habe annähernd 180E-Mails alleine in diesem Postfach. 90% davon tragen den Betreff Kasperfilter. Also halte ich erst mal ganz lange die Entf-Taste gedrückt und nehme in Kauf, auch E-Mails zu löschen, die interessant gewesen wären.... Grüße. Christian

P.S. Jetzt kommt wahrscheinl. "Sorry für den Spam in den Sorry für den Spam E-Mails...

Oh, du kriegst diese Liste schon vorgefiltert? Wo ist der Rest der Nicht-Kasperfilter-Mails? *SCNR* ;-) -- Gruß MaxX 8-)

Am Dienstag, 18. November 2003 09:57 schrieb Ralf Corsepius:

On Tue, 2003-11-18 at 01:30, Matthias Houdek wrote:

...

Oh, du kriegst diese Liste schon vorgefiltert? Wo ist der Rest der Nicht-Kasperfilter-Mails?

Gibt's solche auf dieser Liste noch? Ich dachte schon vor 2 Jahren, das Niveau ließe sich nicht mehr weiter senken, doch offensichtlich geht es tatsächlich auch unterirdisch noch weiter ...

Für das nierdrige Niveau gibt es gründe ... ja. Damals gab es auch noch keinen ms oder niwit hehe. dabei könnte man ja auch sinnvolle sachen schreiben, gut Fragen fallen mir im moment genug ein, nur weis ich nicht wie ich die sinnvoll formulieren soll, deshalb suche ich weiter bis ich eine Lösung gefunden habe und stell dann zur passenden Lösungsfindung eine Sinnvolle Frage .........?!?!?!?!? hehe MfG Thilo -- http://www.chef-de-cuisine.de http://www.gasthof-linde.de

Ralf Corsepius am Dienstag, 18. November 2003 09:57:

On Tue, 2003-11-18 at 01:30, Matthias Houdek wrote:

...

Oh, du kriegst diese Liste schon vorgefiltert? Wo ist der Rest der Nicht-Kasperfilter-Mails?

Gibt's solche auf dieser Liste noch? Ich dachte schon vor 2 Jahren, das Niveau ließe sich nicht mehr weiter senken, doch offensichtlich geht es tatsächlich auch unterirdisch noch weiter ...

Sag mal, bist du blind? Mal abgesehen vo so ein paar Querschlägern (von denen MS ja fast noch amüsant war *g*) hat sich IMHO das Niveau der Liste sogar wieder gebessert. Außerdem ist so ein kleiner Thread zum Umgang hier auf der Liste (wozu sicherlich auch praktische Ratschläge wie der Kasperfilter gehören ;-) immer mal wieder angebracht. Im Ergebnis solcher "Säuberungsaktionen" ist meist ein Qualitätsschrittchen auf der Liste spürbar. -- Gruß MaxX 8-)

Ralf Corsepius am Dienstag, 18. November 2003 14:51:

On Tue, 2003-11-18 at 12:46, Matthias Houdek wrote:

...

Ralf Corsepius am Dienstag, 18. November 2003 09:57:

...

On Tue, 2003-11-18 at 01:30, Matthias Houdek wrote:

...

Oh, du kriegst diese Liste schon vorgefiltert? Wo ist der Rest der Nicht-Kasperfilter-Mails?

Gibt's solche auf dieser Liste noch? Ich dachte schon vor 2 Jahren, das Niveau ließe sich nicht mehr weiter senken, doch offensichtlich geht es tatsächlich auch unterirdisch noch weiter ...

Sag mal, bist du blind?

Mal abgesehen vo so ein paar Querschlägern (von denen MS ja fast noch amüsant war *g*) hat sich IMHO das Niveau der Liste sogar wieder gebessert.

Wirklich? Ohne die Postings der letzten Zeit hier gezählt zu haben, würde ich auf ca. 50-60% Kasperletheater/Kindergarten schätzen.

Die letzten 14 Tage (ab 5.11.2003): 2290 Mails insgesamt, davon 36 Mails "Kasperfilter" 37 Mails "Sorry für den SPAM" Das sind zusammen noch nicht einmal 4 % der Mails der letzten 2 Wochen. Und selbst bezogen auf die letzten 4 Tage (so lange läuft dieser Thread) sind es nur 36 + 37 = 73 Kasperfilter/SorryFürSpam-Mails aus insgesamt 599 Mails (es mögen auch ein paar Gesamtmails mehr sein, einige fallen ja schon vorher raus *g*). Das sind auch noch lange keine 50-60%.

<sarkasmus> Doch in Gewissen Sinne hat sich der Lesewert der Liste tatsächlich wieder erhöht: Statt dröger Technik und Etikettenthreads gibt's nun amüsante Threads von und mit nördlichen Waldzwergen, Novell'en und EUROs, Leuten, die verzweifelt "nach irgendwelchen Knöpfen" oder "ein Programm wie .." suchen, oder auf die arme, käufliche Susi einprügeln wollen ... </sarkasmus>

Den kannst du dir sparen. -- Gruß MaxX 8-)

Ralf Corsepius am Dienstag, 18. November 2003 17:28:

On Tue, 2003-11-18 at 16:19, Matthias Houdek wrote:

...

Ralf Corsepius am Dienstag, 18. November 2003 14:51:

...

On Tue, 2003-11-18 at 12:46, Matthias Houdek wrote:

...

Ralf Corsepius am Dienstag, 18. November 2003 09:57:

...

On Tue, 2003-11-18 at 01:30, Matthias Houdek wrote:

...

Oh, du kriegst diese Liste schon vorgefiltert? Wo ist der Rest der Nicht-Kasperfilter-Mails?

Gibt's solche auf dieser Liste noch? Ich dachte schon vor 2 Jahren, das Niveau ließe sich nicht mehr weiter senken, doch offensichtlich geht es tatsächlich auch unterirdisch noch weiter ...

Sag mal, bist du blind?

Mal abgesehen vo so ein paar Querschlägern (von denen MS ja fast noch amüsant war *g*) hat sich IMHO das Niveau der Liste sogar wieder gebessert.

Wirklich? Ohne die Postings der letzten Zeit hier gezählt zu haben, würde ich auf ca. 50-60% Kasperletheater/Kindergarten schätzen.

Das sind zusammen noch nicht einmal 4 % der Mails der letzten 2 Wochen.

Liess nochmal, was ich geschrieben hatte. Ich sprach von Kasperletheater und Kindergartenniveau auf der Liste, nicht vom "Kasperlefilter"-Thread.

Interessant, was du dann alles so als Kasperletheater einstufst. Und nicht, das du glaubst, irgend jemand könnte dich für arrogant und elitär halten. -- Gruß MaxX 8-)

Hallo, * David Haller <david@dhaller.de> [2003-11-17 05:11] schrieb:

Der Vollstaendigkeit halber (und v.a. auf langsameren Rechnern u.U. durchaus interessant), hier noch meine Version. Mein "Killfile" ist eine einzige procmail-Regel nach folgendem Schema:

Ich habe hier einen P-2 (mit mageren 266 MHz), der aber bei der Abarbeitung der procmail Rezepte und der dort eingebundenen Shellskripte eigentlich nicht stark beansprucht wird. Meine Lösung besteht im wesentlichen auch nur aus einem AWK-Skript, das eine Textdatei mit den Kill-Adressen in *ein* kompaktes Rezept umformt. Zur Vermeidung von Typos ganz sinnvoll, finde ich.

==== ~/.procmail/kill-suse.rc [wird aus .procmail included] ==== :0 H

### Mon Jan 27 23:27:40 CET 2003 ### expires: never * 1^0 ^From:.*marcel-stein@(t-online.de|arcor.de)

### [viel gesnippt]

### Thu Sep 18 23:01:47 2003 ### expires: never * 1^0 ^From:.*(timo|suse)@nitwit.de

### and action ### { :0 H * ^X-Mailinglist:.*suse-linux$ suse-linux-killfiled } ====

Was passiert, wenn zwei procmail Prozesse gleichzeitig in suse-linux-killfiled schreiben wollen? Schreibe im action-Teil lieber ":0 H:", damit die Datei ordentlich ge-locked wird. Das ist natürlich Ansichtssache, da der Dateiinhalt so oder so Müll ist, aber sicher ist sicher. Gruß, Mathias -- Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich. Grundgesetz, Artikel 10, Abs. 1 Infos rund um Email-Verschlüsselung --> www.gnupp.de Mein OpenPGP-Schlüssel 0x3B458473 --> blackhole.pca.dfn.de

Mathias Bauer meinte am 16.11.03 um 21:54:

sich beurteilen.) Darunter neben einem Absenderfilter auch einen Threadfilter, der auf Basis von Message-IDs funkioniert.

Ganze Threads zu filtern kann aber auch erhebliche Nachteile haben: Sehr oft entwickelt sich aus einem Thread, den ein Troll angestoßen hat, noch eine sinnvolle Diskussion. Und meistens wird dann nicht das Subjekt geändert, oder gar ein neuer Thread angefangen. Gruß, Frank -- ** pgp public key available from keyservers **

Hallo, Am Montag, 17. November 2003 11:01 schrieb Frank Streitz:

Mathias Bauer meinte am 16.11.03 um 21:54:

...

sich beurteilen.) Darunter neben einem Absenderfilter auch einen Threadfilter, der auf Basis von Message-IDs funkioniert.

Ganze Threads zu filtern kann aber auch erhebliche Nachteile haben: Sehr oft entwickelt sich aus einem Thread, den ein Troll angestoßen hat, noch eine sinnvolle Diskussion. Und meistens wird dann nicht das Subjekt geändert, oder gar ein neuer Thread angefangen.

Ack. Da fallen mir spontan die Mails von Marcel ein. :-) Gruß Werner -- Werner Scharinger Geschäftsführender Gesellschafter der soft & hard Computerservice GmbH * Am Erlenbach 8 * 94032 Passau Tel. +49 851 33025 * Fax. +49 851 31725 * www.shcs.de Fördermitglied der Wirtschaftsjunioren Passau Mitglied der Strategiekommission der Wirtschaftsjunioren Deutschland c/o IHK für Niederbayern in Passau * Nibelungenstr. 15 * 94032 Passau

* Am Mon, 17 Nov 2003 schrieb Frank Streitz:

Mathias Bauer meinte am 16.11.03 um 21:54:

...

sich beurteilen.) Darunter neben einem Absenderfilter auch einen Threadfilter, der auf Basis von Message-IDs funkioniert.

Ganze Threads zu filtern kann aber auch erhebliche Nachteile haben: Sehr oft entwickelt sich aus einem Thread, den ein Troll angestoßen hat, noch eine sinnvolle Diskussion. Und meistens wird dann nicht das Subjekt geändert, oder gar ein neuer Thread angefangen.

Also ich habe mit einem Threadfilter sehr gute Erfahrungen gemacht, der ist bei mir so organisiert, das Mails bestimmter Personen direkt nach /dev/null umgeleitet werden, die MSG-ID wird aber weggeschrieben, Mails die auf diese Mail antworten, werden dann in eine separate Box abgespeichert - die schaue ich mir dann in Fällen akuter Langeweile evtl. mal an :-) Das macht die Liste lesbarer, mir fehlt nämlich schlichtweg die Zeit, allen Trash zu lesen. Gruß Christoph -- Christoph Maurer - Tux#194235 - christoph-maurer at gmx.de

* Am Die, 18 Nov 2003 schrieb Mathias Bauer:

* Christoph Maurer <christoph-maurer@gmx.de> [2003-11-18 08:04] schrieb:

...

* Am Mon, 17 Nov 2003 schrieb Frank Streitz:

...

[Erfahrungen mit Threadfiltern]

Also ich habe mit einem Threadfilter sehr gute Erfahrungen gemacht, der ist bei mir so organisiert, das Mails bestimmter Personen direkt nach /dev/null umgeleitet werden, die MSG-ID wird aber weggeschrieben, Mails die auf diese Mail antworten, werden dann in eine separate Box abgespeichert - die schaue ich mir dann in Fällen akuter Langeweile evtl. mal an :-)

So ähnlich funktioniert mein Threadfilter auch (siehe andere Email (Repost)). Nur werden Emails von diesen bestimmten Personen nicht in die Tonne gekloppt, sondern des Zusammenhangs wegen mit ausgefiltert.

Wie schaut deine Realisierung aus? procmail? Extra Paket? Input! Input! (Es ist ja nicht so, dass bei meinem Filter nichts zu verbessern wäre :-)

Procmail, da sowieso für diverse Dinge eingesetzt... \ Maskiert den Zeilenumbruch... außerdem lasse ich PMs auch von geplonkten Personen durch... :0 * ^X-Mailinglist: suse- * ? $FORMAIL -x"From" -x"From:" -x"Sender:" -x"Reply-To:" -x"Return-Path:"\ |/usr/bin/grep -is -f $HOME/.procmail/suseplonk.lst { #Rausfiltern der Message-Id für Follow-Ups :0 f | $FORMAIL -x "Message-id:"|sed -e "s/.*<\([^>]*\)>/\1/" \

...

$HOME/.procmail/plonkthread.lst

:0 /dev/null } :0: * ^X-Mailinglist: suse- * ? $FORMAIL -x"References: " -x "In-Reply-To:"\ |/usr/bin/grep -is -f $HOME/.procmail/plonkthread.lst PLONKSUSE Gruß Christoph -- Christoph Maurer - Tux#194235 - christoph-maurer at gmx.de

Hallo! den Betreff habe ich mal in etwas Seriöseres geändert um damit einer mittlerweile sachlicheren Diskussion Rechnung zu tragen. Außerdem haben sich ja schon einige (künstlich) aufgeregt über den Kasperfilter-Thread! * Jörg Rossdeutscher <ratti@gesindel.de> [2003-11-17 21:49] schrieb:

* Am So, den 16.11.2003 schrieb Mathias Bauer um 21:54:

Und oft genug divergieren Diskussionen soweit, daß unter den Betreffs später vernünftige Sachen auftauchen. Zum Beispiel diskutieren wir gerade über gute Kasperfilter in einem verloren geglaubten Thread. :-)

Ich bin auch nur beim Überfliegen der ausgefilterten Emails auf diesen Thread gestoßen :->

[falsch aussortierte Emails]

False positives wären natürlich nicht akzeptabel. Ich sehe aber eigentlich ein größeres Problem: <jammermodus> Bei der wachsenden Anzahl an grottigen MUAs, Webmailern </jammermodus> würde ich eher die Gefahr sehen, daß die Referenzen Schwachsinn enthalten. Hier in der Liste läuft ja kaum ein Thread über mehr als 5 Replies, bis ein Outlook "oder whatever" daherkommt und ihn zerreisst. Mir wird etwas Angst und Bange bei dem Gedanken, _was_ da alles in den Refernezen steht, wenn sie überhaupt existieren. Zweistellige Zahlen oder so. Uh...

... oder das @localhost in des Message-ID. Alles seeehr hilfreich! Leider kann man manche Macken mit procmail nur notdürftig beheben (z.B. Attachments von Outlook).

...

[Hinweis auf Email "Vier Emailfilter mit procmail" vom 31.10.2003] Leider erhielt ich wegen der beiden Megathreads um Boykott-Briefe und den Verkauf von SuSE damals kein Feedback :-(

Ich schätze, die Liste kann ein Repost vertragen.

Repost!

Bitte sehr! Bitte gleich! ... Ich freue mich über jeden Kommentar dazu. Vielleicht nützt es ja dem einen oder anderen. Gleich vorweg: ich verwende fetchmail, procmail und mutt -- mit Sicherheit dürfte einiges auch für KMail und andere MUAs verwendbar sein, die ich aber nicht im Detail kenne. In meinem (SuSE 7.2-)System setze ich nacheinander die folgenden vier Filter ein: (1) Threadfilter (2) Domainfilter (3) Absenderfilter (4) Duplikatfilter Danach werden Mailinglisten aussortiert und mit dem Spambouncer www.spambouncer.org der Müll weggeräumt. (Großer `Sperrmüll' wird gar nicht erst abgeholt: vor dem fetchmail-Aufruf starte ich den mailfilter (mailfilter.sourceforge.net).) Beide Programme kann ich nur empfehlen. Soweit die grobe Beschreibung, nun zu den Details: 1. Threadfilter --------------- Das Ziel besteht im Ausfiltern von zukünftigen Beiträgen eines Diskussionsfadens (Threads), den man aufgrund der bereits eingetroffenen Beiträge als uninteressant bzw. unerwünscht eingestuft hat. Eine Filtrierung basierend auf den Betreffzeilen scheidet aus, weil sie nicht treffsicher genug ist. Selbst wenn man annimmt, dass unterschiedliche Threads mit identischen Betreffzeilen selten sind, kann es vorkommen dass einzelne Subthreads nicht korrekt ausgefiltert werden. Dies geschieht insbesondere dann, wenn die Betreffzeilen Umlaute oder andere Sonderzeichen enthalten -- die Filtrierung scheitert nämlich an dem für die Kodierung dieser Zeichen zuständigen `=?iso-8859-1?q?=...'! Die `Re:'-`Fwd:'-Problematik macht eine Betreffzeilen-Filtrierung nur noch zusätzlich fehleranfällig. Exakter lässt sich mit Hilfe der Message-IDs filtern. Verwendet werden dazu die Kopfzeilen `Message-ID:', `In-Reply-To:' und `References:'. Ich fasse hier mal kurz RFC 2822, Abschnitt 3.6.4 zusammen: Jede Email soll die Kopfzeile `Message-ID:' und -- falls es sich um eine Antwort handelt -- zusätzlich die Kopfzeilen `In-Reply-To:' und `References:' besitzen. Dabei gilt: - `Message-ID:' enthält genau eine ID. - In einer Antwort enthält `In-Reply-To:' die Message-ID jener Eltern-Email, auf die sich die Antwort bezieht. - `References:' enthält das gleichnamige Feld der Eltern-Email, ergänzt um deren Message-ID. Mit den IDs in 'References:' kann man also den Thread rekonstruieren. (Weitere Details im RFC.) Werden also von allen Beiträgen eines uninteressanten bzw. unerwünschten Threads die `Message-ID:'s gespeichert, dann können später ankommende Beiträge aufgrund deren Angaben in `References:' und `In-Reply-To:' zuverlässig ausgefiltert werden. In mutt erledigt das Speichern der Message-IDs folgendes Makro: ---------- in $HOME/.muttrc ---------- macro index <esc>Ft "<pipe-message>threadfilter.sh --add<enter>" \ "Filtere Diskussionsfaden (Thread) aus" -------------------------------------- (Das Skript threadfilter.sh berücksichtigt jede Einstellung von `pipe-split'. D.h. es ist irrelevant, ob die ausgewählten Emails als Ganzes oder jede einzeln durch die Pipe geschickt werden.) Für KMail gibt es sicher auch eine entsprechende Möglichkeit, Emails auszuwählen und durch eine Pipe zu schicken. KMail kenne ich nicht so genau. 2. Der Domainfilter ------------------- Alle Emails, die aus bestimmten Domains kommen, werden ausgefiltert. Der Filtrierung zugrunde liegen die Kopfzeilen `From:', `Sender:' und `X-Sender:'. Die unerwünschten Domains sind in einer normalen Textdatei aufgelistet und ein awk-Skript besorgt die Umwandlung dieser Liste in eine procmail-Regel. 3. Der Absenderfilter --------------------- Ganz analog werden alle Emails ausgefiltert, die von bestimmten Personen kommen. Der Filter verwendet die gleichen Kopfzeilen wie der Domainfilter. Die Absender(adressen!), die in einer Textdatei enthalten sind, werden ebenfalls durch ein awk-Skript umgewandelt. Natürlich gibt es analog zum Threadfilter auch hier mutt-Makros, die die Extraktion von Domains bzw. Absenderadressen aus Emails in die `schwarzen Listen' vornehmen und (nach manueller Nachbearbeitung) die procmail-Regeln automatisch erstellen. Das lass' ich jetzt aber mal als Übung ... :-) 4. Der Duplikatfilter --------------------- Dieser Filter erwischt mehrfache identische Emails, der Vergleich beruht wieder auf den Message-IDs. Den Kern kann man aus `man 5 procmailex' entnehmen; ich habe den Filter nur etwas umgebaut (s.u.). Die Skripte: ---------- in $HOME/.procmailrc ---------- INCLUDERC = ${HOME}/.procmail/filterrc ------------------------------------------ ---------- $HOME/.procmail/filterrc ---------- # $HOME/.procmail/filterrc # Filterquartett für Procmail # # Hinweis: filterrc verwendet folgende *externe* Variablen: # - MAILDIR : Mailverzeichnis # - PMDIR : Procmail-Verzeichnis # - FORMAIL : /usr/bin/formail # Threadfilter FILTERTHREADS = yes THREADFOLDER = ${MAILDIR}/muell MSGIDTHREADCACHE = ${PMDIR}/msgid.thread.cache THREADFILTERSCRIPT = ${PMDIR}/threadfilter.sh # Domainfilter FILTERDOMAINS = yes DOMAINFOLDER = ${MAILDIR}/muell # Absenderfilter FILTERSENDERS = yes SENDERFOLDER = ${MAILDIR}/muell # Duplikatfilter FILTERDUPS = yes DUPFOLDER = ${MAILDIR}/muell MSGIDDUPCACHE = ${PMDIR}/msgid.dup.cache MSGIDDUPSIZE = 64000 ## ## Ende des Konfigurationsabschnitts ## # Interne Variablen NEWLINE=" " # Threadfilter # ============ :0 * FILTERTHREADS ?? yes * ! THREADFOLDER ?? ^^^^ * ! FORMAIL ?? ^^^^ * ! THREADFILTERSCRIPT ?? ^^^^ * ! MSGIDTHREADCACHE ?? ^^^^ { :0 Whc : ${MSGIDTHREADCACHE}.lock | ${THREADFILTERSCRIPT} --filter :0 a { :0 c | ${THREADFILTERSCRIPT} --add :0 fhw | ${FORMAIL} -A "X-Filter: Thread" LOG = " Filter: Thread${NEWLINE}" :0 : ${THREADFOLDER} } # Kriterien für den Beginn uninteressanter bzw. unerwünschter # Threads; d.h. im Prinzip ein Killfile für Autoren *und* von # *ihnen* begonnene Threads. :0 * 1^0 ^(From|(X-|)Sender):[ \t]+.*\<?marcel-stein@arcor\.de\>? * 1^0 ^(From|(X-|)Sender):[ \t]+.*\<?marcel-stein@t-online\.de\>? * 1^0 ^(From|(X-|)Sender):[ \t]+.*\<?suse@nitwit\.de\>? * 1^0 ^(From|(X-|)Sender):[ \t]+.*\<?timo@nitwit\.de\>? { :0 c | ${THREADFILTERSCRIPT} --add :0 fhw | ${FORMAIL} -A "X-Filter: Thread" LOG = " Filter: Thread${NEWLINE}" :0 : ${THREADFOLDER} } } # Domainfilter # ============ # # Regeln nach folgendem Muster: # * 1^0 ^(From|(X-|)Sender):[ \t]+.*@\/.*domain.com\>? :0 * FILTERDOMAINS ?? yes * ! DOMAINFOLDER ?? ^^^^ * ! FORMAIL ?? ^^^^ { INCLUDERC = ${PMDIR}/domainfilter } # Absenderfilter # ============== # # Regeln nach folgendem Muster: # * 1^0 ^(From|(X-|)Sender):[ \t]+\/.*\<?eine\.email@adresse\.de\>? :0 * FILTERSENDERS ?? yes * ! SENDERFOLDER ?? ^^^^ * ! FORMAIL ?? ^^^^ { INCLUDERC = ${PMDIR}/senderfilter } # Duplikatfilter # ============== :0 * FILTERDUPS ?? yes * ! DUPFOLDER ?? ^^^^ * ! FORMAIL ?? ^^^^ * ! MSGIDDUPCACHE ?? ^^^^ * ! MSGIDDUPSIZE ?? ^^^^ { :0 Whc : ${MSGIDDUPCACHE}.lock | ${FORMAIL} -D ${MSGIDDUPSIZE} ${MSGIDDUPCACHE} :0 a { :0 fhw | ${FORMAIL} -A "X-Filter: Duplikat" LOG = " Filter: Duplikat${NEWLINE}" :0 : ${DUPFOLDER} } } # Ende. ---------------------------------------------- ---------- $HOME/.procmail/threadfilter.sh ---------- #! /bin/sh # $HOME/.procmail/threadfilter.sh # Thread-Filter für Procmail # Konfiguration MSGIDCACHE="$HOME/.procmail/msgid.thread.cache" MAXIDCOUNT=2500 # Skript PROGNAME="${0##*/}" test -f "$MSGIDCACHE" || touch "$MSGIDCACHE" test $# -eq 0 && { echo "$PROGNAME: Keine Parameter." exit 1 } case "$1" in -a|--add) lockfile "$MSGIDCACHE".lock && { formail -s formail -czx message-id: >>"$MSGIDCACHE" rm -f "$MSGIDCACHE".lock } ;; -f|--filter) # Exitcode: 0 : Mail gehört zum Thread --> ausfiltern # 1 : Mail in Ordnung TMPFILE="$(mktemp -q /tmp/threadfilter-XXXXXX)" test $? -ne 0 && exit 1 formail -cz -x in-reply-to: -x references: | \ sed 's/</\ </g; s/>/>\ /g;' | \ sed -n '/^<[^[:blank:]]\+@[^[:blank:]]\+>$/p' | \ sort -u >"$TMPFILE" grep -qis -f "$TMPFILE" "$MSGIDCACHE" EXITCODE=$? rm -f "$TMPFILE" test "$EXITCODE" -ne 0 && exit 1 ;; -u|--update) lockfile "$MSGIDCACHE".lock && { COUNT="$(cat "$MSGIDCACHE" | wc -l)" test $COUNT -gt $MAXIDCOUNT && { tail -n $MAXIDCOUNT "$MSGIDCACHE" >"$MSGIDCACHE".new mv "$MSGIDCACHE".new "$MSGIDCACHE" } rm -f "$MSGIDCACHE".lock } ;; *) echo "$PROGNAME: Parameter '$1' unbekannt." exit 1 ;; esac exit 0 # Ende. ----------------------------------------------------- Zur Erzeugung der Domain- und Absenderfilter dienen die beiden folgenden awk-Skripte. Hier sind sie zwar nicht schön, dafür aber wenigstens platzsparend. Das Updaten der Filter kann man ja z.B. mit einem Makefile oder einem Cronjob lösen. ---------- $HOME/.procmail/domainfilter.awk ---------- # $HOME/.procmail/domainfilter.awk # Erstellt den Domainfilter für Procmail BEGIN { print "# Domainfilter für Procmail"; printf "# Automatisch erstellt am %s\n\n:0\n", strftime(); } END { printf "{\n\t:0 fhw\n\t| ${FORMAIL} -A \"X-Filter: Domain\"\n\n"; printf "\tLOG = \" Filter: Domain (${MATCH})${NEWLINE}\"\n\n"; printf "\t:0 :\n\t${DOMAINFOLDER}\n}\n\n# Ende.\n"; } ! /^(\#.*|[[:blank:]]*)$/ { domain = gensub("\\\.", "\\\\.", "g"); printf "* 1^0 ^(From|(X-|)Sender):"; printf "[ \\t]+.*@\\/.*%s\\>?\n", domain; } # Ende. ------------------------------------------------------ und beinahe analog ---------- $HOME/.procmail/senderfilter.awk ---------- # $HOME/.procmail/senderfilter.awk # Erstellt den Absenderfilter für Procmail BEGIN { print "# Absenderfilter für Procmail"; printf "# Automatisch erstellt am %s\n\n:0\n", strftime(); } END { printf "{\n\t:0 fhw\n\t| ${FORMAIL} -A \"X-Filter: Absender\"\n\n"; printf "\tLOG=\" Filter: Absender (${MATCH})${NEWLINE}\"\n\n"; printf "\t:0 :\n\t${SENDERFOLDER}\n}\n\n# Ende.\n"; } ! /^(\#.*|[[:blank:]]*)$/ { sender = gensub("\\\.", "\\\\.", "g"); printf "* 1^0 ^(From(X-|)|Sender):"; printf "[ \\t]+\\/.*\\<?%s\\>?\n", sender; } # Ende. ------------------------------------------------------ Bin gespannt auf eure Reaktionen, Mathias -- Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich. Grundgesetz, Artikel 10, Abs. 1 Infos rund um Email-Verschlüsselung --> www.gnupp.de Mein OpenPGP-Schlüssel 0x3B458473 --> blackhole.pca.dfn.de

On Thursday 20 November 2003 22:04, Joerg Rossdeutscher wrote:

Und wenn das alles schief läuft, ist der Unfall lediglich ein Fallback auf das Outlook-Behaviour: Der Thread wird falsch gehandelt. Natürlich sollte das nicht so sein. Aber eine Zeitbombe ist es auch nicht.

Ein Cyrus-Mailserver würde Deine Nachricht als doppelt empfangen unterdrücken und nicht mehr zustellen. Kristian -- http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG

Joerg Rossdeutscher schrieb:

Am Do, den 20.11.2003 schrieb Kristian Köhntopp um 22:10:

...

On Thursday 20 November 2003 22:04, Joerg Rossdeutscher wrote:

...

Und wenn das alles schief läuft, ist der Unfall lediglich ein Fallback auf das Outlook-Behaviour: Der Thread wird falsch gehandelt. Natürlich sollte das nicht so sein. Aber eine Zeitbombe ist es auch nicht.

Ein Cyrus-Mailserver würde Deine Nachricht als doppelt empfangen unterdrücken und nicht mehr zustellen.

Könnte ich als gerechte Strafe akzeptieren. Allerdings würde der andere Verursacher ja den gleichen Fehler im MUA haben, also trifft es keinen Unschuldigen.

Wie hoch ist die Wahrscheinlichgkeit, dass so etwas eintrifft? IMHO bewegt sich das schwer in einer Epsilonumgebung um Null. Ich meine, wer nennt sich und seinen Rechner normalerweise schon ratti...? :-) Schoenes Woe, Th.

Moin, Am Fr, den 21.11.2003 schrieb David Haller um 04:35:

Am Thu, 20 Nov 2003, Joerg Rossdeutscher schrieb:

...

Am Mi, den 19.11.2003 schrieb David Haller um 21:34:

...

Message-Id: <1069279039.752.45.camel@ratti.local>

Sie ist zweifellos nicht weltweit eindeutig,

Im Gegenteil. Jeder Hinz und Kunz kann seine Kiste so nennen.

?? Ja, hab ich doch geschrieben: Nicht eindeutig.

...

...

Kannst du mal den (aelteren) patch von mir testen?

Nein, weil ich Debian unstable fahre und keinen Grund mehr habe, evolution selbst zu kompilieren

Die betrifft das doch gar nicht, wenn du dein aktuelles Evo nimmst, den patch reinbuegelst und einfach mal nebenher kompilierst -- du musst das Teil nicht mal installieren AFAIR...

...und das ist leider nicht so. Du brauchst, um Evolution kompilieren zu können, fast die kompletten Gnome-Sourcen auf dem Rechner, und einen guten Teil davon in inoffiziellen Beta-Versionen. Bekanntermaßen ist das Debian-Projekt ja gehackt worden, daher komme ich derzeit sowieso an nix ran, aber das Ding kompilierst du nicht "mal eben". Bei meinen letzten Versuchen habe ich Tage gebraucht, ehe es auch nur durchlief, und inzwischen habe ich ein neues System. Und wenn es dann kompiliert, dann dauert es immer noch etliche Stunden pro Durchlauf. Zudem ist Evolution extrem Versionsabhängig - ein Evolution-Update zieht einen enormen Rattenschwanz an Updates nach sich, weil genau *diese* Beta-Alpha-rc-Version einer Lib braucht, die dann wiederum... Evolution ist riesig. Ein Viech. Ein Monster.

Hey, was meinst du, wie's mir geht???

Ich habe damals fuer kmail (das ich nicht verwendete!) nen patch aus dem Hut gezaubert, dann fuer Evo (das ich erst recht nicht verwendete)... und? Und jetzt ist dieser Scheiss immer noch nicht gefixt, obwohl du ja den Entwicklern geschrieben hast, und nun grab ich den Patch wieder aus und du willst den nichtmal testen???

Weil es leider nicht "mal eben" ist. Dafür gehen mindestens drei komplette Abende drauf, und das Problem ist mir einfach zu marginal dafür.

Und wenn du den Patch testest, dann kann ich den Evo-Entwicklern den Patch auch vor den Latz ballern! Du hast ja selbst die Erfahrung mit diesen "lieben", arroganten, RfC-ignoranten Ar^WMenschen gemacht...

Eben. Der Patch würde ein gewolltes Feature von Evolution ändern. Er wird todsicher rejected - und kaum jemand kompiliert Evolution aufgrund seiner Größe selbst. Wo ist also der Sinn? Mit der Wahrscheinlichkeit eines Lottogewinns könnte eine Mail sich falsch einsortieren oder von einigen Webservern fälschlicherweise als Duplikat wegsortiert werden. Ich halte den Weg für falsch.

Oder ich pack das auf ein extra-SF projekt oder sonstwas... Weiss der Geier.

Wenn aber gerade du, aber auch andere hier, die Evo verwenden, mich hier einfach haengen lasst, dann bin ich einfach nur noch frustriert.

Wenn du das Ding jemals selbstgebacken hast, wirst du nicht von "hängenlassen" sprechen. Ich bin der Erste, der sich eine Alpha von Firebird, Mozilla oder whatever backt. Aber ganz bestimmt nie wieder Evolution. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

Hallo, Am Fri, 21 Nov 2003, Christian Boltz schrieb:

Am Mittwoch, 19. November 2003 21:34 schrieb David Haller:

...

Am Wed, 19 Nov 2003, Joerg Rossdeutscher schrieb:

...

Wie sind deine Erfahrungen mit den IDs? Leider gehört mein MUA zu denen, die keine korrekte schreiben, aber immerhin ist sie alltagstauglich.

Naja, nicht wirklich. Kannst du mal den (aelteren) patch von mir testen? [...] ==== ~/.bashrc ==== export EVOLUTION_MSGID_FQDN="yes" ====

Abschalten geht via EVOLUTION_MSGID_FQDN="no" oder man setzt die Environment-variable einfach nicht.

Du musst allerdings auch einen FQDN haben, zu ueberpruefen mittels der Ausgabe von 'hostname -f'.

Warum nimmst Du nicht gleich den Inhalt der Variablen EVOLUTION_MSGID_FQDN als FQDN, falls die Variable gesetzt ist? Das würde die Sache wesentlich praktischer machen (v. a., da Ratti ja absichtlich ratti.local als internen Hostname hat)

Auch wieder wahr. Naja, das mit der Variablen war ja schon ein "Feature"... Ich habe Evolution nie verwendet, ich verwende es nicht und ich will es nie verwenden, und schon gar nicht will ich die Arbeit fuer dessen Entwickler machen. *HRRRGHHHMMMPPFFFF* Wenn mich Evolution mehr als ein Furz einer Kuh auf einer Wiese am anderen Ende von Deutschland interessieren wuerde, dann koennte ich das sicher locker hinbekommen, die Variable so auszuwerten. ICH WILL ABER NICHT VERDAMMT NOCH MAL!!! Ich will nicht den RfC-ignoranten arroganten Heinis von Evolution nachflicken!!! Der eigentliche Patch spielt aber in den anderen Zeilen, eben dass gethostbyname(gethostname()) aufgerufen wird um den echten Hostnamen zu bestimmen. Diesen kann man ganz normal via /etc/hosts oder DNS definieren. Und das sollte eigentlich auch reichen. Aber naja, wer so RfC-ignorant wie die Evolution-Entwickler ist, der hat sowas ja nicht noetig... Auch wenn ich weiss, wo und wie es geht, freiwillig mache ich das nicht. Das mit der Variablen war ein Gefallen an die Leser und Schreiber dieser Liste gewesen, den ich "ad hoc" eingebaut habe, aus purem Altruismus. Und jetzt kommt auch noch ratti daher, und sagt, es sei ihm zu aufwaendig, mal nebenher Evolution testhalber mit dem patch zu kompilieren... *grrrr* -dnh, und siehe nebenan... Ich will Schmerzensgeld!  -- Schau Dir Evolution an, das ist mittlerweile genauso dämlich wie Outlook. Ein VBS-Interpreter fehlt noch, aber der kommt bestimmt bald. Das dauert nimmer lang. [Adalbert Michelic in suse-linux]

Moin, * Joerg Rossdeutscher <ratti@gesindel.de> [2003-11-19 21:23]:

Zerrissene Threads wieder herzustellen ist ja nicht sinnvoll machbar

Naja, in wichtigen Mailinglisten mache ich das schon. Thorsten -- Just because you do not take an interest in politics doesn't mean politics won't take an interest in you. - Pericles

Hallo, Am Thu, 20 Nov 2003, Mathias Bauer schrieb:

Das =?iso-8859-1?q?= etc. habe ich nie genauer analysiert. Meist steht danach irgend ein Umlaut und manchmal heißt es statt -1 eben -15 etc.

Das ist eine Kodierung lt. RfC 1342, 1522, 2047. In Header duerfen _generell_ keine non-7-bit-ascii Zeichen auftreten, denn im Header ist das charset noch unbekannt, das wird ja dort erst im Content-Type-Header deklariert. Was macht man also? Man gibt das charset "inline" bei der Kodierung an. Die Form ist: encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" Dabei duerfen im encoded-text _KEINE_ "?", Leerzeichen, Tabs oder Zeilenumbrueche stehen, diese sind lt. RfC in QP (Quoted Printable) als _ oder =20 zu mitzukodieren. Wird encoded-text mit Base64 kodiert, dann werden Leerzeichen automatisch mitkodiert. encoding kann Q oder B sein, fuer Quoted Printable oder Base64. Und: ==== RfC 2047 (3.) ==== The 'charset' portion of an 'encoded-word' specifies the character set associated with the unencoded text. A 'charset' can be any of the character set names allowed in an MIME "charset" parameter of a "text/plain" body part, or any character set name registered with IANA for use with the MIME text/plain content-type. ==== Es duerfen auch mehrerere, unterschiedlich kodierte Teile auftreten: ==== Re: Dateien nach Zeit =?iso-8859-15?B?bPZz?= =?iso-8859-15?Q?chen?= ==== Hierbei ist (wie immer) Whitespace am Zeilenende sowie am Zeilenanfang eines fortgesetzten Headers zu ignorieren. Ebenso zu ignorieren ist "whitespace" zwischen "ecoded-words": ==== RfC 2047 (6.2) ==== When displaying a particular header field that contains multiple 'encoded-word's, any 'linear-white-space' that separates a pair of adjacent 'encoded-word's is ignored. (This is to allow the use of multiple 'encoded-word's to represent long strings of unencoded text, without having to separate 'encoded-word's where spaces occur in the unencoded text.) ==== Leider gibt es viele MUAs, die das falsch machen, speziell im Zusammenhang mit fortgesetzten Headern fuegen diese dann gerne Whitespace innerhalb von encoded-words ein, oder verstuemmeln (v.a. Subjects), was dann zu so netten Sachen wie Subject: Re: Dateien nach Zeit =?iso-8859-15?B?PT9J?= =?iso-8859-15?Q?SO-8859-1=3FQ=3Fl=3DF6s?= l=F6schen?= fuehrt. Das dekodiert zu: Subject: Re: Dateien nach Zeit =?I SO-8859-1?Q?l=F6s l=F6schen?= Was, wenn man die falsche Fortsetzung und das falsche Leerzeichen korrigiert zu Subject: Re: Dateien nach Zeit =?ISO-8859-1?Q?l=F6s_l=F6schen?= wird, was wiederum zu Subject: Re: Dateien nach Zeit lös löschen dekodiert. Irgendein (tod)kranker MUA hat da also Mist gebaut.

Ich habe mir schon mal überlegt, ob man da mit recode was machen kann, oder ob man es gar mit sed das einfach wegoperiert, aber dann kommt sicher eine Email mit ganz exotischer (oder nicht konformer) Kodierung, welche man garantiert nicht berücksichtigt hat.

Ja, das geht mit recode, allerdings muss man vorher das encoding und das charset ausfiltern und die =????= wegmachen. Z.B.: ==== for x in $header # wortweise betrachten, s.o. do if echo "$x" grep -q '^=?' then charset="`echo \"$x\" | sed 's/.*=?\([^?]\+\)?.*/\1/'`" charset="`echo \"$charset\" | tr '[:lower:]' '[:upper:]'`" encoding="`echo \"$x\" | sed 's/.*=?[^?]\+?\([qQbB]\)?.*/\1/'`" encword="`echo \"$x\" | sed \ 's/.*=?[^?]\+?[qQbB]?\([^?]\+\)?=.*/\1/'`" case "$encoding" in q | Q) x="`echo \"$encword\" | sed 's/_/=20/g' | recode /QP..$charset`" ;; b | B) x="`echo \"$encword\" | recode /B64..$charset`" ;; esac fi echo -n " $x" done ==== "Defekte" wie oben angedeutet werden hier natuerlich nicht beruecksichtigt. In Perl laesst sich das etwas eleganter loesen, da kann man sogar manche Defekte reparieren. Bei Interesse kann ich meine Perl-Scriptfragmente mal ueberarbeiten (und moeglichst so, dass es sich mit perlcc (5.8.0) kompilieren laesst). -dnh -- - Macs sind für die, die nicht wissen wollen, warum Ihr Rechner funzt. - Linux ist für die, die wissen wollen, warum er funzt. - DOS ist für die, die wissen wollen, warum er nicht funzt, und - Windows ist für die, die nicht wissen wollen, warum er nicht funzt.

Hallo, Am Fri, 21 Nov 2003, Mathias Bauer schrieb:

* David Haller <david@dhaller.de> [2003-11-20 13:50] schrieb:

...

Am Thu, 20 Nov 2003, Mathias Bauer schrieb:

...

Das =?iso-8859-1?q?= etc. habe ich nie genauer analysiert. Meist steht danach irgend ein Umlaut und manchmal heißt es statt -1 eben -15 etc.

Das ist eine Kodierung lt. RfC 1342, 1522, 2047.

[... viel interessantes gekürzt ...]

...

Ja, das geht mit recode, allerdings muss man vorher das encoding und das charset ausfiltern und die =????= wegmachen. Z.B.:

==== for x in $header # wortweise betrachten, s.o. do if echo "$x" grep -q '^=?'

Müsste es -- nur so auf die Schnelle -- nicht heißen: if echo "$x" | grep -q '^=?'

Ja! [snippetry]

...

In Perl laesst sich das etwas eleganter loesen, da kann man sogar manche Defekte reparieren. Bei Interesse kann ich meine Perl-Scriptfragmente mal ueberarbeiten (und moeglichst so, dass es sich mit perlcc (5.8.0) kompilieren laesst).

Hey danke für die Infos! Allein bis ich die passenden RFCs rausgesucht habe... Leider bin ich von Ideen noch nicht zu Fragmenten gekommen :-( Ich werde wohl zuerst mal Perl lernen, was ich mir eh schon lange vorgenommen habe und danach sicher noch einige kalte Wintertage brauchen, bis was brauchbares heraus kommt.

Ok, ich versuch dann mal die Fragmente zu was einzeln tauglichem zusammenzufuegen.

Außerdem finde ich es problematisch, wenn zur Gesamtverarbeitung (incl. Filter) einer Email 100000 mal awk, formail, grep, sed etc. verwendet wird. Ich bin ja kein Freund von monolithischen Gesamtlösungen aber irgendwann scheint mir das nicht mehr besonders praktikabel. Obwohl es natürlich schon funktioniert! Wie denkt ihr darüber?

Also, bei mir bremst bisher eigentlich nur spamassassin, den ich dementsprechend weit hinten in der Filterkette habe. Davor sind viele normale procmail-Regeln, aber auch eine, die fuer alles, was bis dahin durchkommt ein gawk-script + antivir aufruft. Das ist aber immernoch viel schneller als SA... Im Moment habe ich hier also folgende Filter: ==== ## filter for base64-encoded MZ-exe-files :0 B: * ^TV[qpro][iw5QJB]AAMAAAAEAAAA exe-files # suse-linux "killfile" INCLUDERC=/home/dh/.procmail/kill-suse.rc # general sorting / whitelist INCLUDERC=/home/dh/.procmail/sort.rc :0 fw | /home/dh/bin/avcheck-mail :0 H * ^X-AVCheck-Mail: virii-new # noch zwei spezifische Filter (einer fuer die ct-register-Mails, der # den Anhang extrahiert und direkt ins Register einpflegt) # spamassassin :0 fw | /usr/local/bin/spamassassin :0 H * ^X-Spam-Level:.*\*\*\*\*\*\* spammed-sure :0 H * ^X-Spam-Level:.*\*\*\*\* spammed-probable :0 inbox ==== /home/dh/bin/avcheck-mail ist dabei ein gawk-Wrapper um antivir, den ich hier IIRC sogar schonmal gemailt habe... Im Vergleich zu SA ist der uebrigens _sehr_ performant...

Äh noch was ... könntest Du mir evtl. Deine Skriptfragmente zum Austoben überlassen???

Klar, s.o. Im Moment sind die aber "so" untauglich ;)

Evtl. über einen Link auf der HP. Wenn man schon mal ne Ausgangsbasis für ein interessantes Problem hat, ist's ja leichter als sich anhand diverser Hello-World-Progrämmchen zu motivieren.

Mach ich. -dnh -- Qual Qual oh Qual wo bist Du oh Qual oh Qual -- B. Brodesser in suse-talk

* Am Mit, 19 Nov 2003 schrieb Joerg Rossdeutscher:

...

Exakter lässt sich mit Hilfe der Message-IDs filtern. Verwendet

Wie sind deine Erfahrungen mit den IDs? Leider gehört mein MUA zu denen, die keine korrekte schreiben, aber immerhin ist sie alltagstauglich. Kann man das für alle MUAs sagen?

Zumindest gelingt es mir mit Hilfe einer MSG-ID-Filterung zuverlässig Folgenachrichten auf bestimmte Personen auszublenden. Bis her kann ich weder false positives noch Nichterkennung bemerken. Ich betrachte allerdings sowohl In-Reply-To als auch References im Header. Gruß Christoph -- Christoph Maurer - Tux#194235 - christoph-maurer at gmx.de

Moin, Am Mo, den 17.11.2003 schrieb Jens Hofheinz um 17:22:

Am Sonntag, 16. November 2003 19:10 schrieb Joerg Rossdeutscher:

...

Weiter mit einem Ausschnitt aus meiner ~/.procmailrc: ^^^^^^^^^^ PLONK=/home/ratti/.plonk

:0:

* ? (formail -x From: -x Sender: -x Reply-To: -x Received: | fgrep -iqf $PLONK) /home/ratti/plonk

Mich würde der komplette Inhalt interessieren. Oder läuft das auch mit diesen 2 Zeilen?

Das sollte eigentlich alles sein. Ich habe jedenfalls nicht mehr drin. Eventuell könnte es nötig sein, den Pfad zu erweitern, sodaß formail und fgrep auch definitiv "greifbar" sind - oder, wenn du sicher gehen willst, machst du einfach ein "which formail" und trägst es oben mit dem kompletten Pfad ein.

...

(Achtung, /var/spool/mail/ratti darf nicht in Benutzung sein)

Kannst Du das kurz näher erklären?

Ja. Wie gesagt, gelegentlich lese ich "im Block" alles, was gefiltert wurde, sprich: Ich lese alle meine Mails, und dann hole ich mir explizit nur die gefilterten Artikel rein. Was dann in meinem Mailclient als "ungelesen" neu auftaucht ist also Nervkram. Es gibt viele Möglichkeiten, die mbox-Datei vom Server in den lokalen MUA zu bringen, und es hängt natürlich von deiner lokalen Installation ab, wie und wo du ansetzen kannst. Ich habe einen lokalen Server und sitze an meinem Client-Rechner. Ich hole meine Post per POP3, sprich: Auf dem Server wird /var/spool/mail/ratti ausgelesen. Der gefilterte Kram liegt aber in /home/ratti/plonk. Es sind aber beides Standard-mbox-Dateien, also brauche ich nur den Inhalt von /home/ratti/plonk nach /var/spool/mail/ratti verschieben. Es ginge also eigentlich: mv /home/ratti/plonk /var/spool/mail/ratti Damit würde ich die Datei aber ganz ersetzen - wohlmöglich sind aber noch Mails drin, die durch einen Fehler nicht abgeholt wurden, oder man benutzt einen MUA wie Apples mail.app, der Post erst nach einer Woche löscht, und: Ich will die Datei nicht überschreiben, weil ich dann gucken muß, ob die Rechte noch stimmen. Deswegen ist es schlauer, den Inhalt einfach hinten dranzuhängen, dann geht nix schief: cat /home/ratti/plonk >> /var/spool/mail/ratti ...und dann die plonk-Datei leeren. Entweder rm /home/ratti/plonk oder, was ich sehr gerne tue:

/home/ratti/plonk

Das ">" ist hier "echt" und kein Quoting. Auf hochdeutsch: Leite "nichts" um in diese Datei. Dadurch wird die Datei geleert. Prima für z.B. überquellende Logfiles, die man nicht löschen darf, solange der zugehörige daemon noch aktiv ist. So geht's. Das Problem ist nur: Wenn im gleichen Augenblick fetchmail Post abholt, dann würde zwei Prozesse gleichzeitig Daten in das Postfach schreiben, und zwar vermutlich durcheinander. Deswegen mache ich das nur, wenn ich weiss, daß der Rechner offline ist. Natürlich könnte immer noch was querschiessen, cronjobs zum Beispiel, aber auf meinem ein-einziger-Client-Server ist das eine akzeptable Lösung. Anonsten könnte man die Nachrichten auch anders anschieben, z.B. mit formail. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

Moin, * David Haller <david@dhaller.de> [2003-11-17 23:24]:

==== resort-plonked.sh [UNGETESTET!] ==== MBOX="/home/ratti/plonk" LOCKFILE="/home/ratti/plonk.lock"

trap "release_lock; exit 2;" 1 2 3 4 6 7 8 10 11 12 13 14 15 17

acquire_lock() { test -e "$LOCKFILE" && exit 37 echo $$ > "$LOCKFILE" }

release_lock() { if test -r "$LOCKFILE" && test `cat "$LOCKFILE"` -eq $$ then rm -f "$LOCKFILE" else exit 1 fi }

acquire_lock

if cp "$MBOX" "${MBOX}.work" then

...

"$MBOX" else release_lock test -f "${MBOX}.work" && rm -f "${MBOX}.work" exit 1 fi

release_lock

if cat "${MBOX}.work" | procmail then rm -f "${MBOX}.work" fi ====

==== ~/.procmailrc ==== :0 H * ^X-Plonked-Seen: ratti@localhost inbox

:0 H: /home/ratti/plonk.lock * ? (formail -x From: -x Sender: -x Reply-To: -x Received: | fgrep -iqf $PLONK) { :0 fw | formail -i "X-Plonked-Seen: ratti@localhost"

:0 /home/ratti/plonk } ====

Ok, um an die Diskussion anzuknüpfen, die Du leider nicht fortgesetzt hast: Warum nochmal benutzen alle Procmail? Das ist eine Art Quiz, oder? Wer die unleserlichtste Regel erstellt, bekommt einen Preis? Thorsten -- Don't let your sense of morals prevent you from doing what is right. - Isaac Asimov

Moin, * David Haller <david@dhaller.de> [2003-11-18 01:30]:

PS: Die (gesnippten) procmail-Regeln sind nicht unleserlich -- fuer dich aber wohl ungewohnt.

Ich habe den Kram über ein Jahr benutzt. Es geht einfach darum, daß man durch viele Reifen springen muß, um zu bekommen, was man haben will. Falls sie unleserlich wären, dann nur weil ich die Syntax inzwischen aus dem Hirn geswapt hätte. Das passiert bei Maildrop nicht so leicht, weil man die Syntax an vielen Orten wiedererkennt, gerade für Newbies ein nicht zu unterschätzender Vorteil.

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.

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.

ich verwende halt procmail, weil das alles kann was ich brauche

Stell Dir, vor, ich verwende einen MDA, der alles kann, was ich brauche, den ich aber trotzdem niemals weiterempfehlen würde. Ich kann nämlich durchaus auch Dinge beurteilen, die ich gut kenne. Ich habe mal gelesen, daß dicke Bücher bei Amazon oä. im Allgemeinen bessere Beurteilungen bekommen, weil sich die Rezensenten nicht eingestehen wollen, daß sie 1000 Seiten lang ihre Zeit verplempert haben.

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

Ich kann verstehen, dass du das "reflexartige" "procmail" nicht mehr sehen kannst[1].

Ich kann aber dein "pauschales" "igitt" bzgl. procmail auch nicht leiden, deshalb bringe ich auch immer wieder Argumente fuer procmail.

Pauschal ist es nur in Bezug auf Newbies. Ich habe schon des öfteren gesagt, daß man es tatsächlich benutzen kann, wenn man es denn lange genug studiert hat. Für Newbies wirkt Procmail aber so abschreckend, daß sie vermutlich lieber ganz auf einen MDA verzichten als sich das anzutun. Das ist etwa so, als würde man Anfängern ed(1) statt $EDITOR empfehlen, weil man damit ja alles machen kann, weil man den ja gut kennen würde, weil der ja nach $ÜBLE_VERRENKUNG auch in der einen oder anderen Funktion fast so einfach zu benutzen wäre wie andere Editoren. Mag ja alles stimmen, deutet aber darauf hin, daß man ein eingeschränktes Bild von ed(1) und vor allem von ed(1) im Vergleich zu anderen Editoren hat. Ebenso kann man sicherlich gute Programme in Brainfuck schreiben, es drängt sich aber die Frage auf, ob das die richtige Sprache für Anfänger ist, die keine besondere Vorliebe dafür an den Tag legen, grundlos Qualen zu erleiden. 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...)

Und wo wir schonmal dabei sind: ___ _____ __ __ _____ ___ __ __ ___ ___ ___ ___ _ _ _ | __|_ _\ \/ / \ \ / / __| _ \ | \/ / __|/ __|__|_ _| \| | | | | _| | | > < \ V /| _|| / | |\/| \__ \ (_ |___| || |) |_|_|_| |_| |___/_/\_\ |_| |___|_|_\ |_| |_|___/\___| |___|___/(_|_|_) _ _ _____ ___ _ _ | \| |/ _ \ \ / / | | | | .` | (_) \ \/\/ /|_|_|_| |_|\_|\___/ \_/\_/ (_|_|_)

(ja, ueber ungueltige Msg-Ids kann ich mich wesentlich mehr echauffieren als ueber mail-filter...)

Ok, wie wär's mit einem Tausch: Ich fixe meinen Msg-ID und Du rätst in Zukunft den armen Newbies zu Maildrop? (Schicke Schrift, alles handgemacht?) Ansonsten bin ich sicher, eine ähnliche Kurzsichtigkeit bzgl. Msg-IDs an den Tag legen zu können wie alle beteiligten Anwesenden bzgl. Procmail. Das ist leicht, ich muß nur starrsinnig an dem festhalten, was im Moment mein Weltbild ausmacht und alles andere da irgendwie einsortieren. :O h:, ich schmeiß mich weg. Wenn es das mit dem Quiz nicht ist, ist es dann so ein Pyramidenschema? Bekommt man eine Prämie, wenn man einen weiteren Newbie in sein Unglück lockt?

[1] bei mir ist das uebrigens nicht der Fall -- da ich aber procmail verwende, schreibe ich eben ein procmail-Rezept als Anhaltspunkt fuer etwas, und erfinde nicht irgendwas in Mail::Audit Syntax oder sonstwas, das ich selbst nicht praktisch nachvollziehen kann...

Und bitte vergiß endlich Mail::Audit. Es würde helfen, meine Mails zu lesen, um 'rauszukriegen, was ich davon halte. (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.) Thorsten -- Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich. - Grundgesetz, Artikel 10, Abs. 1

Moin, * Florian Gross <florian@grossing.de> [2003-11-18 11:00]:

Geht viel einfacher: figlet

| _ \ __ _ ___ | | _| | __ _ _ __ _ __ | |_| | | | | |/ _` / __| | |/ / |/ _` | '_ \| '_ \| __| | | |_| | (_| \__ \ | <| | (_| | |_) | |_) | |_|_| |____/ \__,_|___/ |_|\_\_|\__,_| .__/| .__/ \__(_) |_| |_| Mein NEdit kann jetzt auch Figlets, danke! Thorsten -- Don't let your sense of morals prevent you from doing what is right. - Isaac Asimov

Moin, * David Haller <david@dhaller.de> [2003-11-20 02:18]:

Am Tue, 18 Nov 2003, Thorsten Haude schrieb:

...

* David Haller <david@dhaller.de> [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

Moin, * Christian Boltz <cb.suse@wein-vin-vinum.net> [2003-11-23 00:44]:

Am Samstag, 22. November 2003 13:05 schrieb Thorsten Haude:

...

* David Haller <david@dhaller.de> [2003-11-20 02:18]:

...

Am Tue, 18 Nov 2003, Thorsten Haude schrieb:

...

* David Haller <david@dhaller.de> [2003-11-18 01:30]: Im Prinzip fehlt procmail ein Substitutionsmechanismus, der sowas wie

* ^Foo: (`perl -e '@_=<>;chomp(@_);print join("|",@_), "\n";' < FILE`)

machen wuerde, wuerde procmail das `` ausfuehren.

Die Zeile bastelt eine RegEx zusammen, die auf den Inhalt des Headers "Foo:" prüft. Zuerst wird FILE in perl eingelesen, die Zeilenumbrüche entfernt (chomp) und dann das Ganze mit "|" verkettet, also ein "OR" für die RegEx. Die Klammern außenrum stehen ja schon in der Procmail-Regel ;-) Es entsteht also (nach Ausführung der Backticks) eine Zeile ähnlich der folgenden: * ^Foo (zeile1|zeile2|zeile3|zeile4)

Ok, jetzt verstehe ich es auch. Danke!

...

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.

Auch KMail kann kompliziertere Filteraktionen ;-) Ich lasse mir hier z. B. CVS commit-Mails durch ein Script pipen, dass die diffs einfärbt (durch Umwandlung in eine HTML-Mail).

Diffs färbt mein Edit ein, nicht mein Mailprogramm.

Gegenfrage: Kann Procmail oder Maildrop z. B. nach "Alter in Tagen" filtern?

Natürlich.

...

...

...

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.

Apropos: bei der suse-linux-faq haben wir (mangels Maildrop-Spezialisten) ein procmail-"Monopol". Thorsten, hast Du nicht Lust, mitzumachen?

Ist das die hier: http://www.helms.sh/faq/faq.html Thorsten -- There's no such thing as a stupid question. Only stupid people. - User Friendly

Christian Boltz schrieb:

[...] [1] Im Unterverzeichnis entwurf/ kannst Du Dir schon mal ansehen, wie das Layout mal werden soll ;-)

Tja, was hat man, wenn man versucht, eine FAQ in *deutsch* mit *englischen* Titeln zu belegen? Genau: Murks! :-) Das deutsche "inoffiziell" heisst im englischen naemlich "unofficial", nicht "inofficial"... Schade um das Logo :-) Wie waere es, wenn ihr bei deutsch statt englisch bleibt? SCNR, Thomson

Hallo! Christian Boltz wrote:

Am Montag, 24. November 2003 00:12 schrieb Thomas Hertweck:

...

Tja, was hat man, wenn man versucht, eine FAQ in *deutsch* mit *englischen* Titeln zu belegen? Genau: Murks! :-) Das deutsche "inoffiziell" heisst im englischen naemlich "unofficial", nicht "inofficial"...

Laut "ding" gibt es beide Varianten - inofficial und unofficial. Was davon die gebräuchlichere ist, steht allerdings nicht dabei ;-)

In meinem Pons Woerterbuch Deutsch-Englisch/Englisch-Deutsch gibt es nur eine Variante - und Pons ist eigentlich ziemlich gut. Auch dict.leo.org spuckt bei Eingabe von inoffiziell nur eine Variante aus, naemnlich "unofficial". Ebenso ist es bei meinem English Standard Dictionary... Aber es waere natuerlich moeglich, dass es trotz allem auch ein "inofficial" gibt, das moechte ich nicht ausschliessen. Habe ich allerdings so im eng- lischen noch nie (zumindest kann ich mich nicht daran erinnern) gelesen. Meine Bemerkung war auch nicht ganz so ernst zu nehmen... :-)

[...] Allerdings kann es passieren, dass ich das Logo nochmal ändere, damit es besser zum neuen Erscheinungsbild von SUSE passt. Lass Dich überraschen - oder subscribe Dich in der FAQ-Liste, dort gibt es die Entwurfslinks immer früher ;-)

Habe momentan leider nicht so viel Zeit, sonst wuerde ich das vielleicht machen. Allerdings halte ich die Art & Weise, wie man momentan an der FAQ mitarbeiten kann, fuer viel zu kom- pliziert. Wenn es mit Aufwand verbunden ist, dann sinkt (das sagen meine saemtlichen Erfahrungen) das Interesse an Mitar- beit... Aber gut, das muessen die "Verantwortlichen" wissen, wie sie das halten wollen. Wenn es einfach ein Template im Netz gaebe und man das in Ruhe daheim ausfuellen und dann per Mail an einen Maintainer schicken koennte, faende ich das we- sentlich einfacher und glaube, es wuerden auch mehr Leute mit- machen.

...

Wie waere es, wenn ihr bei deutsch statt englisch bleibt?

Im Prinzip ja, aber es müsste dann ja strenggenommen "inoffizielle" heißen, und das kauft uns niemand als "Stempel" ab ;-) Und "inoffiziell SuSE Linux FAQ" liest sich blöd, auch wenn das "inoffiziell" als Stempeltext daherkommt. Von daher tendiere ich momentan dazu, dieses eine Wort englisch zu lassen ;-)

Das halte ich fuer keine so gute Idee, denn es gibt schon eine "Unofficial SuSE FAQ" (http://dinamizm.ath.cx/)[1] von der Schwesterliste suse-linux-e. Um sich da ein bissl abzugrenzen waere es schon besser, es wirklich in deutsch zu halten. Beitraege sollen ja schon in deutsch sein (wenn ich das richtig verstanden habe) und ich faende es vorteilhaft, wenn man das dem Titel auch direkt anmerkt. Vielleicht findet sich ja ein anderer treffender Terminus statt "inoffizielle SuSE FAQ"... Just my 2 cents *g*, Th. [1] auch: http://susefaq.sourceforge.net/

Hallo! Christian Boltz schrieb:

Am Dienstag, 25. November 2003 09:12 schrieb Thomas Hertweck:

...

[...] Habe momentan leider nicht so viel Zeit, sonst wuerde ich das vielleicht machen. Allerdings halte ich die Art & Weise, wie man momentan an der FAQ mitarbeiten kann, fuer viel zu kom- pliziert.

Naja, so schwer ist es eigentlich nicht - Du brauchst nur CVS-Grundkenntnisse (checkout, update, commit) und ein paar XML-Tags (von denen die wichtigsten wie bei HTML sind).

Ich musste echt lachen, als ich das gelesen habe. Es ist ein typischer Effekt: Natuerlich ist es nicht schwer, fuer jeman- den, der taeglich mit diesen Dingen zu tun hat. Ich kann Dir jetzt auch sagen, es ist nicht schwer, die Ausbreitung von Wellen in der Erde zu berechnen - Du brauchst nur Grundkennt- nisse in Mathematik (Laplace-Operator, partielle Ableitungen) und Physik (z.B. elastodynamische Wellengleichung) und schon hast Du alles beisammen. Aber trotz allem glaube ich, dass Du es beim Lesen dieser Zeilen vielleicht nicht unbedingt als "einfach" ansehen wirst (ausser Du bist vielleicht Physiker, aber das weiss ich nicht). Auch auf dieser Liste werden immer wieder Fragen gestellt, die vermeintlich leicht sind, deren Ursache den Fragesteller aber dennoch vor Probleme stellt. Mir passiert das auch manchmal, wenn ich im Hoersaal stehe und unseren Studenten etwas beibringen soll - da denkt man dann auch, das ist ja alles nicht schwer... Man vergisst leider ab und an, sich in die Position der Gegenseite einzudenken; was fuer mich selbstverstaendlich und einfach ist, ist es eben fuer andere noch lange nicht (und umgekehrt). Um zurueck zum Thema zu kommen: ich schaetze mal, fuer einige, die evtl. mal etwas fuer eine FAQ schreiben koennten, ist die mo- mentane Situation nicht ideal. Man braucht von Kristian ein Login, mit CVS kennen sich mit Sicherheit nicht alle aus, ebenso mit XML usw. - das klingt fuer mich alles ziemlich um- staendlich und abschreckend, wenn ich ehrlich sein soll. Dabei bedeutet das keinesfalls, dass kein Interesse besteht - sonst haette ich wohl kaum vor Zeiten ein NVIDIA-Howto und in letzter Zeit das Kernel-Howto geschrieben. Ich benutze z.B. RCS und nicht CVS, ich schreibe HTML/CSS, aber XML, hmm... Vielleicht geht es anderen eben aehnlich. Du wirst wahrscheinlich nun sa- gen, ich solle eben die anderen Dinge lernen, das ist ganz ein- fach - aber Du weisst ja selbst wie das so ist mit diesen Din- gen, die man ansonsten nicht unbedingt braucht. Wenn man Bei- traege fuer etwas haben moechte, dann muss es IMHO so einfach wie moeglich gestaltet werden.

...

Wenn es mit Aufwand verbunden ist, dann sinkt (das sagen meine saemtlichen Erfahrungen) das Interesse an Mitar- beit... Aber gut, das muessen die "Verantwortlichen" wissen, wie sie das halten wollen. Wenn es einfach ein Template im Netz gaebe und man das in Ruhe daheim ausfuellen und dann per Mail an einen Maintainer schicken koennte, faende ich das we- sentlich einfacher und glaube, es wuerden auch mehr Leute mit- machen.

Über die Idee könnte man glatt nachdenken ;-) Niemand hat etwas dagegen, wenn jemand einen guten Text für die FAQ einreicht. Allerdings sehe ich das Risiko, dass die FAQler auch mit weniger guten Texten "bombardiert" werden ;-)

Nun, von "bombadieren" wuerde ich nicht sprechen :-) Wenn Texte zu schlecht sind (Stil/Inhalt betreffend), dann muss so etwas einfach an den Autor zurueck gehen mit bitte um Verbesserung - so geht das bei saemtlichen wissenschaftlichen Veroffentlichun- gen, da wird nicht lange gefackelt. Ein Template, das zur Verfue- gung gestellt wird (z.B. mit einem kurzen Beispielinhalt), und das man quasi nur noch mit Inhalt fuellen muss, wuerde ich fuer eine Idee halten, die man mal diskutieren sollte.

[...] Idee auf die Schnelle: wie wärs mit einem HTML-Formular, das man sich abspeichern und offline ausfüllen kann? Man müsste dann nur zum Versand kurz online gehen. Diese Variante hätte (im Vergleich zu einer Mail) u. a. den Vorteil, dass man zumindest das Grundgerüst der XML-Tags automatisch generieren könnte und damit der Aufwand für die FAQ-Mitarbeiter gering wäre. Wäre diese Lösung akzeptabel?

So etwas waere sicher auch nicht schlecht. Meine Idee zielte ein- fach darauf ab, dass es a) einfacher werden sollte, Beitraege zu liefern und dass es b) fuer denjenigen, der einen Beitrag schreibt, hauptsaechlich auf den Inhalt ankommen darf, und nicht auf den Rest. Mit einem Editor kann eben jeder umgehen, und eine Mail schicken bzw. ein Formular ausfuellen sollte auch noch jeder hinbekommen (im Vergleich zu CVS, XML, usw.).

Allerdings: Priorität hat derzeit, die bereits bestehenden Texte der FAQ zugänglich zu machen (Homepage + XML-Konvertierung), danach könnte man dann bei entsprechendem Interesse auch eine Vorlage für die "externe" Mitarbeit einrichten.

Es war nur ein kleiner Vorschlag meinerseits. Wenn andere eine Art Template/Formular fuer Bloedsinn halten, dann sollte es auch nicht eingefuehrt werden. Ich wuerde auch nicht erwarten, dass im Falle einer Einfuehrung schlagartig die Anzahl der Beitraege in die Hoehe geht :-)

...

[...] Das halte ich fuer keine so gute Idee, denn es gibt schon eine "Unofficial SuSE FAQ" [...]

Weißt Du jetzt, warum ich "_i_nofficial" genommen hab? ;-)

Naja, ein (IMHO) falsches Wort zu nehmen um ein Duplikat zu vermei- den, ist in meinen Augen vielleicht keine so besonders gute Idee :-) Vielleicht hat ja jemand noch einen anderen bahnbrechenden Slogan und teilt ihn uns mit... *g* Gruesse, Thomson

"Antje M. Bendrich" schrieb:

[...] "YaSFAQ", Yet another SuSE FAQ. Klingt ein bißchen nach Yast und ein bißchen nach NASDAQ. Ohne Erläuterung garantiert Suchmaschinen- untauglich.

Da magst Du Recht haben, aber "Yet another SuSE FAQ" finde ich trotzdem ganz witzig... :-) Auch wenn's nicht deutsch ist. CU, Th.

Hallo Christian, Christian Boltz (cb.suse@wein-vin-vinum.net) schrieb am 30.11.2003 (23:41): [Namensvorschläge für FAQ]

Antjes Ideen sind ja schon kreativ, aber so recht gefallen sie mir nicht ;-)

Danke, aber mir auch nicht. Ich konnte nur nicht widerstehen. Gruß, Antje -- "Emacs is a nice operating system, but I prefer UNIX." - Tom Christiansen

Moin, * Christian Boltz <cb.suse@wein-vin-vinum.net> [2003-11-23 00:44]:

Auch KMail kann kompliziertere Filteraktionen ;-) Ich lasse mir hier z. B. CVS commit-Mails durch ein Script pipen, dass die diffs einfärbt (durch Umwandlung in eine HTML-Mail).

Hört sich interessant an. Werden die Diffs gleich vom Server mitgeschickt oder erstellst Du die lokal? In beiden Fällen: Wie macht man das genau? Thorsten -- It is dangerous to be right when the government is wrong. - Voltaire

Hallo Thorsten, Am Sat, 22 Nov 2003, Thorsten Haude schrieb:

* David Haller <david@dhaller.de> [2003-11-20 02:18]:

...

Am Tue, 18 Nov 2003, Thorsten Haude schrieb:

...

* David Haller <david@dhaller.de> [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().

Hallo, Am Mon, 24 Nov 2003, Thorsten Haude schrieb:

* David Haller <david@dhaller.de> [2003-11-23 03:49]:

...

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

Ach was, das geht schon!

Jo, mei, wenn das sauber ueber Dateien verteilt waere oder so...

...

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.

Jo mei, schaun ma halt nach: - - - Schnipp - - - [..] - - - Schnapp - - -

Kommt ja fast hin ;) Je nachdem, wie der MTA die Header setzt / uebermittelt :)

...

...

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

Ist bei mir nicht viel anders. Das initiale Einsortieren dauert dann halt 'ne Minute oder zwei, na und?

Noe. Wenn ich z.B. alles durch SA laufen lassen wuerde, dann braeuchte da so ein Schwung von sagen wir 250 Mails (wie gerade eben) 10-15 Minuten oder sogar laenger. Mein Rechner hat halt nicht soviel "Wumms" ;) Ganz ohne SA (d.h. procmail + awk-script & antivir) wuerde es ca. 1min dauern. Mit SA kommt's auf den Anteil an, denn ich vorher rausfiltern kann. Wenn mal viel Spam eintrudelt, dann dauert das gerne mal 5min... -dnh -- Wenn man Signaturen essen könnte, hätten in Dag° alle durch mich Gewichtsprobleme. [WoKo in dag°]

Hallo, Am Tue, 25 Nov 2003, Thorsten Haude schrieb:

* David Haller <david@dhaller.de> [2003-11-25 01:51]:

...

Am Mon, 24 Nov 2003, Thorsten Haude schrieb:

...

* David Haller <david@dhaller.de> [2003-11-23 03:49]:

...

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

Ach was, das geht schon!

Jo, mei, wenn das sauber ueber Dateien verteilt waere oder so...

Ja wie unterscheidest Du denn zwischen C und C++ innerhalb einer Datei? Kommentare?

Nein. Eben. Klar, ich verwende auch lieber cstdio als das mit C++ iostreams zu machen, aber bei maildrop ist das schon was anderes. Das ist ein abenteuerliches Gemisch... Schau dir einfach mal 'maidrop/deliver.C' bzw. 'maildrop/*.C' an... Das hat bis auf die Namespaces meist relativ wenig mit C++ zu tun... Und dem Code jemandes, der C und C++ nicht "sauber" auseinanderbekommt misstraue ich prinzipiell.

...

Noe. Wenn ich z.B. alles durch SA laufen lassen wuerde, dann braeuchte da so ein Schwung von sagen wir 250 Mails (wie gerade eben) 10-15 Minuten oder sogar laenger. Mein Rechner hat halt nicht soviel "Wumms" ;)

SA ist doch Perl, oder? Dann wird der direkt aus Mail::Audit aufgerufen und hat nur noch minimale zusätzliche Kosten.

Ja. Aber ich verwende ja procmail und nicht Mail::Audit. Genau weil ich die "Kosten" fuer Perl / SA eben nicht will (bzw. diese auf das wenige beschraenken will, was sich nicht vorher ausfiltern laesst). -dnh -- 18: Vorbereitet für den Multimediaeinsatz Es sind noch zwei Slots auf dem Motherboard frei. (Peter Berlich)

Moin, Am Di, den 18.11.2003 schrieb Thorsten Haude um 00:29:

Warum nochmal benutzen alle Procmail? Das ist eine Art Quiz, oder? Wer die unleserlichtste Regel erstellt, bekommt einen Preis?

Weil es sehr weit verbreitet ist, eingespielt und "überall drauf". Aus den von dir angeführten Gründen habe ich nämlich auch keine Lust, mich mit procmail auseinanderzusetzen, aber auch nicht mit mail::irgendwas, und für procmail ist halt "sofort" was im Netz ergoogelt. procmail filtert bei mir das, was "sein muß": Kasperfilter und Swen-Würmer. Alles andere mache ich noch viel einfacher: Ich klicker mir meine Regeln in meinem MUA zusammen. Alles weitere Verteilen von Mailinglisten und dergleichen geht auch mit WENN (X-Header X-List) IST suse-linux VERSCHIEBE IN POSTFACH Suse-Liste per Maus. Nein, ich schreie nicht, alles in Versalien sollen Buttons oder Dropdowns sein. :-) Ich habe ein paar Rechner in Betreuung, an denen ich aus verschiedenen Gründen nichts (mehr) anfassen will. Irgendwelche Möhren mit 4-GB-Platten und Kernel 2.0, oder "proprietäre" Hardware-mit-Linux-drauf Sachen, bei denen ich einen Teufel tun werde und irgendwas selbst kompilieren. Für die also sowieso schonmal procmail, also auch für alle anderen. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

*** Joerg Rossdeutscher <ratti@gesindel.de> wrote:

Zu guter Letzt muß man nur noch die Datei ~/.plonk mit Adressen füllen:

und wie machst du das? händisch? würdest du mutt benutzen, könntest du dir [1] mal ansehen. :0:

cat ~/.plonk timo@nitwit.de marcel-stein@arcor.de suse@nitwit.de

/dev/null micha [1] http://lists.debian.org/debian-user-de/2002/debian-user-de-200201/msg00905.h...

* suse@nitwit.de postete am 17. Nov. 2003 folgendes:

On Sunday 16 November 2003 14:57, Rafael Kolless wrote:

...

Deine Reaktion ist mir völlig unverständlich, hat es Dich genervt, dass ich

Ich hab mich dazu schon geäussert. Dass du darauf nicht eingehst, sondern stattdessen jetzt hier rumsülzt, relativiert meine Entschuldigung.

BTW: Sagt mal, habt ihr alle nichts zu tun und kein echtes Leben?

Im Gegensatz zu Dir, eines ohne irgendwelche Drogen *fg*

Ich habe auf diese Soap Opera hier eigentlich keine Lust...

Dann mach Deinen Rechner aus, das Fenster auf und befördere diesen aus dem selbigen. Bye Michael -- nitwit found - Remove? (Y)es (S)ure (F)ine (O)K _______________________________________________________________________ http://macbyte.info/ ICQ #151172379 http://autohbci.macbyte.info/

Am Montag, 17. November 2003 12:21 schrieb suse@nitwit.de:

On Sunday 16 November 2003 14:57, Rafael Kolless wrote:

...

Deine Reaktion ist mir völlig unverständlich, hat es Dich genervt, dass ich

Ich hab mich dazu schon geäussert. Dass du darauf nicht eingehst, sondern stattdessen jetzt hier rumsülzt, relativiert meine Entschuldigung.

Mmmh, ging es hier nicht einmal ursprünglich um den DMA-Modus des Brenners? -- www.pinguin-and-knights.org 2003 by Lontro

* suse@nitwit.de postete am 15. Nov. 2003 folgendes:

On Sunday 16 November 2003 09:17, Rüdiger Meier wrote:

...

Das interessiert hier wohl niemanden mehr!

Haha, ja, genau das ist der Punkt :->

Versuch mal drüber nachzudenken :->

Das mit dem Nachdenken, solltest Du mal üben. Bye Michael -- God said: tar xfvz universe.tar.gz - and the Universe was! _______________________________________________________________________ http://macbyte.info/ ICQ #151172379 http://autohbci.macbyte.info/

suse@nitwit.de [Sat, 15 Nov 2003 09:01:07 +0100]:

"daS"...Herrje...jaja, ok, in dem Fall hab ich wohl etwas überreagiert, ich entschuldige mich.

Aber bei dem ganzen Hohlgequatsche der virtuellen Pimpfe hier geht's einem echt auf den Nerv.

Angesichts dieser Aussage bezweifle ich, dass es dir mit der Entschuldigung ernst ist. Falls du es noch nicht gemerkt hast: du befindest dich hier auf einer öffentlichen Mailingliste wo solch arrogantes Dummgequatsche völlig fehl am Platz ist. Philipp

* suse@nitwit.de textete am 14.11.03:

On Saturday 15 November 2003 20:29, Rafael Kolless wrote:

...

Ich habe immer Fehlermeldungen vom SMTP-Server erhalten und KMail meinte der Versand war nicht erfolgreich.

Das ist der integrierte Vollidioten-Spam-Schutz.

...

Das Problem liegt wohl am SMTP von suse@nitwit.de, er meldet immer:

Nein, das Problem liegt in deiner debilen, völlig verpickelt-hoffnungenslos-doofen Birne.

Und sowas von einem, der nicht mal seinen Namen als Absender eintragen kann... Kannst du dich jetzt woanders unbeliebt machen? Danke. Henne, kannst du dem mal bitte auf die Zehen treten? flo -- Regeln sind da um denn kleinen Mensch zu baendigen... Die groessen tun eben was sie wollen... [Alain Declercq in datu]

* suse@nitwit.de postete am 14. Nov. 2003 folgendes:

On Saturday 15 November 2003 20:29, Rafael Kolless wrote:

...

Ich habe immer Fehlermeldungen vom SMTP-Server erhalten und KMail meinte der Versand war nicht erfolgreich.

Das ist der integrierte Vollidioten-Spam-Schutz.

...

Das Problem liegt wohl am SMTP von suse@nitwit.de, er meldet immer:

Nein, das Problem liegt in deiner debilen, völlig verpickelt-hoffnungenslos-doofen Birne. ____ _ ___ _ _ _ __ __/\_| _ \| | / _ \| \ | | |/ /_/\__ \ / |_) | | | | | | \| | ' /\ / /_ _\ __/| |__| |_| | |\ | . \/_ _\ \/ |_| |_____\___/|_| \_|_|\_\ \/

Bye Michael -- Wenn ich scherzen will, sage ich die Wahrheit. Das ist immer noch der größte Spaß auf Erden. -- George Bernard Shaw _______________________________________________________________________ http://macbyte.info/ ICQ #151172379 http://autohbci.macbyte.info/