- dovecot - dovecot.org

[dovecot] today cvs
by Farkas Levente 25 Apr '03

25 Apr '03

hi, the today cvs has a new bug during configure (both on rh 8.0 and rh 9): ----------------------------------- checking size of long long... 8 checking type of off_t... long long ./configure: line 12009: syntax error near unexpected token `else' ./configure: line 12009: `else' ----------------------------------- -- Levente "Si vis pacem para bellum!"

3 3

[dovecot] Using on AIX
by Adam Lackorzynski 25 Apr '03

25 Apr '03

Hi, I'm trying to install dovecot-0.99.9-test6 with gcc-3.2.2 under AIX (4.3.3) and found some problems. First, I need to define _XOPEN_SOURCE_EXTENDED to 1 in src/lib/fdpass.c and src/auth/mycrypt.c or undefine it to compile successfully. When I define _XOPEN_SOURCE_EXTENDED to 1, I get the following error while connecting: dovecot: Apr 21 17:56:44 Info: Dovecot starting up imap-login: Apr 21 17:57:19 Fatal: fd_send(5) failed: Bad file number dovecot: Apr 21 17:57:19 Error: child 39504 (login) returned error 89 This happens after a successful authentication (i.e. wrong authentications are correctly denied). Something similar happens if I define _XOPEN_SOURCE to 500 in both files. When I undefine the _XOPEN_SOURCE_EXTENDEDs without modifying the original _XOPEN_SOURCE defines, it seems to come further: imap-login: Apr 21 18:24:23 Info: Login: xxx [xxx.xxx.xxx.xxx] imap(xxx): Apr 21 18:24:23 Panic: file mail-index-data.c: line 439 (mail_index_data_append): assertion failed: ((size & (MEM_ALIGN_SIZE-1)) == 0) dovecot: Apr 21 18:24:23 Error: child 95800 (imap) killed with signal 6 but this doesn't work either. Anything other I could try? Thanks, Adam -- Adam adam(a)os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/

2 17

[dovecot] index files
by Farkas Levente 23 Apr '03

23 Apr '03

hi, what's happend if I change the index type ie. change it back to the default # mail_cache_fields while before I use mail_cache_fields = and restart dovecot? in this case at the next login the index files are regenerated? -- Levente "Si vis pacem para bellum!"

2 6

[dovecot] errors
by Farkas Levente 23 Apr '03

23 Apr '03

hi, in the yesterday cvs, an internal error in the imap message appear in the client side and in the maillog: ------------------------- Apr 16 10:01:42 red imap(zgabor): Corrupted index file /home/zgabor/Maildir/.Lists.Bugtraq/.imap.index: Invalid seen messages count (284 < 285) Apr 16 10:01:43 red imap(zgabor): Corrupted index file /home/zgabor/Maildir/.Lists.Linux/.imap.index: Invalid seen messages count (191 < 192) Apr 16 10:01:44 red imap(zgabor): Corrupted index file (in-memory index for /home/zgabor/Maildir/.Lists.Linux): Filename mismatch for UID 1: 1050448183.2238_1.red.int.bppiac.hu vs 1050321835.21498_1.red.int.bppiac.hu ------------------------- and this version is _very_ slow!!! -- Levente "Si vis pacem para bellum!"

3 6

[dovecot] quotas again
by Mark E. Mallett 21 Apr '03

21 Apr '03

A couple of notes about quotas-- I know this has been brought up before but the negative effects that occur when a user is over quota are still disconcerting. Ideally it would be best if a user could at least delete mail when in an over-quota condition. One would think it would be enough to simply ignore errors creating the index files (and use an in-memory index). However, another problem is that the mere renaming of a file from the new/ directory to the cur/ directory can cause an over-quota error if the cur/ directory has to be expanded. We see these errors in the maillog followed by an "I/O leak" message, e.g.: Apr 21 07:42:26 mercury mem[10059]: pop3(someuser): maildir build: rename(/users/3a/someuser/Maildir/new/1049919998.23875.mercury.mv.net, /users/3a/someuser/Maildir/cur/1049919998.23875.mercury.mv.net) failed: Disc quota exceeded Apr 21 07:42:26 mercury mem[10059]: pop3(someuser): I/O leak: 0x807361c (1) Apr 21 07:42:26 mercury mem[10059]: pop3(someuser): I/O leak: 0x804a1b8 (0) and then we get a report about the server dropping the connection. BTW we seem to see quite a lot of these "I/O leak" messages in other situations too, and I think it started with the test5 release (but I am not absolutely sure). What does this mean? Yours, mm

3 4

[dovecot] 0.99.9-test6
by Timo Sirainen 21 Apr '03

21 Apr '03

Just two fixes: - dovecot-uidlist file is now assumed to be changed if it's modify time is changed. before we relied on inode changing which isn't fully reliable. - mbox dotlocks sometimes incorrectly thought someone else had overridden them Known problems that I should fix: - mbox: we don't necessarily notice message flag changes by external programs (or another dovecot without index files). It's because we don't always reparse the whole mbox file when it has changed. I think I'll have to add some X-IMAP-Changelog header which describes what changes were made by other Dovecot processes. If the change isn't listed in that header, we'll fallback to reparsing the whole file. Although that's still a bit annoying since MTA just appends the new mails, we wouldn't really need to reparse the whole file then, just the new mails. - I should use link() instead of relying on O_EXCL which doesn't work with NFSv2 (or Linux's NFSv3 client). - .subscriptions and .customflags files still aren't NFS-safe

1 0

[dovecot] Folders with mail and subfolders
by Keith Edmunds 21 Apr '03

21 Apr '03

I have a maildir hierarchy (built originally with Courier-IMAP) where some folders contain both email and subfolders. Using Dovecot I cannot see the mail in the top folders: I can only see the subfolders. Is this an RFC restriction or a Dovecot restriction? If the latter, is it planned to change? Otherwise: just started using Dovecot, and I'm very impressed with the speed of it. Thanks! Keith

4 4

[dovecot] 0.99.9-test5
by Timo Sirainen 21 Apr '03

21 Apr '03

- Fixed startup crashing in POP3 server - Several fixes to opening index file which needs to be rebuilt. Before it didn't always rebuild the index but just fallbacked to using only memory, and that could have been quite slow since all mails in the mailbox were opened and parsed. - If there's nothing in mail_cache_fields, index rebuilding doesn't open the file anymore. This should make in-memory indexes a lot faster than before, but it could also mean some performance hits later. If client wants to fetch all mails from the mailbox, the same thing has to be done anyway.. This needs more thinking actually what is the optimal behaviour. - Support /etc/shadow-like file for passdb.

3 3

[dovecot] Message with lots of attachments breaks Dovecot
by Tim Hunt 21 Apr '03

21 Apr '03

I have a message with over a 1000 embedded attachments(!), and it breaks Dovecot. The issue appears to be buffer management. There is some logic in the function message_part_deserialize_part that seems to assume that the message part structure is in a contiguous array, but that doesn't seem to be the case. I haven't been able to figure out enough about the memory management in Dovecot to fix the problem. Below is a horrible workaround that just allocates a lot more memory for the message part array, so that it remains contiguous. *** mail-index-update.c.orig Wed Mar 26 10:41:55 2003 --- mail-index-update.c Sun Apr 20 16:53:45 2003 *************** *** 498,504 **** if (cache_fields & DATA_FIELD_MESSAGEPART) { t_push(); ! buf = buffer_create_dynamic(data_stack_pool, 2048, (size_t)-1); message_part_serialize(part, buf); --- 498,504 ---- if (cache_fields & DATA_FIELD_MESSAGEPART) { t_push(); ! buf = buffer_create_dynamic(data_stack_pool, 51200, (size_t)-1); message_part_serialize(part, buf);

2 1

[dovecot] Patch for zero content-length
by Tim Hunt 21 Apr '03

21 Apr '03

mbox-index.c uses a zero content length as a flag for an invalid Content-Length: header. Unfortunately zero is also a valid value for Content-Length. The patch below attempts to address the problem. *** mbox-index.h.orig Tue Apr 15 09:04:02 2003 --- mbox-index.h Sun Apr 20 11:42:12 2003 *************** *** 19,24 **** --- 19,25 ---- struct istream *input; uoff_t content_length; int set_read_limit; + unsigned int content_length_good:1; }; int mbox_set_syscall_error(struct mail_index *index, const char *function); *** mbox-index.c.orig Mon Mar 24 05:52:44 2003 --- mbox-index.c Sun Apr 20 12:41:16 2003 *************** *** 264,277 **** start_offset = ctx->input->v_offset; i_stream_set_read_limit(ctx->input, 0); ! end_offset = start_offset + ctx->content_length; ! if (ctx->content_length == 0 || !mbox_verify_end_of_body(ctx->input, end_offset)) { ! if (ctx->content_length != 0) i_stream_seek(ctx->input, start_offset); mbox_skip_message(ctx->input); end_offset = ctx->input->v_offset; ctx->content_length = end_offset - start_offset; } i_stream_seek(ctx->input, start_offset); --- 264,280 ---- start_offset = ctx->input->v_offset; i_stream_set_read_limit(ctx->input, 0); ! end_offset = start_offset; ! if ( ctx->content_length_good ) ! end_offset += ctx->content_length; ! if (!ctx->content_length_good || !mbox_verify_end_of_body(ctx->input, end_offset)) { ! if (ctx->content_length_good ) i_stream_seek(ctx->input, start_offset); mbox_skip_message(ctx->input); end_offset = ctx->input->v_offset; ctx->content_length = end_offset - start_offset; + ctx->content_length_good = TRUE; } i_stream_seek(ctx->input, start_offset); *************** *** 301,311 **** --- 304,316 ---- strcasecmp(hdr->name, "Content-Length") == 0) { /* manual parsing, so we can deal with uoff_t */ ctx->content_length = 0; + ctx->content_length_good = TRUE; for (i = 0; i < hdr->value_len; i++) { if (hdr->value[i] < '0' || hdr->value[i] > '9') { /* invalid */ ctx->content_length = 0; + ctx->content_length_good = FALSE; break; }

1 0