From: Boris Kraut Organization: Date: Wed, 29 Feb 2012 04:02:43 +0100 Category: Message-ID: <20120229030243.LQUzln@silberbruch> Keywords: Comments: To: undisclosed-recipients: ; Subject: Re: Umstellung auf IMAP - IMAPFilter Nachdem ich mich bei OfflineIMAP zu der Erkenntnis durchgrungen hatte, wie, wo und wann gefiltert und sortiert werden sollte, bin ich jetzt doch wieder ein Schritt zurueck: Mir wurde imapfilter [1] nahegelegt und ich bin sehr zufrieden damit. Filter ist eine Untertreibung, denn prinzipiell gibt es einem ein LUA-Interface fuer IMAP-Postfaecher. Was man damit tut, ist einem komplett selbst ueberlassen. Mails nach verschiedenen Mustern in Folder einzusortieren duerfte die Hauptanwendung sein, aber auch kurze Status-Ausgaben oder Suchen sind moeglich. Suchen ist ein gute Stichwort, denn neben imapfilter gibt es noch jede Menge anderer IMAP-Tools, die ich mir evtl. spaeter einmal anschauen sollte. Bei der Recherche bin ich aber noch auf einige Projekte gestossen -- bzw. wieder gestossen -- die versuchen die doch sehr monolithischen MUAs aufzubrechen, indem sie die Indexer- und Suchfunktion auslagern. MU alias maildir-utils [2] und notmuch [3] sind zwei auf Xapian basierende Projekte die auch sehr gut mit Maildirs umgehen koennen. Aufbauend auf letzterem gibt es auch ein paar fix-und-fertig MUAs. Von der Idee her finde ich die Indexer- Sache super, aber ob ich mir Xapian als Dependency reinziehen will, muss ich mir nochmal ganz genau ueberlegen. Aber es ist schoen zu sehen, dass beim Thema Mail nicht nur Bestandspflege gemacht wird, sondern dass sich da mei mehreren Projekten was tut und auch immer noch neue Sachen angegangen werden. Es scheint doch noch ein paar Leute zu geben, die mit dem Ist-Stand nicht zufrieden sind :). Aber zurueck zu imapfilter. Da ich IMAP bisher nie wirklich be- achtet und als neue, multiuser, multifolder Version von POP an- gesehen habe, war es fuer mich extrem ueberraschend zu merken, dass man damit nicht nur Nachrichten innerhalb einer Mailbox in verschiedene Folder zu schieben -- das leuchtet ja ein, wenn man mehrere Folder hat -- sondern auch komplett neue Nachrichten zu erstellen. Prinzipiell kann man also auch per IMAP Mails einliefern, im RFC wird aber klar, dass es nicht als SMTP-Ersatz gedacht ist... > Note: The APPEND command is not used for message delivery, > because it does not provide a mechanism to transfer [SMTP] > envelope information. ...aber man will ja vielleicht Mails von einem lokalen Folder [oder einer anderen IMAP-Mailbox] hochladen. Genau das mache ich naemlich gerade mit IMAPFilter. Klingt banal? Eigentlich schon, aber in meinem bisherigen POP-Weltbild war klar, dass Nachrichten immer nur vom Server zum Client fliessen. Schoen, dass das nicht (mehr) so ist. Das nimmt Druck aus der "eigener Mailserver" Idee.. wobei ein reiner IMAP-Server waere schon was tolles, dann koennte ich mir offlineimap auch sparen und auf eine reine imapfilter Loesung setzen. Hach... Der zweite Punkt, der mich im RFC ueberrascht hat, war der ganz selbstverstaendliche Umgang mir Nicht-Mail-Usecases: > For example, implementations which offer access to USENET > newsgroups MAY use the "#news" namespace to partition the > USENET newsgroup namespace from that of other mailboxes. > Thus, the comp.mail.misc newsgroup would have a mailbox > name of "#news.comp.mail.misc", and the name > "comp.mail.misc" can refer to a different object (e.g., a > user's private mailbox). Heute wuerde man wohl sicherlich auch Feeds dazu zaehlen, so nahe wie sich Atom-Entries und Mails eigentlich sind -- dazu habe ich ja schonmal was geschrieben. Was uns wieder zu dem leidigen Thema fuehrt: Prinzipiell stimmt die Richtung von rss2mail, aber die Implementierung ist grottig. Das muesste "man" mal aendern... [1] https://github.com/lefcha/imapfilter [2] http://www.djcbsoftware.nl/code/mu/ [3] http://notmuchmail.org/