Moin Moin!
d.h. dann wohl, dass fetchmail die runterlädt (und sie bleiben erhalten, selbst wenn sie auf dem Mainserver gelöscht sind)
Exakt. Und es ist fetchmail sogar recht egal, ob es die Mails per POP3, IMAP4 oder ein paar exotischere Protokolle beim jeweiligen Provider einsammelt. Webmail-Support habe ich allerdings noch nicht für fetchmail gesehen.
- um dann mit Thunderbird via fetchmail (Mailserver auf localhost?) per IMAP drauf zuzugreifen? Nein, du nutzt fetchmail, um die Dinger runterzuladen und dann einen extra IMAP- (= Mail-) Server (den du nur im LAN nutzt).
Nee, Thunderbird und fetchmail sehen sich gegenseitig nicht. Auf den Mail-Server greife ich im LAN von verschiedenen Clients zu, in aller Regel von zwei Dual-Boot-Laptops, einem Dual-Boot-Desktop, und gelegentlich auch über SSH-Tunnel aus den weiten des Internet (Büro, Urlaub, ...). Auf dem Server läuft (der Bequemlichkeit wegen) zwar auch ein Thunderbird, aber der spielt KEINE besondere Rolle und arbeitet wie die Thunderbirds auf allen anderen Rechnern auch.
Welchen nutzt Du? (Linux vermutlich?).
Nö, Linux ist ein Betriebssystemkern, der kann mit IMAP nichts anfangen. (jaja, Erbsenzähler!)
Mein Server läuft unter Slackware 12.1, aber für E-Mail setze ich selbst compilierte Software ein -- schlicht und ergreifend deswegen, weil Slackware sich immer noch mit sendmail rumschlägt.
Stattdessen läuft bei mir exim, das ist trotz einer etwas sperrigen Dokumentation relativ einfach zu installieren. imapdir wird von exim nicht direkt unterstützt, aber die Zeilen
directory = /var/spool/maildir/$local_part/INBOX
maildir_format = true
unter "local_delivery:" in der exim.conf sorgen dafür, dass eingehende Mails an passender Stelle im passenden Format abgelegt werden. imapdir ist ja "nur" eine Erweiterung des maildir-Formats.
Für den Zugriff auf die Mailbox per IMAP setze ich BINCimap ein, mit einem klitzekleinen Patch, der die Mailbox nicht in $HOME, sondern in /var/spool/maildir/$USER anspricht. (Genauer gesagt im aktuellen Verzeichnis, das ein kleines Hilfsprogramm in der Aufrufkette von bincimapd auf /var/spool/maildir/$USER setzt.)
Zugriff per POP3 ist nicht möglich, die entsprechende Zeile in /etc/inetd.conf ist auskommentiert. Ich brauche POP3 nicht im LAN, notfalls könnte man aber den popa3d patchen oder gegen einen etwas flexibleren POP3-Server tauschen.
Datenfluß:
* fetchmail läuft permanent als Daemon, pollt alle paar Minuten die wichtigsten Provider und leitet Mails an den lokalen Mailserver (hier: exim) weiter.
* Der lokale Mailserver (exim) nimmt die E-Mail zur Auslieferung an einen lokalen Benutzer an
* fetchmail löscht die Mail vom Provider-Server (falls nicht anders konfiguriert)
* Der lokale Mailserver legt die E-Mail in der Mailbox des Empfängers ab (hier: neue Datei in /var/spool/maildir/$USER/INBOX/tmp, die nach Abschluß des Schreibvorgangs nach ../new verschoben wird)
* Thunderbird oder ein beliebiger anderer IMAP-Client verbindet sich mit dem inetd auf dem IMAP-Port
* inetd startet ein Wrapper-Script, dass nach diversen Prüfungen (Login, Passwort, Verzeichniswechsel) bincimapd startet (oder irgendeinen anderen IMAP-Daemon)
* bincimapd liefert Mails an den Thunderbird aus, wahlweise nur Header oder komplette Mails
* bincimapd verschiebt, löscht und flaggt Mails im Auftrag des Mail-Clients (Thunderbird)
Ich nutze fetchmail und einen IMAP-Server im LAN, und da haben mir find und grep eigentlich immer gereicht. Das Schöne am imapdir-Schema ist ja, dass jede Mail eine Datei ist.
Das klingt prima. Diese Vergurkung wie Outlook sie in der Outlook.pst macht, geht mir ziemlich auf den Senkel.
Mir will nicht in den Kopf, wie man sich freiwillig Outlook antun kann. Aber das ist eine andere Geschichte.
Thunderbird schleppt noch aus uralten Netscape-Zeiten das mbox-Format mit sich herum, eine Datei pro Folder in der Oberfläche, plus eine Index-Datei. Das Format funktioniert für größere E-Mail-Mengen leider auch nicht wesentlich besser als Outlooks Binärmüllhalde.
Allerdings mag das ext3-Dateisystem Verzeichnisse mit ein paar Zehntausend Dateien (maildir/imapdir) auch nicht sonderlich gerne.
Man kann also auf die Verzeichnisse einen stinknormale Volltext-Index für Dateien aufsetzen, den man z.B. per cron aktualisiert.
Oder eben sowas wie "Copernik Desktop Search"? Wenn das nicht immer die komplette HD scannen will sondern nur in dem einen Ornder bleibt, ist das ja erträglich u.U.
Nur dass das Ding auf dem falschen Rechner läuft -- auf dem Client. Bau es einmal auf dem Server, dann kannst Du es von allen Clients nutzen.
Auch sehr beliebt ist es, die Mails in ein RDBMS zu stopfen und dessen Such- und Index-Funktionen zu nutzen.
Äh, muss mich mir dann alles mit PHP und MyAdmin oder eigenen Suchfunktionen programmieren? Vermutlich nein. Also habichda noch eine Wissens-/Verständnislücke.
Neee, PHP willst Du nicht benutzen. So masochistisch kann man doch gar nicht sein. ;-)
Du läßt den Mail-Server seine Mails eben NICHT ins Dateisystem schreiben, sondern in eine Datenbank. Ich würde vermutlich exim überreden, das Ausliefern der Mail an ein externes Programm abzugeben. Dessen Job ist "INSERT $mail INTO $database". Das kann die Mail als einen großen Textblock in die DB packen, in eine einfache Tabelle mit einer fortlaufenden ID und einem BLOB-Feld. Das ist schnell geschrieben, sowohl der Programmcode als auch das INSERT. Dazu können noch Flags (Read, Spam, ...) kommen, und z.B. Ordner-IDs.
Der IMAP- bzw. POP3-Server wird dann durch entsprechende Programme ersetzt, die SELECT, DELETE und UPDATE auf die Datenbank machen. Für IMAP wäre es natürlich vorteilhaft, Header und Body getrennt abzulegen, damit mit der Option "Headers only" nicht immer die gesamte Mail aus der DB gefischt werden muß.
Aber beim Suchen ist dieses Format nicht wirklich toll. Also zerlegt irgendein Programm (entweder der Einlieferer oder ein periodisch laufender Helfer) jede Mail in ihre Bestandteile. Erstmal Header und Body, dann die Header nochmal in einzelne logische Zeilen, und den Body ggf. in MIME-Bestandteile (alternative Formate, Attachments). Für eine Suchoptimierung könnte man auch darüber nachdenken, den Mail-Body ggf. noch in Plain Text konvertieren. Das alles kommt in verschiedene Tabellen, verbunden über fortlaufende IDs.
Die "Suchmaschine" macht dann ein SELECT über die Header und/oder die Body und/oder die Plaintext-Teile, und liefert dann eine Mail-ID an das Thunderbird-Addon. Das kann dann dem Thunderbird mitteilen, dass die Mail 739163876 genau das ist, was Du gerade suchst.
Der Zugriff auf beide könnte dann jeweils über ein TB-Addon geschehen.
Beide heißt "RDBMS" und Imap-Ordner im Lan?
Jein. Die IMAP-Ordner sind das, was dir der TB darstellt. Das hat nicht notwendigerweise etwas mit LAN oder Verzeichnissen im Dateisystem des Servers zu tun.
Aber egal, ob Du die Mails in einem RDBMS ablegst oder in imapdir- oder mbox-Verzeichnissen, wenn man sich bei der Suchschnittstelle zwischen dem TB-Addon und dem Suchserver richtig Mühe gibt, müßte es sogar mit einem einzigen Addon funktionieren, der Suchserver kümmert sich dann darum, die Suchabfrage in Dateisystem-Suchen oder RDBMS-Suchen zu übersetzen.
Den Imap-Ornder im Lan erwische ich doch direkt über den Mailserver, den
ich dann mit "localhost" unter den Servereinstellungen adressiere, oder?
Oder.
Du greift AUSSCHLIESSLICH über IMAP auf die Mail-Verzeichnisse zu, sonst schießt Du Dir früher oder später größere Löcher in die Füße. Sprich: Du trägst im Thunderbird als Mailserver server.dein.lan ein und gibst die Mail-Storage NICHT frei, weder per NFS noch per Samba. (Und selbst obwohl paralleler Zugriff von mehreren Hosts beim imapdir-Format kein Problem sein sollte, möchte ICH nicht auf die harte Tour vom Gegenteil überzeugt werden.)
Das hat den Vorteil, dass Du Dir bei strukturellen Änderungen auf dem Server keine Sorgen über die Clients machen mußt. IMAP dient in meinem LAN deutlich länger als BINCimap und exim, vorher habe ich mich mit sendmail und UW imapd rumgequält. Nach dem Wechsel auf exim/BINCimap habe ich an den Clients exakt NICHTS umgestellt. Sollte ich irgendwann meine Mails in PostgreSQL stopfen, wird exakt das auf der Client-Seite nochmal passieren: NICHTS.
(Ich gehe sogar noch einen Schritt weiter und adressiere den Server über ein DNS-Alias imap.mein.lan statt über server.mein.lan, so könnte ich bei Bedarf sogar IMAP über einen komplett eigenen Server abwickeln.)
Das (noch rein hypothetische) TB-Addon könnte dann z.B. für die IMAP-Spezial-Suche als Default den IMAP-Host samt Benutzername und Passwort nehmen, und als Standard-Port den IMAP-Port plus einen festen Offset.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".