similar to: crash with fts_squat on an identified email

I noticed the following this week. No idea how long its been happening because I have not tested deleting folders hardly at all. Steps to reproduce: 1. Create a folder "NewFolder", click on it in thunderbird so an index dir is created: ls -ldi Maildir/.NewFolder/ 1504062 drwx------ 5 mcdouga9 egrstaff 4096 Nov 16 19:44 Maildir/.NewFolder/ ls -ldi

Two nights ago I took a leap and extended my testing of dovecot 1.1 by replacing 1.0 for the approx 15 users I had on 1.0. At that time I also for the first time tried dovecot 1.1 in a load balanced 2 server configuration with indexes on NFS. I was hoping I did this right, using the mail_nfs params and 1.1 so fchown etc would flush the access cache, but I am getting a number of messages and

When I was initially testing dovecot 1.1b2,3 I had ACLs turned on and encountered this problem below. I had them turned off until now, I'll need to have ACLs working before I can widen testing. I'm not sure how to make "env MAIL=maildir:~/Maildir gdb /tmp/imap" load the ACL plugin so I assume that is why it does not crash; not getting any log either from that, maybe I made a

I have up to 4 servers that will run dovecot behind a load balancer, which means the same user might be accessing the same mailbox from multiple servers, and it seems like dovecot doesn't like multiple access to the dovecot indexes for the one user since I currently have them stored in a nfs home directory. Is this a bad thing? Must I keep a seperate index location per server? Just today

I noticed these happen when one of my users searches his Trash folder which he doesn't empty. He uses thunderbird and it is reproducable. Feb 5 22:47:39 boomhauer dovecot: IMAP(username): file message-header-parser.c: line 350 (message_parse_header_next): assertion failed: +(IS_LWSP(line->value[0])) Feb 5 22:47:41 boomhauer dovecot: child 8022 (imap) killed with signal 6 Feb 5

I don't know how this happened. I'm not sure if there is a coredump somewhere because I don't know what user, and I have nothing for 'root' or 'dovecot'. Any advice, or should I make all my coredumps go to a central writable directory so I have better chance of catching it if it happens again? Is it maybe from someone connecting to postfix and causing a SMTP-AUTH

This happened a while back, I was running 1.1rc3 up until today so I have no idea if it would have an effect. Sorry if its something that has been fixed. The error below was repeated many many times, I deleted the index so the user would stop getting disconnected (although I didn't hear any complaints). I have not seen this happen repeatedly in this manner to any other user yet. Apr 15

Version: 1.1.1 OS: FreeBSD 7.0-STABLE amd64 I have only seen this happen twice so far. I do not know what the two users were doing to cause it. Jun 26 17:23:26 hill dovecot: IMAP(userA): Invalid transaction log size (32812 vs 32920): /home/userA/Maildir/dovecot/private/indexes/.Deleted Messages/dovecot.index.log Jun 26 17:23:26 hill dovecot: IMAP(userA): Invalid transaction log size (32812

In the past I dabbled with the imap quota plugin with the fs backend because I wanted to report usage to my users (not limit them). At the time, the quota plugin would make dovecot crash when trying to write to a folder (I can bring up this report if needed). However, in a later beta of dovecot 1.1 I tried quota again but I cannot get it to report any results. I've been wanting to use

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-07:10.gtar Security Advisory The FreeBSD Project Topic: gtar directory traversal vulnerability Category: contrib Module: contrib_tar Announced:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-07:10.gtar Security Advisory The FreeBSD Project Topic: gtar directory traversal vulnerability Category: contrib Module: contrib_tar Announced:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-06:26.gtar Security Advisory The FreeBSD Project Topic: gtar name mangling symlink vulnerability Category: contrib Module: contrib_tar

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-06:26.gtar Security Advisory The FreeBSD Project Topic: gtar name mangling symlink vulnerability Category: contrib Module: contrib_tar

Hello people, me again ... Just an FYI this time, I think: 0[209]1 sunray1:/contrib > gtar zxf R-1.4.1.tgz tar: R-1.4.1/date-stamp: Could not create file: Permission denied gtar: Error exit delayed from previous errors 2[210]1 sunray1:/contrib > gtar zxvf R-1.4.1.tgz "R-1.4.1/date-stamp" R-1.4.1/date-stamp gtar: R-1.4.1/date-stamp: Could not create file: Permission denied gtar:

just installed dovecot with fts_squat config attached after message. When i telnet to imap server and execute by hand 1 login user password select foldername search body "someword" it works fine, and at blazing speed except first run (indexing). i already indexed everything by doveadm index offline to prevent server overload if multiple users (after i tell them) will try fulltext

Hi all! I've got problem with results returned by doveadm fetch. The are random and incorrect. I'll try show you: - trying to fetch emails with both: nonexistent header name and non existent value of header name: -- doveadm fetch -u user at domain uid HEADER X-Sasdasdsendasasdasdasdasaer XXtuxie |grep -c uid 0 - trying to fetch email with: non existent header name and existent value of

Hi, dovecot's imap process segfaults when I search a virtual mailbox using the fts_squat plugin. Is this supposed to work, or a known bug? I've seen some changes commited to fts_solr a couple of months ago that where supposed to fix search issues on virtual mailboxes, maybe fts_squat needs to be fixed to? log === rawlog ------ 3551 SELECT "INBOX.virtual.unseen" 3552 UID

I can confirm the report posted in http://dovecot.org/list/dovecot/2011-November/062263.html that fts_squat no longer seems to be used after moving from 2.0.16->2.1 rc 1. I don't see crash reports in the logs, just "0 messages indexed". My search test tool just does a normal IMAP SEARCH for a long non-existent string. If there's another way to trigger re-indexing in 2.1, I

Hi everyone, I have now updated to dovecot 2.3.4.1 - unfortunately the issue still persists. Can anyone help me figure out if this is due to a misconfiguration on my part or another error? Any help is greatly appreciated! Cheers Benjamin Am 14.03.2019 um 23:28 schrieb benjamin at godbersen.info: > Hi everyone, > > I am running into a problem when trying to use fts_squat in a virtual

Hi Michael, thanks for getting back to me. I understand the alternatives to squat are solr and lucene and have to be explicitly included into dovecot at compilation. Unfortunately I am not in a position to manually compile dovecot. What other option do I have to use full text search in dovecot without manually compilating my package? Thanks and cheers Benjamin Am 20.03.2019 um 20:31