Doorzoekbaar mailarchief opbouwen op basis van Qmail maildir

[Verwijderd]

Aangezien ik mijn computers vrijwel allemaal opnieuw heb geïnstalleerd dit jaar, altijd verschillende computers heb gebruikt, en nu zo'n 15 losse pst-files in back-ups heb, heb ik nauwelijks meer een goed en doorzoekbaar e-mail archief.

Tevens is sinds installatie van ESET NOD32 ALLES in mijn IMAP-archief voorzien van een hele lelijke anti-spam signature in elke e-mail die ooit ontvangen en verzonden is. Daarbij zijn de onderwerpregels en bodies helaas sindsdien ook niet meer synchroon.

Gelukkig heb ik altijd mijn inkomende e-mail door laten sturen naar een backup mailbox, dus kan ik dat gewoon gebruiken voor het opnieuw opbouwen van een e-mail archief. We zijn gestopt met het gebruiken van een domein, waar heel veel belangrijke e-mail overheen is gegaan.

Gezien ik vaak foutmeldingen in Outlook kreeg, dat een verzonden bericht niet opgeslagen kon worden in de 'verzonden items' IMAP box, ben ik die waarschijnlijk wel kwijt. Of ik moet ze allemaal uit de pst-bestanden importeren zonder risico op dubbelen.

Het werkt nu via Horde en Qmail, maar dat is ENORM traag en loopt vrijwel altijd vast. Komt ook omdat het aantal mails wel 100K+ is. Ik ben momenteel een tarball aan het maken van de /var/qmail/mailnames/domain.tld directory en op zoek naar een oplossing om mijn e-mail archief van de laatste 7 jaar goed doorzoekbaar te maken!

Hoe kan ik 10GB e-mail makkelijk laten doorzoeken? Overpompen naar Gmail lijkt me echt onrealiseerbaar, verder zouden we over het limiet van 7.4GB webruimte komen (alvorens toepassen van filtering).

Ik wil graag alles op een prettige manier kunnen doorzoeken. Er is wel een budget, maar om Google Apps for Domains voor €49,- per jaar te gebruiken, dat vind ik niet echt een 'mooie' oplossing. Verder zou ik, als ik een jaarlijks terugkerende investering moet maken, liever investeren in iets waar ik zelf ook nog iets aan heb voor andere e-mail adressen.

Een oplossing op basis van Linux server-side zou ik trouwens het prettigst vinden. Windows Server zou eventueel ook een optie zijn.

[ Voor 4% gewijzigd door Verwijderd op 16-02-2010 03:01 ]

[Sir Isaac]

Een IMAP server op de Maildir moet kunnen. Ik ken Horde niet, dus weet niet waarom dat bij jou zo traag kan zijn. Zelf gebruik dovecot, en daar ben ik zeker tevreden over: simpele configuratie, behoorlijk snel, ook op een niet zo'n snelle server.
Maar die 10 Gb moet je wel goed onder verdelen. Mijn inbox heeft op dit moment 3000+ berichten, en dat merk je wel, vooral client side. (mijn mail client is evolution.)

[smesjz]

Qmail is een SMTP-server en geen IMAP-server. De problemen met traagheid en foutmeldingen die je noemt hebben betrekking op je IMAP-server en niet op Qmail.

Ook een IMAP-server als Dovecot of Courier kan prima overweg met de bestaande Maildir structuur, maar het is vooral interessant om te weten waarom ie vast loopt. I.p.v. Horde kan je ook Roundcube overwegen, het heeft dan wel veel minder features maar het is vrij eenvoudig om te zetten en biedt een mooie vergelijking voor performance.

Je zou met strace (en familiy) eens kunnen kijken waarom je IMAP-server zo traag is. Misschien is de I/O wel de bottleneck...

[Tim]

Ikzelf gebruikt Dovecot in combinatie met Thunderbird 3. Thunderbird houd een lokale geïndexeerde kopie bij van alle IMAP berichten en is daarom heel snel met zoeken. De grootste folder is 2Gb, bevat 3500 berichten en opent zonder vertraging.
Email komt binnen op Gmail en wordt dan overgeheveld naar mijn server met een eigen scriptje (maar fetchmail of iets dergelijks kan natuurlijk ook).

Overigens heb ik kort geleden ook verschillende accounts samengevoegd, en daarbij heb ik een Thunderbird plugin gebruikt om alle dubbele berichten te filteren.

[Verwijderd]

Ik had enorm gehoopt dat het mogelijk zou alle e-mail via POP3 over te hevelen naar 'Gmail', maar de foutmelding is: "There are too many messages on the other server. Please delete some mail from your other account, or move it out of the inbox.". Het maakt niet uit wat ik aan of uit vink.

Volgende week hang ik een Xeon-server op in het datacentrum. Ik zou een VPS server kunnen configureren en hierop Dovecot met Postfix installeren, maar ik betwijfel of dit sneller is dan mijn huidige Horde/Qmail/Courier-Imap setup. Bij een zoekfunctie zal de meeste zoekwinst namelijk ook behaald worden door de headers die gewoon op mijn computer staan en de server zou via webmail gewoon een heel 8GB archief door moeten gaan, wat niet erg handig is als je alleen op onderwerp zoekt.

De huidige hardware is enorm goed en de IO is ook nog erg snel (getest via HDParm), daar zal het ook niet aan liggen. Op het moment overweeg ik zelfs een Exchange oplossing, misschien is deze wel in staat om uitstekende snelle zoekfuncties aan te bieden via Outlook Web Access.

[smesjz]

Verwijderd schreef op dinsdag 16 februari 2010 @ 18:10:
Ik had enorm gehoopt dat het mogelijk zou alle e-mail via POP3 over te hevelen naar 'Gmail', maar de foutmelding is: "There are too many messages on the other server. Please delete some mail from your other account, or move it out of the inbox.". Het maakt niet uit wat ik aan of uit vink.

Door het aan/uit vinken van Gmail settings krijg je echt niet opeens minder mails op je eigen POP3 server. Misschien maar even een tijdelijke maildir aanmaken en daar wat mails naar toe gooien.

Volgende week hang ik een Xeon-server op in het datacentrum. Ik zou een VPS server kunnen configureren en hierop Dovecot met Postfix installeren, maar ik betwijfel of dit sneller is dan mijn huidige Horde/Qmail/Courier-Imap setup. Bij een zoekfunctie zal de meeste zoekwinst namelijk ook behaald worden door de headers die gewoon op mijn computer staan en de server zou via webmail gewoon een heel 8GB archief door moeten gaan, wat niet erg handig is als je alleen op onderwerp zoekt.

De huidige hardware is enorm goed en de IO is ook nog erg snel (getest via HDParm), daar zal het ook niet aan liggen. Op het moment overweeg ik zelfs een Exchange oplossing, misschien is deze wel in staat om uitstekende snelle zoekfuncties aan te bieden via Outlook Web Access.

Server-side search kan prima met Dovecot aangezien deze gewoon mail kan indexeren, zie ook http://wiki.dovecot.org/Plugins/FTS en bijbehorende opmerkingen over wanneer de index wordt opgebouwd.

Je kan er zelfs Solr achter hangen voor het zoeken maar volgens mij voldoet Squat ook wel.

Misschien dat het tunen van de indexen nog veel winst kan behalen.

Gegevens van hdparm zijn leuk, maar redelijk zinloos als je kijkt naar een filesystem met 30k aan kleine files. Dan komt het eerder neer op filesystem tuning, staar je niet blind op hdparm.

Ik denk dat je een hele acceptable performance kan behalen als je er wat tijd in stopt. Om meteen Exchange + OWA uit te rollen is ook wel redelijk radicaal.

[Verwijderd]

smesjz schreef op dinsdag 16 februari 2010 @ 18:37:
Door het aan/uit vinken van Gmail settings krijg je echt niet opeens minder mails op je eigen POP3 server. Misschien maar even een tijdelijke maildir aanmaken en daar wat mails naar toe gooien.

In de Google help stond het volgende advies: "If you encounter this error, we recommend that you uncheck Leave a copy of retrieved messages on the server." Ik doelde op die optie. Ik heb natuurlijk een tar-backup gemaakt van de maildirectory, voor als dit niet goed gaat.
http://mail.google.com/su...er.py?hl=en&answer=29592#

smesjz schreef op dinsdag 16 februari 2010 @ 18:37:
Server-side search kan prima met Dovecot aangezien deze gewoon mail kan indexeren, zie ook http://wiki.dovecot.org/Plugins/FTS en bijbehorende opmerkingen over wanneer de index wordt opgebouwd.

Je kan er zelfs Solr achter hangen voor het zoeken maar volgens mij voldoet Squat ook wel.

Misschien dat het tunen van de indexen nog veel winst kan behalen.

Gegevens van hdparm zijn leuk, maar redelijk zinloos als je kijkt naar een filesystem met 30k aan kleine files. Dan komt het eerder neer op filesystem tuning, staar je niet blind op hdparm.

Ik denk dat je een hele acceptable performance kan behalen als je er wat tijd in stopt. Om meteen Exchange + OWA uit te rollen is ook wel redelijk radicaal.

Ik wist verder niet dat Solr/Lucene ook geschikt was voor het doorzoeken van e-mail op basis van een index. Ik zal zeker eens kijken in welk opzicht Dovecat/FTS/Solr aanzienlijk sneller is dan mijn huidige Horde set-up die enorm langzaam is.

Maar Solr/Lucene, dat werkt toch niet echt met een grafische gebruikersinterface? Hoe kan ik dan zoeken naar e-mails via zo'n oplossing? Via command-line?

[Wolfboy]

Solr is een webservice die om lucene heen gebouwd is, je kan daarmee gewoon via een webinterface zoeken in je mail.

Wat betreft het indexeren, sinds Solr 1.4 zijn er diverse import scripts beschikbaar dus je zou Solr waarschijnlijk gewoon je hele directory direct kunnen laten uitlezen

Het indexeren van een enkel item duurt relatief lang met Solr/Lucene, maar het zoeken is extreem snel en het indexeren van grote hoeveelheden items tegelijk is ook best snel.

[TwOkkie]

Gegevens van hdparm zijn leuk, maar redelijk zinloos als je kijkt naar een filesystem met 30k aan kleine files. Dan komt het eerder neer op filesystem tuning, staar je niet blind op hdparm.

Precies. Hoe houdt NTFS zich onder directories met honderdduizenden kleine bestandjes? Ik heb ooit eens een ext2 machine op z'n plaat zien gaan op veel te hoge seek-times in zo'n directory. In die tijd was ReiserFS daar veel beter in vanwege het gebruik van BTree's in de directory-index. Of praat ik nou onzin? We hebben er toen voor gekozen om de directory-structuur anders op te bouwen en niet om een ander FS te kiezen. Nu zou ik opnieuw moeten kijken wat het beste is voor de situatie.

In ieder geval kan de keuze van je filesystem (en daarna tuning) zeker belangrijk zijn in de performance. Als het meer dan 20 seconden duurt om 1 mailtje aan een archief toe te voegen (zoals ik destijds constateerde) heb je al gauw een probleem. Mocht je voor windows kiezen dan is het filesystem al voor je gekozen...

[ Voor 11% gewijzigd door TwOkkie op 16-02-2010 19:44 ]

[Verwijderd]

Mensen, ik ben al een stuk verder en het ziet er inderdaad naar uit dat er in combinatie met Dovecot inderdaad erg interessante opties zijn!

Opties waarbij zoekopdrachten in een zulke hoeveelheid e-mail mogelijk zijn in enkele seconden werken natuurlijk allemaal met indexeringsbestanden, dus ik vraag me af of het filesystem erg veel invloed heeft. Ik zal dit voor de zekerheid zeker controleren voor de daadwerkelijke deployment.

[smesjz]

Verwijderd schreef op dinsdag 16 februari 2010 @ 18:55:
Ik wist verder niet dat Solr/Lucene ook geschikt was voor het doorzoeken van e-mail op basis van een index. Ik zal zeker eens kijken in welk opzicht Dovecat/FTS/Solr aanzienlijk sneller is dan mijn huidige Horde set-up die enorm langzaam is.

Maar Solr/Lucene, dat werkt toch niet echt met een grafische gebruikersinterface? Hoe kan ik dan zoeken naar e-mails via zo'n oplossing? Via command-line?

Zo ver ik lees communiceert Dovecot met Solr via HTTP voor het laten indexeren van de mails. Als jij vervolgens via IMAP zoekt (server-side that is) zal Dovecot Solr aanspreken voor het daadwerkelijk zoeken.

Buiten dat kan je natuurlijk ook een andere app gebruiken die tegen Solr babbelt en de XML zelf interpreteert zodat je ook zelf highlighting kan gebruiken. Ongetwijfeld zijn hier ook wel open source tools van.

Ik weet niet in hoeverre je ook Solr's termen directory kan gebruiken bij het zoeken via Dovecot, dus of term boosten en fuzzy zoeken werkt zul je zelf moeten uitproberen. Ongetwijfeld vind je op de Dovecot mailinglists of wiki hier meer informatie over.

Het volledige bericht zul je toch via 'FETCH' uit IMAP moeten trekken omdat je anders ook message flags mist (replied,forwarded). Deze worden zo ver ik weet niet geindexeerd.

Maar ik zou me voorlopig beperken tot zoeken via webmail, waarbij Dovecot dus tegen Solr praat. Dat laatste hoeft alleen als Squat niet volstaat.

[TwOkkie]

Verwijderd schreef op woensdag 17 februari 2010 @ 02:30:
Opties waarbij zoekopdrachten in een zulke hoeveelheid e-mail mogelijk zijn in enkele seconden werken natuurlijk allemaal met indexeringsbestanden, dus ik vraag me af of het filesystem erg veel invloed heeft. Ik zal dit voor de zekerheid zeker controleren voor de daadwerkelijke deployment.

Als alles eenmaal geïmporteerd en geïndexeerd is, zal je filesystem alleen nog van invloed zijn op het moment dat mailtjes geopend of toegevoegd worden. Als je dan 10 seconden moet wachten voordat je lineaire directory doorgezocht is naar die ene entry of dat eerstvolgende lege plekje, maakt je fs wel degelijk uit.

Mijn kennis van filesystems is niet helemaal up-to-date, dus ik hou het even bij deze tip. In de tijd dat ik dit probleem tegenkwam, was Reiserfs nog in ontwikkeling en niet rijp voor productie. Op dit moment is Reiserfs aan alle kanten ingehaald door de ontwikkelingen. XFS, JFS en Ext4 zul je zelf moeten onderzoeken.

[ Voor 9% gewijzigd door TwOkkie op 17-02-2010 13:12 ]