similar to: New indexing code

Hi, I wonder if it's normal behaviour that indexes created in memory have long creation time. Other problem is that indexes created on nfs sometimes get crushed and I need to delete indexes in case of fetching mails ( I see mails on hd but when telnet on host and make stat I don't see any). Does version 1.1.x correct this errors ? And what is better to use : nfs or memory indexing ? Can

There are now two full text search backends in CVS HEAD: - squat: My own full text search index based on ideas from Cyrus Squat indexes. Supports substring searches. - lucene: Uses CLucene library. It should be pretty easy to add support for more backends. As I've explained a couple of times already, IMAP RFC says that searches are done by matching substrings, so the Lucene backend

Hi all, I use a local dovecot server which is synchronized with my two imap accounts using OfflineIMAP. This works very nice and is highly usable. But one thing I'd like to improve is the slow IMAP search. When I search for a string in the subjects of all messages in a mailbox using some mail client, dovecot seems to grep all the messages in there. Is there a way to let dovecot index more

I've been doing some stress testing in the last few days and fixing all the errors I saw. I'm hoping that I've finally really fixed all the index/mbox problems. So, again I think the only thing left for v1.0 is the documentation. Please test this nightly snapshot before I'll release rc27 tomorrow: http://dovecot.org/nightly/dovecot-latest.tar.gz If you've seen any of the

Sorry about the lack of replies to questions in this list. Work on the new indexing code has taken way too long, but it's finally beginning to be get near usable state. After it's fully working, I'll start being more active here again. If you're interested (as a developer, normal users shouldn't even try playing with it yet), you can checkout "newdove" module

SEARCH is probably the slowest command that Dovecot has, especially when searching texts from message bodies. There exists a lot of text search engines, but unfortunately as far as I know there exists only one that can be used with IMAP. The reason why IMAP is special is because it requires that when searching eg. "ello", it must match also mails which contain eg. word

On 2018-12-09 23:13, Timo Sirainen wrote: > On 9 Dec 2018, at 16.44, Andr? Rodier via dovecot <dovecot at dovecot.org> > wrote: >> >> Hello, >> >> I think I submitted this before, but I am not sure this has been >> addressed >> >> I am using AppArmor with Dovecot, without any issue. >> >> However, I think there is a bug in the

On Apr 7, 2017, at 3:01 AM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: >> On April 7, 2017 at 9:38 AM Timo Sirainen <tss at iki.fi> wrote: >> On 7 Apr 2017, at 2.25, Daniel J. Luke <dluke at geeklair.net> wrote: >>> >>> On Apr 6, 2017, at 1:33 PM, Timo Sirainen <tss at iki.fi> wrote: >>>> Planning to release v2.2.29 on Monday.

On Apr 7, 2017, at 11:17 AM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: >> On April 7, 2017 at 6:00 PM "Daniel J. Luke" <dluke at geeklair.net> wrote: >> On Apr 7, 2017, at 3:01 AM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: >>>> On April 7, 2017 at 9:38 AM Timo Sirainen <tss at iki.fi> wrote: >>>> On 7 Apr 2017, at 2.25, Daniel

Hello all, I have a problem with an incosistent mdbox: Oct 24 10:43:23 two dovecot: imap-login: Login: user=<...>, method=PLAIN, rip=..., lip=..., mpid=4977, TLS Oct 24 10:43:23 two dovecot: imap(listen at mjh.name): Error: mdbox map .../mdbox/storage/dovecot.map.index corrupted: Unexpectedly lost INBOX uid=638 map_uid=809891 Oct 24 10:43:23 two dovecot: imap(listen at mjh.name): Error:

Hi, Mailing list archives suggest that this problem has been fixed in the older versions itself but I am getting the error still while trying to doveadm index a large folder of emails. Sometimes it throws error after 30000, something 40000, the latest it gave up after 111000. But it just never completes. 111000/322080doveadm:

An embedded and charset-unspecified text was scrubbed... Name: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20070814/70b6141c/attachment-0004.pl> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dovecot-1.0-deliverfrom.patch URL:

Guys, We have a very large maildir for email auditing purposes. It's currently at 600 GB and continues to grow. Can dovecot handle this with squat indexing, or am I out of my mind? Thanks! John

> On April 7, 2017 at 6:48 PM "Daniel J. Luke" <dluke at geeklair.net> wrote: > > > On Apr 7, 2017, at 11:17 AM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > >> On April 7, 2017 at 6:00 PM "Daniel J. Luke" <dluke at geeklair.net> wrote: > >> On Apr 7, 2017, at 3:01 AM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: >

Hi Using this line in dovecot.conf (ignore linewrap) default_mail_env = mbox:%h/IMAP/:INBOX=%h/.email:INDEX=/var/cache/dovecot/%n The INBOX indexes are being built correctly in /var/cache/dovecot, but all other indexes for folders are still being built in the user's home directory. I had it working once - but it seems fragile - almost as if the config parser is sensitive to context???

Hi! I'm using Dovecot 2.1.7 on Debian Wheezy 32-bit (package version is 1:2.1.7-7+deb7u1) with maildirs. My problem is that the incremental indexing of maildirs with squat takes a very long time... I don't know if it reindexes anything, but it seems it iterates though all messages on each search query and reads them. It works fast only on successive queries within several minutes,

v2.1.2 added support for "session IDs", which is a 9 year unique identifier for that specific IMAP/POP3 connection. Initially I thought it would only be useful for tracking connections going through Dovecot proxies to backends (the session ID is forwarded), but then I thought it could be useful for everyone if auth process also logs the session ID. So I thought for v2.1.6 I'd change

A new employee started today, when logging into his new mailbox this morning during a walk-through I got a nasty server error response in Thunderbird - something I never see, DC runs smooth as butter for us. Checking the server log I see this: == snip == dovecot: Jul 09 09:38:54 Error: IMAP(xxxxxxx): Maildir /home/x/xxxxxxx/Maildir sync: UIDVALIDITY changed (1183406107 -> 1183999134)

Hi, 2 or 3 customers have reported that they are having problems downloading their mail via. POP3. I have attached the rawlogs of their transactions and the UID list at the time. Is this because I am using an incompatible UID format or is something else at fault? Deleting the UID list and indexes fixes the problem. I am using Test72. Regards Andrew -- Andrew Hutchings (A-Wing) - Linux

Hi! > RCS file: /home/cvs/dovecot/src/lib-index/mail-index.c,v > Working file: src/lib-index/mail-index.c > revision 1.268 > date: 2007-03-11 16:10:42 +0000; author: tss; state: Exp; lines: > > +8 -5; commitid: yo3GJUvm1yKgLG9s; > If we run out of disk space, move to in-memory indexes. I just saw the commit. Is this a "solution" for the Quota/FS problem, the