similar to: (message_parse_header_next): assertion failed:, +(IS_LWSP(line->value[0])) 1.1beta14

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

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

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

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

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

I've tried to stress test dovecot 1.1.4 with imaptest for days without any assertion failure or crash. Just some "got too little data" messages. So far it's the most stable 1.1.x version. Today a user got this imap segfault with vanilla 1.1.4 (I don't know if it's something you have already fixed in current tree). The user didn't complain of anything, I've just

I have some folders with a good amount of spam. While demonstrating full text search to a user, we found a folder that would crash dovecot while doing a fts. While splitting up the mailbox to narrow it down, I found there are a good number of messages in that folder that all made it crash in the same manner. I figured I'd narrow down a single one, get that fixed, then retest the rest. I

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

Browsing through the source code to find some properties of deliver I stuck here: --- dovecot-1.2.rc3/src/lib-mail/message-header-parser.c.orig 2009-01-07 19:33:26.000000000 +0100 +++ dovecot-1.2.rc3/src/lib-mail/message-header-parser.c 2009-04-23 09:53:08.000000000 +0200 @@ -284,7 +284,7 @@ Exception to this is if the value consists only of

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

I found imap core in coredump dir: (gdb) bt #0 0x00000000004abdea in message_parse_header_next (ctx=0x79c150, hdr_r=0x7fffffffe478) at message-header-parser.c:114 #1 0x00000000004a8193 in read_header (mstream=0x795330) at istream-header-filter.c:162 #2 0x00000000004a84e7 in i_stream_header_filter_read (stream=0x795330) at istream-header-filter.c:288 #3 0x00000000004bc216 in i_stream_read

Hi, I ran into a problem wherein my mail client (RoundCube) would not display a message from a Dovecot IMAP server (claiming that the message had no content). The raw source of the message looked fine, but the body structure returned by Dovecot only had the first text/plain part and not the alternative text/html part. The message looks like: ... headers removed ... X-Mailer: Lotus

We're encountering a crash when proxying to an Exchange server: Mar 30 10:40:47 mproxy dovecot: imap-login: Login: user=<xxxbxxx>, method=PLAIN, rip=10.39.76.71, lip=141.42.206.11, mpid=18556, TLS, session=<H98xGkAvfvMKJ0xH> Mar 30 10:40:49 mproxy dovecot: imap(xxxbxxx): Fatal: block_alloc(134217728): Out of memory Mar 30 10:40:49 mproxy dovecot: imap(xxxbxxx): Error: Raw

I haven't seen this before 1.1b16, it happened to two users today while they were searching using fts. Feb 18 16:41:36 hill dovecot: IMAP(username): file buffer.c: line 288 (buffer_set_used_size): assertion failed: (used_size <= buf->alloc) Feb 18 16:41:36 hill dovecot: child 53560 (imap) killed with signal 6 I can probably narrow it down to an example mail if needed. GNU gdb 6.1.1

Hi, I compressed a folder with the following script: ... for i in *.*.*; do file $i | grep bzip2 >/dev/null 2>&1 if [ $? -ne 0 ]; then echo "Compress: $i" cat "$i" | bzip2 -9 > ../tmp/$i if [ $? -eq 0 ]; then mv ../tmp/$i $i fi else

Hi all, I just had a panic with dovecot 1.1.6, two days after replacing 1.0.15 with it in production. Here are the logs immediately preceding the panic, I think they're related. It seems the user connected simultaneously from two different clients, from his own computer and a webmail running on the server, then manipulated mail folders on one side, and logged out. The panic occurred 3

I have a situation where if a user is over quota and sending through postfix I get an error, now this error only happens if the user is over quota, otherwise it works with no problem. However if sending using /usr/local/libexec/dovecot/dovecot-lda it works every time even if overquota, any ideas? I just can't seem to figure this one out. TIA, Paul Using mail command Dec 21

Hi, I have one user constantly crashing with: Core was generated by `dovecot/imap'. Program terminated with signal 11, Segmentation fault. #0 0x007e5b7c in mailbox_list_notify_next (notify=0x0, rec_r=0xbfee8f00) at mailbox-list-notify.c:28 28 return notify->list->v.notify_next(notify, rec_r); (gdb) bt #0 0x007e5b7c in mailbox_list_notify_next (notify=0x0,

Greetings, I recently upgraded our server from Dovecot 1.0.14 to 1.1.1. I am building using the FreeBSD ports system, so nothing is custom aside from the flags set there. dovecot fell down a few days after the update with: pid 1823 (imap), uid 1000: exited on signal 11 the mail log shows: Jul 4 14:36:07 hostname dovecot: IMAP(username): Corrupted index cache file

Hi, got the following with beta4 while uploading messages from a local mbox to the dovecot server in my LAN, tested with mutt and sylpheed, the same action works with 1.2.11: Mar 29 13:42:46 [dovecot] imap(juergen): Panic: stream doesn't support seeking backwards Mar 29 13:42:46 [dovecot] imap(juergen): Raw backtrace: /usr/lib/dovecot/libdovecot.so.0 [0xb76b7ec4] ->