Hallo, On Wed, 09 Jul 2003, Konrad Neitzel schrieb:
Argh ... mit Mozilla habe ich viele schlechte Erfahrungen gemacht! Der scheint eine komische Art und Weise zu haben, wie er verschiedene Konfig-Dateien behandelt. [..] Aber da kommt dann ein Knackpunkt, der mich an KDE z.B. auch stört: Ich will gerne gewisse Einstellungen sichern, aber doch nicht alles. Wo liegen von KMail die Einstellungen? Die würde ich gerne sichern. Filterregeln und so ....
Du willst fetchmail[1], deinen $MTA_OF_CHOICE, procmail und mutt verwenden... Das richtest du einmal sauber ein, und "dann laeuft das"[tm]. Mit dem richtigen Editor (wie xemacs) z.B. auch problemlos und immer "richtig" sowohl auf der Konsole wie unter X[3]. Klar, bei mutt bastelt man gern mal nen neuen hook fuer diese, oder einen fuer jene ML, bzw. passt die "subscribe"/"mailinglists" oder auch "alternates" Variablen an, aber wenn man das sauber in passende config-Dateien auslagert, ist das sehr uebersichtlich. Und auch die procmail-Regeln kann man "auslagern". Bsp: .muttrc .mutt/mailcap .mutt/aliases .mutt/keybind .mutt/personal .mutt/colors .mutt/gpg.rc .procmailrc .procmail/sort.rc .procmail/kill.rc .procmail/kill-suse.rc Schau mal bei Sebastian (www.helms.sh) nach, der hat da IMO eine gute Beispielconfig. Dein "Problem" reduziert sich dann auf ein tar cvzf mail-config.tar.gz .procmail* .mutt* tar xvzf mail-config.tar.gz (ggfs. ergaenzt um die MTA config). -dnh, der fuer das ganze GUI-MUA-Gemurkse nur noch ein verstaendnisloses Kopfschuetteln uebrig hat... PS: ".procmail/kill.rc" ist bei mir leer, dafuer habe ich kill-suse.rc, das killfile fuer diese ML, "aufgemotzt": ==== vereinfacht, da ich bei mir noch ein paar Sachen mehr mache ==== # $HOME/.procmail/kill-suse.rc MONTH=`date '+%Y-%m'` :0 H ### 27.02.2001 ### expires: never * 1^0 ^From.*ob_ok@gmx.net # [snip] ### Mon Jan 27 23:27:40 CET 2003 ### expires: never, lernresistent * 1^0 ^From:.*marcel-stein@t-online.de * 1^0 ^From:.*marcel-stein@arcor.de # [snip] ### AND_ACTION ### suse-linux-killfiled ==== Ja, richtig gesehen, das gesamte "kill-suse.rc" ist eine einzige Regel, mit Kommentaren und einer deutlich komplexeren "Action" als oben in der gekuerzten Fassung... z.Z. fehlt mir nur noch eine spezifisches kill-spam.rc, da mir spamassassin zu lahm ist... Im Moment laufen bei mir einfach zu viele Mails unnoetig durch spamassassin, da ich i.d.R. "eintoenig" spam bekomme ("ham" wird sowieso vorher aussortiert :), da liesse sich durch eigene procmail-Rezepte, z.B. auch fuer Virii wie die Sor?big Varianten, einiges an Performance gewinnen... Ich plane eine Abwandlung von "nixspam"[2] umzusetzen und spamassassin erst anschliessend im Regelwerk ;) PPS: Rants zu den GUI-MUAs mit denen ich bisher Kontakt hatte, erspare ich mir an dieser Stelle... [1] oder Alternativen, see sig [2] ftp://ftp.ix.de/pub/ix/ix_listings/2003_05/nixspam.procmailrc [3] Im Gegensatz z.B. zu nedit. Fuer vim muesste man wohl ein wrapperscript basteln, dass ggfs. gvim bzw. xterm aufruft[4]. [4] ok, ich verwende auch ein wrapperscript, aber ein "intelligentes" fuer gnuserv, so dass bei mir immer nur ein xemacs laeuft: ==== ~/bin/gnuclientorxemacs [mit alias gc='gnuclientorxemacs'] ==== #!/bin/sh if ps | grep '[g]nuserv'; then exec gnuclient "$@" else exec xemacs -f 'gnuserv-start' "$@" fi ==== Die Erkennung/Umschaltung X/Konsole macht XEmacs hingegen selbst. Apropos: via xemacs/gnuclient lassen sich wunderbar Daten zwischen Konsole und X austauschen, viel bequemer als via cat /dev/vcs* bzw. cat /dev/pts/*... Jup, ein gnuclient auf der Konsole verbindet sich zum XEmacs unter X und andersrum! Man muss nur beachten, dass je nachdem wo der "eigentliche" XEmacs aufgerufen wird, u.U. eine abweichende config verwendet wird. -- Kein Wunder, daß Eric Raymond so auf Schußwaffen steht. Wenn ich den Usern meiner Software mit so schöner Regelmäßigkeit Mails löschen würde, wäre Selbstverteidigung auch ganz oben auf meiner Liste. -- Felix von Leitner in dcsm ueber fetchmail