Subject: Re: Umstellung auf IMAP - IMAPFilter
From: Boris Kraut <[email-masked]>
To: undisclosed-recipients: ;
Date: Wed, 29 Feb 2012 04:02:43 +0100

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/