| |
 |
| Kolumnen: Aktuelle Text-Modus-E-Mail-Programme im Vergleich
|
|
|
Veröffentlicht durch XTaran am Freitag 05. Januar 2007, 21:23
Aus der es-geht-doch-nichts-über Abteilung
|
|
|
|
|
Via NewsForge bin ich auf einen etwas älteren Artikel bei Linux.com gestoßen, in welchem der Autor, ein Sylpheed-Benutzer, die in seinen Augen aktuellen E-Mail-Clients (oder auch MUA, Mail User Agent) für den Text-Modus vergleicht, um zu schauen, ob sich der Weg zurück nicht doch vielleicht lohnt. Interessant ist dabei alleine schon, welche E-Mail-Clients er bewußt ausgeschlossen und welcher er getestet hat...
|
|
|
|
|
|
|
Bei Elm und Elmo sieht er die Entwicklung als tot an (bei letzterem ist außerdem noch die Webseite kaputt) und hat sie deswegen gar nicht erst getestet. Dass er Pine und Mutt getestet hat, verwundert dagegen wohl kaum jemanden, sind sie doch die beiden momentan am meisten genutzten Text-Mode-MUAs schlechthin. Weiter hat er noch den mir bisher unbekannten Pine-Klone Cone (COnsole Newsreader and Emailer) der Courier-MTA-Leute und NMH (New Mail Handling System), eine Sammlung von Kommandozeilen-Tools zur E-Mail-Bearbeitung von MH-Mailboxen sowie dessen Emacs-Frontend MH-E getestet.
Den offiziellen und aufgrund seiner Apache-Lizenz auch freien Pine-Nachfolger Alpine (Apache License Pine) wollte der Autor des Artikels zwar auch testet, bekam ihn aber unter Debian und Ubuntu nicht zum kompilieren. Umso erfreulicher ist, daß es seit dem 1. Januar 2007 Alpine als Debian-Paket in Debian Unstable gibt. Von Cone gibt es dagegen bisher noch kein Debian-Paket.
Die nächste Frage, die sich einem stellt: Welche Text-Mode-Email-Clients hat er übersehen? Oder gibt es wirklich so wenige? Spontan fallen mir noch die minimalistischen Text-Mode-MUAs mail bzw. mailx (z.B. aus den GNU Mail Utilities oder von OpenBSD) und nail (Reimplementation von mail/mailx, jetzt Bestandteil des Heirloom Projektes) sowie die für Emacs geschriebenen MUAs RMAIL (bei GNU Emacs und XEmacs dabei), vm (bei XEmacs, für GNU Emacs verfügbar dabei) und GNUS (ursprünglich ein Newsreader) ein. Diese drei Emacs-MUAs werden definitiv genutzt — und selbst bei den klassischen Kommandozeilen-MUAs, mit denen auch ich vor über 10 Jahren angefangen habe, gibt es heute noch Leute, die das als ihren täglichen E-Mail-Client benutzen.
Was fehlt noch? Zwei Pine-Forks bzw. -Klone wurden erwähnt, aber in der Pine-Community sind auch noch Patches (Farben, Support für weitere Mailbox-Formate und vieles mehr) recht üblich. Auch in der Mutt-Community hat's vor längerer Zeit mal gekriselt, weil lange nichts passiert ist bei Mutt. Das hat sich zwar jetzt geändert, aber aus dieser Zeit übrig geblieben ist z.B. Mutt-NG, der gerade als Patch-Sammlung gegen aktuelle Mutt-Versionen versucht, wieder aufzuerstehen. Da darunter aber auch tiefgreifende Patches wie eine Sidebar und NNTP-Support (Pine und seine Klone sind ja nicht nur MUAs sondern auch Newsreader) sind, sollte Mutt-NG bei solch einer Liste oder Vergleich schon auch als eigenständiger MUA angesehen werden.
Ein Blick in die Debian-Paketliste der Sektion Mail bringt noch weitere Text-Modus-MUAs zum Vorschein: af (Emacs-ähnlicher MUA, der u.a. Cut & Paste zwischen verschiedenen Mail-Foldern kann, aber weder in Lisp geschrieben ist, noch Emacs braucht), biabam ("Biabam Is A Bash Attachment Mailer", einfacher Kommandozeilen-Mailer zum Attachments versenden), SendEmail (ebenfalls zum Versenden von Mails von der Komandozeile aus), etPan! (ähnlich zu mutt, aber Konfiguration über Benutzer-Interface möglich, baut auf libEtPan! auf, hat außerdem noch ein grafisches Pendant namens etPanX) und Mush (The Mail User's SHell; mit zu mail und mailx ähnlichem Kommandozeilen-Interface, leider unfrei, da wie bei Qmail modifizierte Versionen nicht vertrieben werden dürfen) sowie die Emacs-MUAs Cmail (leider nur japanische Webseite), Wanderlust (E-Mail und News, leider nicht zusammen mit vm oder GNUS installierbar, jedenfalls nicht mit Debian) und Mew (inkl. den darunterliegenden Kommandozeilentools und Mail-Bibliotheken aus dem Paket im).
Was für Text-Mode-MUAs verwenden denn die Symlink-Leser? Ist mutt wirklich der beliebteste und beste™ Text-Mode-MUA? Ist Pine der ewige Zeite? Benutzt jemand Pine- oder Mutt-Klone? Wie verbreitet sind die Emacs-MUAs?
|
|
|
|
< Audi migriert komplett auf Linux | Druckausgabe | Alan Cox reicht Patent für DRM ein > | |
|
|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
|
|
|
|
|
|
|
|
Also der IMAP-Support von Pine ist eigentlich nicht grade der schlechteste, vor allem wohl auch deswegen, weil der uw-imapd von den gleichen Leuten entwickelt wird/wurde. Das gleiche würde ich von Cone erwarten, den der ist von den Leuten, die den Courier IMAPd geschrieben haben.
Der IMAP-Support von Mutt ist zwar nicht unbedingt grade der performanteste, aber ich habe auch schon schlechtere gesehen.
Insbesondere habe ich noch keinen GUI-MUA gesehen, der IMAP über eine simple SSH-Verbindung (ohne Port-Forwarding) zum IMAP-Server tunneln kann. (Hab allerdings auch noch nicht aktiv danach gesucht.) Pine und Mutt können das. Und dabei ist "ssh imap.example.com /etc/rimapd" soooo einfach. Mit ssh-agent und ssh-add muss man dann nicht einmal sein Paßwort im MUA speichern oder bei jeder Session erneut eingeben, das macht alles der SSH-Agent, den man eh verwendet.
P.S.: Weiß jemand ob irgendein MUA (egal, ob grafisch oder nicht) außer Cone schon SMAP (Simple Mail Access Protocol) unterstützt? Hat das schonmal jemand genutzt oder zumindest ausprobiert? Taucht datt watt? :-)
--
There is no place like $HOME
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich habe eine Menge der Zeit in der ich mein Studium versaut hab damit verbracht einen vernünftigen E-Mail-Client für IMAP zu finden. Hängengeblieben bin ich bei mutt + offlineimap. Ich synchronisieren mir meine Mails lokal in einem Maildir und greife darauf mit mutt zu. Ja, das ist schon ein Stück weit schmerzhaft, aber alles andere war noch schlimmer (und man hat keinen Ärger mit dem Notebook im Zug). Die ganzen grafischen Mail-Clients sind einfach sowas von langsam, sobald man mehr als 1000 Mails in der Box hat... Also ich meine jetzt vor allem beim Suchen und limitieren nach Absendern, Subject oder Datum. Auch können alle anderen Clients den Index nicht so schön Bunt machen...
Aber ich bin offen für neues. Ich hätte gerne endlich einen Mailclienten, der Spaß macht.
--
Today's weirdness is tomorrow's reason why.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 06. January 2007, 12:09 MEW (#7)
|
|
|
|
|
Mit einer großen Mailbox wird Mutt aber auch nervig, weil er keinen Index-Cache bietet. D.h. er muss jede Mail einzeln öffnen und die Header einlesen. Es ist zwar nicht unerträglich langsam, aber mir einem Cache würde es gar nicht auffallen. Sylpheed hat so einen Index-Cache und damit dauert es keine x Sekunden einen Mailfolder einzulesen. Das ist allerdings auch so ziemlich das einzige was mich an Mutt stört. Gut die andere Sache ist, dass man so einen Quatsch wie MSMTP (oder für Masochisten: sendmail) braucht, weil klassiche MUAs das nicht selbst können.
|
|
|
|
|
|
|
|
|
|
|
|
|
3.105. header_cache
Type: path
Default: ""
The header_cache variable points to the header cache database. If
header_cache points to a directory it will contain a header cache database
per folder. If header_cache points to a file that file will be a single
global header cache. By default it is unset so no header caching will be
used.
--
Today's weirdness is tomorrow's reason why.
|
|
|
|
|
|
|
|
|
|
|
|
|
Kuhl, danke!
Das gab's noch nicht, als ich meinen mutt das letzte mal so richtig von vorne bis hinten durchkonfiguriert habe.
*gleichausprobierenmüss* Denn in einer Umgebung mit vielen identischen Workstations und $HOME per NFS, geht nix über IMAP. /var/spool/mail/$USER per NFS tut zwar auf den ersten Blick und ist auch einigermassen performant, aber mangels Locking nicht zuverlässig. Brauchen tut man es aber trotzdem, nämlich read-only für (x)biff & Co. :-)
Und das IMAP tut wie IIRC schonmal irgendwo erwähnt ohne Passwort per SSH-Keys und SSH-Agent, da man den IMAPd einfach per SSH auf dem Mail-Server startet. Eine bessere Lösung kenne ich nicht. Außer vielleicht per ssh auf den Mailserver und die Mails dort mit 'nem MUA direkt aus /var/spool/mail/$USER lesen. Aber das skaliert bei vielen Usern nicht, wenn's zuviele User machen. Und ein Mail-Server ist normalerweise auch nicht für die interaktive Nutzung sondern für den Server-Betrieb optimiert, d.h. auf Durchsatz und nicht auf die geringe Latenz eines UI. :-)
Privat mache ich das allerdings lese ich meine Mail auf dem Server in einem screen mit mutt direkt aus /var/spool/mail/$USER (wie es sich gehört) und $HOME/Mail/-*. Alles was in $HOME/Mail mit "-" beginnt, sind Incoming-Mailboxen. Das ist in mutt auf Tastaturen mit US-Layout als z.B. "=-blafasel" besonders leicht zu tippen und sticht bei ls schön hervor. Außerdem wird es bei alphabetischer Sortierung oben einsortiert.
Das Einsortieren der eingehenden Mails geschieht übrigens ebenfalls klassisch: mit procmail und SpamAssassin.
Neben einer Shell und einem mutt läuft im Screen auch noch ein GNU Emacs mit einem Emacs-Server und $EDITOR ist auf "emacsclient" gesetzt. D.h. der mutt verbindet beim Mailschreiben einfach zum Emacs und dort tippe ich dann die Mail mit dem post-mode.
Dieses Setup hat sich bei mir seit über 5 Jahren gut bewährt und wird immer, wenn ich neue mutt-Features entdecke, passend erweitert.
--
There is no place like $HOME
|
|
|
|
|
|
|
|
|
|
|
|
|
ich hab das einfach in /tmp gesetzt und /tmp ist als tmpfs gemountet. :-)
--
Today's weirdness is tomorrow's reason why.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 06. January 2007, 15:48 MEW (#15)
|
|
|
|
|
Das erscheint mir nicht sehr intelligent.
|
|
|
|
|
|
|
|
|
|
|
|
|
dafür ist es um so intelligenter, nicht zu verraten, warum es nicht intelligent ist.
--
Today's weirdness is tomorrow's reason why.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 06. January 2007, 15:46 MEW (#14)
|
|
|
|
|
NIH.
$ mutt -v|head -n1
Mutt 1.4.2.2i (2006-07-14)
Was ist das? Mutt-devel?
|
|
|
|
|
|
|
|
|
|
|
|
|
nein, 1.4 ist stable. 1.5 ist devel (siehe mutt.org)
--
Today's weirdness is tomorrow's reason why.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 06. January 2007, 22:35 MEW (#21)
|
|
|
|
|
Ja, eben. Ich habe 1.4. Da gibt es keine Option "header_cache".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Den Vorteil von IMAP habe ich für mich persönlich nie gesehen.
Es gibt viel zuviele problematische Punkte, die IMAP für den Benutzer (also mich :) nicht attraktiv macht.
Es braucht eine ständige Internetverbindung. Auch heute habe ich das nicht überall.
Wenn die Verbindung nicht gegeben ist, muss der MUA lokale Kopien vorhalten (sonst kann man ihn gleich in die Tonne treten). D.h. schon mal grösseren Programmieraufwand mit was-weiss-ich-nicht-wievielen Stolperfallen.
Die meisten MUA haben keine wirklich gute IMAP-Implementation. Und pain tue ich mir nicht wieder an nur alleine wegen IMAP.
Die Aufgabe von IMAP ist, für einen lokalen Client die Mails auf einem Remote-Rechner so darzustellen, als wären sie lokal. Dafür muss man durch einige Reifen springen. Wenn ich einen Rechner habe, der 24 Stunden am Tag läuft, ist es viel einfacher, wenn ich mich per ssh -X auf dem Rechner einlogge und dann mit gnuclient einen XEmacs öffne, der sich in die bestehende XEmacs-Session einklingt.
Wenn ich mit meinem Notebook verreise und E-Mails erhalten will, mache ich den Standard-Sync mit unison, der mein Home-Verzeichnis des Desktops und des Notebooks abgleicht und habe alle Mails auf dem richtigen Stand. Ich kann auch neue Mails auf dem Notebook empfangen und wenn ich wieder zu Hause bin synchronisieren. Völlig problemlos.
Für mich persönlich hätte IMAP nur den Vorteil, dass ich bei meinem Mail-Provider eine Ordnerstruktur erstellen kann. Aber das ist für mich der ganze Overhead nicht wert.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 06. January 2007, 15:56 MEW (#16)
|
|
|
|
|
Ich finde auch das IMAP eigentlich eher für den Business-Betrieb (und ähnliches) gedacht ist. Denn dort will man eher nicht, dass die Mails auf den einzelnen Workstations verstreut liegen und selbst NFS ist im Zweifel dafür meist auch suboptimal. Für den Heimbereich finde ich IMAP allerdings auch nicht sonderlich sinnvoll. Schließlich sind auch di wenigsten Mails verschlüsselt, da möchte ich sie nicht unnötig lang dem Internet oder sonstigen Schnüfflern aussetzen.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich glaube, ihr versteht den Sinn von IMAP nicht. Wer immer mit dem gleichen Programm und dem gleichen Rechner arbeitet, hat es auch schwer, den Vorteil von IMAP zu sehen. Dabei sind sie, wenn man den Fokus nur etwas erweitert, offensichtlich:
Da wäre die Datensicherung: ein zentraler Mail-Server läuft sich einfacher sichern und da er 24/7 läuft, gibt es auch keine Probleme damit, daß das mal vergessen wird.
Da wäre die Erreichbarkeit: klar, wenn man immer mit dem selben Gerät seine Mails ließt, dann braucht man das vielleicht nicht so, aber neben einem Mail-Client ist eine Web-Mail-Lösung sehr hilfreich. Denn nicht immer kann man sein Notebook ans Netz hängen und Mails empfangen (u.U. über einen SSH-Tunnel). Da geht dann Web-Mail und der klare Vorteil ist, daß die Änderungen, die man mit den Mails gemacht hat (löschen, verschieben, beantworten und damit Sent-Folder füllen) auch später im "richtigen" Mailprogramm schon drin sind. Wer vielleicht noch seine Mails mit verschiedenen Rechnern ließt (Notebook, PDA, Desktop), wird das erst recht gut finden.
Da wäre Multiuser: ein gerne übersehenes und auch selten implementiertes Feature ist die Möglichkeit der Shared-Folder, d.h. andere Nutzer können auf gemeinsame Folder zugreifen. Das ist gut als Mail-Archiv oder manchmal bei Urlaubsvertretung und manchmal für die Sekretärin, die die Mails ihres Boss lesen muss.
Dann noch die Gleichgültigkeit des Formates: wie die Mails angelegt werden (mbox, maildir, Datenbank) ist bei IMAP völlig egal. Man braucht keinen Client, der diese Formate kann.
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 01. March 2007, 11:00 MEW (#33)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Gnus hat ein großes Problem: solange es Mails saugt, bleibt es stehen... (ausser man nimmt auch wieder sowas wie offlineimap)
--
Today's weirdness is tomorrow's reason why.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wessen Problem das ist, ist mir eigentlich ziemlich egal :-)
--
Today's weirdness is tomorrow's reason why.
|
|
|
|
|
|
|
|
|
|
|
|
|
Da die Webbasierten Lösungen immer besser werden, verlieren klassische Mailclients immer mehr an Bedeutung..
Web-Basierte Clients bieten Zugriff von überall her, eine schnellere Suche, da das Zeug indexiert wird (ja, das geht auch auf dem Desktop), Ein sicheres Backup...
Viele Anbieter bieten auch Clients für Mobile Geräte an. Somit kann man Traffic sparend überall seine Mails abrufen, mit weniger overhead als POP oder IMAP, weil z.B. nicht die gesamten Headers heruntergeladen werden müssen, sondern nur das wirklich benötigte geliefert wird...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Web-Basierende Lösungen sind eine nette Ergänzung, aber einen textbasierenden Client kann es nicht ersetzen. Allein schon wenn man mal offline ist (z.B. im Zug [im Tunnel]), oder bezogen auf die Geschwindigkeit. Und dank IMAP muss ich mir meinen Mailclient eigentlich immer aussuchen und kann hin und her hüpfen, wie ich gerade will...
--
Today's weirdness is tomorrow's reason why.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 06. January 2007, 17:18 MEW (#20)
|
|
|
|
|
Ich befürchte für Otto Normal könnte das sogar stimmen. GMail ist ja ziemlich beliebt. Aber für Power-User kann das höchstens eine Ergänzung sein. Die Web-Interfaces bieten ja teilweise nicht einmal eine verschlüsselte Verbindung und das Signieren oder Verschlüsseln von Mails ist auch nicht sinnvoll möglich, d.h. entweder nur umständlich per Upload bzw. Copy&Paste oder sonst nur per Snake Oil. Effizientes Suchen ist auch kaum möglich und bei der Archivierung ist voll und ganz auf den Anbieter angewiesen. Außerdem ist es äußerst zweifelhaft ein Webbrowser für jeden Mist zu benutzen, da die Entwickler in dem Bereich sehr oft wenig Verständnis von Sicherheit haben bzw. das Web bzgl. Sicherheit sowieso noch in den Kinderschuhen steckt. Ständig finden sich irgendwo Möglichkeiten für Cross-Site-Scripting und meist ist das dann dank Web (2.0) auch noch plattformunabhängig.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja, das mit dem verschlüsseln von E-Mails ist ein Problem, da gebe ich dir Recht...
Zumindest das abrufen ist z.B. bei GMail verschlüsselt möglich. Auch POP wird ja verschlüsselt gemacht...
Um nochmals GMail als Beispiel zu nehmen, ich suche damit deutlich effiziennter als Lokal mit Outlook oder dem Donnervogel bzw. der Eistaube. Vor allem auch durch die Suchgeschwindigkeit. Ich kann 10 Suchanfragen an Gmail richten (und so entsprechend die Suchwörter optimieren) in der Zeit, wo Thunderbird/IceDove mir eine Suche abwickelt.
Die Archivierung kannst du ja dank POP auch selber machen. Du lädst dir einmal pro Woche alle Mails runter und sicherst die irgendwo... Dann ist man nicht mehr auf den Anbieter angewiesen.
Die Zukunft läuft meines Erachtens auf Web-Basierte Anwendungen raus, GMail ist wie gesagt heute in einigen Bereichen deutlich angenehmer als ein Desktop-Client. Und sicherheitstechnisch ist es vor allem auch für Anfänger interessant, da solche Clients z.B. die Files auf Viren überprüfen, es gibt unglaublich viele Windows Nutzer, die keinen Virenscanner haben. Ebenfalls gibt es solche E-Mail Web-Clients schon sehr lange, ich glaube auch da sollte langsam ein gewisses Sicherheitsbewusstsein entstanden sein...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 16. January 2007, 15:37 MEW (#26)
|
|
|
|
|
verschlüsselung wird bei gmail sogar erzwungen. unverschlüsselt kommst du weder über pop noch über web an deine mails.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 17. January 2007, 12:55 MEW (#27)
|
|
|
|
|
Für den Login oder die gesamte Session? Die meisten Webseiten verschlüsseln nur den Login und der Rest wird unverschlüsselt übertragen, da kann man sich leicht vertun. Außerdem ist es zweifelhaft wie effektiv die Verschlüsselung ist, bei einem Branchenriesen, der auch noch US-amerikanischem Recht unterliegt. Da kann Google lange behaupten, sie würden niemals nie staatlichen Organisationen Zugriff auf ihre Daten geben.
Die amerikanische Bevölkerung(!) hat ja eindrucksvoll bewiesen, dass es sie einen Dreck scherrt, wenn Ausländer ausspioniert werden. Wenn es aber an die eigene Backe geht, dann verhalten sie sich wie Mimöschen und finden sogar das Vorzeigen einer ID-Card am Flughafen unzumutbar, während die Untermenschen am Nebenschalter wie Verbrecher behandelt werden, selbst wenn es sich nur um einen Zwischenstopp handelt.
Wenn Google es mit Datenschutz ernst meinte, dann hätten sie ihre Infrastruktur längst ins Ausland verlegt.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 22. January 2007, 19:36 MEW (#29)
|
|
|
|
|
Udo Vetter meinte auf dem 23C3, dass den deutschen Behörden sehr schwer ist von Google irgendwelche Zugangsdaten zu bekommen und er es deswegen sehr empfehlen kann.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 06. February 2007, 21:34 MEW (#31)
|
|
|
|
|
Du wirst es nicht glauben, aber es gibt schlimmere Organisationen als deutsche Behörden. Das Google dich vor denen schützt, ist zu bezweifeln. Behaupten kann Google vieles.
|
|
|
|
|
|
|
|
|
|
|
|
|
Web-Basierte Lösungen verdummen breite Userschichten, die garkeinen Schimmer mehr haben was ein E-mailclient (ob Text oder bunt) überhaupt ist. Da wurden mir von Arbeitskollegen schon unvermittelt Sprüche wie "Ich konnte dir die Mail nicht schicken, der Webserver war nicht erreichbar" an den Kopf geworfen, und ich musste mich echt zusammenreissen um nicht unhöflich zu werden.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 12. January 2007, 10:13 MEW (#25)
|
|
|
|
|
Warum müssen sie genau wissen was ein Web/E-Mailserver macht wenn sie nur E-Mails versenden möchten?
Das Internet ist halt auch für Leute benutzbar die keine Lust/Zeit haben sich erst in techn. Details einzuarbeiten
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 01. February 2007, 11:10 MEW (#30)
|
|
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 28. February 2007, 17:03 MEW (#32)
|
|
|
|
|
... bin ich ein anonymer Feigling, wenn ich keine Cookies erlaube???
:-p
|
|
|
|
|
|
