- dovecot - dovecot.org

[dovecot] current cvs
by Farkas Levente 16 Apr '03

16 Apr '03

hi, so after upgrade to the current cvs all of our problem disappear:-) but we don't have time to test the ssl part... although after I compile and install the new dovecot I stop it I do a -------------------- find /home/*/Maildir -name '.imap*' -exec rm {} \; find /home/*/Maildir -name 'dovecot-uidlist' -exec rm {} \; find /home/*/Maildir -name 'msgid.cache' -exec rm {} \; find /home/*/Maildir -name '.customflags' -exec rm {}\; -------------------- just to be sure that we use a fresh version and no other problem can be caused by the old index or any other cached files. this was a BIG mistake!!! we've got about 300 users and about 100 online at the same time. after a two minutes break (while I reinstall and delete) every user check his mail which casue a load about 90!!! the cpu usage 1-2% but the avarage load was 90 (curently about 0.22)! the reason was IO. we have to stop imap and wait for a while... I don't know the exact reason bu I assume dovecot is regenerate everybody's index a other cache at the same time. is there any way to reduce the possible number of IO load? this would be useful if never happend again!:-) this happend around 4:40. the output of sar -b: -------------------- 03:00:00 PM tps rtps wtps bread/s bwrtn/s 03:10:00 PM 48.18 29.19 18.99 1456.53 771.29 03:20:00 PM 41.66 25.80 15.86 1054.88 830.05 03:30:00 PM 42.64 25.67 16.97 1223.03 759.77 03:40:00 PM 44.98 31.95 13.03 1959.15 467.40 03:50:00 PM 26.68 14.63 12.05 741.48 424.12 04:00:00 PM 25.80 11.70 14.10 516.21 450.04 04:10:00 PM 59.55 34.91 24.64 1755.07 939.11 04:20:00 PM 95.98 61.15 34.83 4453.24 1563.25 04:30:00 PM 95.08 55.45 39.63 2182.22 1591.56 04:40:00 PM 168.85 145.99 22.86 11155.73 1037.25 04:50:00 PM 135.98 106.50 29.48 7908.21 1604.76 05:00:00 PM 125.87 97.65 28.23 5876.03 1060.50 05:10:00 PM 80.83 62.92 17.90 4321.82 590.19 05:20:00 PM 102.04 77.65 24.40 4907.27 1076.92 05:30:00 PM 129.04 106.58 22.46 6387.18 883.13 05:40:00 PM 89.44 73.20 16.24 4905.64 782.94 05:50:00 PM 88.23 73.16 15.06 5539.93 965.34 06:00:00 PM 92.49 72.67 19.81 5486.25 692.18 06:10:00 PM 45.24 32.82 12.42 1711.35 618.31 06:20:00 PM 42.17 28.16 14.01 960.11 622.33 06:30:00 PM 29.90 20.24 9.66 1538.27 376.17 06:40:00 PM 25.89 12.14 13.74 796.73 833.25 06:50:00 PM 20.50 4.98 15.52 264.91 993.62 07:00:00 PM 15.08 7.57 7.52 453.41 282.63 -------------------- the output of sar -d -------------------- 04:10:00 PM dev22-3 0.00 0.00 04:10:00 PM dev33-0 1.76 109.55 04:10:00 PM dev34-0 8.51 919.94 04:20:00 PM dev3-0 8.56 183.93 04:20:00 PM dev22-2 67.62 3798.02 04:20:00 PM dev22-3 0.00 0.00 04:20:00 PM dev33-0 4.80 463.81 04:20:00 PM dev34-0 15.01 1570.73 04:30:00 PM dev3-0 4.40 126.63 04:30:00 PM dev22-2 77.02 2440.08 04:30:00 PM dev22-3 0.00 0.00 04:30:00 PM dev33-0 1.94 124.80 04:30:00 PM dev34-0 11.73 1082.28 04:40:00 PM dev3-0 4.78 124.56 04:40:00 PM dev22-2 137.27 10306.18 04:40:00 PM dev22-3 0.00 0.00 04:40:00 PM dev33-0 13.50 410.44 04:40:00 PM dev34-0 13.29 1351.80 04:50:00 PM dev3-0 6.33 194.27 04:50:00 PM dev22-2 111.50 7961.44 04:50:00 PM dev22-3 0.00 0.00 04:50:00 PM dev33-0 5.64 156.51 -------------------- -- Levente "Si vis pacem para bellum!"

2 5

[dovecot] Shadow password file
by Jaime Medrano 16 Apr '03

16 Apr '03

¿Is there any way to make dovecot to take the passwords from a file with a shadow password format? I've tried with the passwd-file auth plugin, but it complains that users have uid=0 Thanks in advance, Jaime Medrano

2 3

[dovecot] it seems to unusable
by Farkas Levente 16 Apr '03

16 Apr '03

hi, is there any way to turn off the whole indexing stuff? unfortunately the system getting totaly unusable beacuase of the high load and the mail index generation is so slow that every users call the helpdask that his mail is not working (what's more in this case just click on OE again and start another mailer process:-() we've got about 100k mails which is about 10-20GB! -- Levente "Si vis pacem para bellum!"

1 0

[dovecot] pop3 coredump
by Mark E. Mallett 15 Apr '03

15 Apr '03

Hi- I was able to get a coredump out of the new pop3 (from 0.99.9-test4) by attempting to simulate the execution environment and simply running the pop3 program. Running the older pop3 from 0.99.8.1 works fine, repeatedly: % /usr/local/libexec/dovecot/pop3 quit +OK Logging out. However running the new one: % /usr/local/libexec/dovecot/pop3.new pop3(user9): Error: Corrupted index file /users/48/user9/Maildir/.INBOX/.imap.index: index.next_uid (4539) > uidlist.next_uid (4000) Segmentation fault (core dumped) It doesn't always dump core even with this message. The error message is not always the same, but it's usually what's above. Simply repeating the invocation a number of times I also saw: pop3(user9): Error: Corrupted index file (in-memory index for /users/48/user9/Maildir): Filename mismatch for UID 1: 1050440153.17005.mercury.mv.net vs 1050437948.5418.mercury.mv.net Here's some gdb output corresponding to the coredump above. -mm- Script started on Tue Apr 15 16:51:28 2003 % gdb pop3/pop3 pop3.core ... Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libiconv.so.2...done. Reading symbols from /shlib/libgcc.so.1...done. Reading symbols from /shlib/libc.so.2...done. Reading symbols from /shlib/ld-bsdi.so...done. #0 0x0 in ?? () (gdb) bt #0 0x0 in ?? () #1 0x8053439 in index_storage_init (storage=0x808f000, box=0x8080658, index=0x808c200, name=0x807660e "INBOX", readonly=0, fast=0) at index-storage.c:264 #2 0x804b8e0 in maildir_open (storage=0x808f000, name=0x807660e "INBOX", readonly=0, fast=0) at maildir-storage.c:239 #3 0x804ba20 in maildir_open_mailbox (storage=0x808f000, name=0x80765b1 "INBOX", readonly=0, fast=0) at maildir-storage.c:288 #4 0x804b1c7 in main_init () at main.c:98 #5 0x804b269 in main (argc=1, argv=0x8047d3c, envp=0x8047d44) at main.c:132 #6 0x8049cae in __start () (gdb) up 1 #1 0x8053439 in index_storage_init (storage=0x808f000, box=0x8080658, index=0x808c200, name=0x807660e "INBOX", readonly=0, fast=0) at index-storage.c:264 264 storage->callbacks->notify_no(&ibox->box, (gdb) l 259 if (!index->open(index, flags)) 260 break; 261 262 if (INDEX_IS_IN_MEMORY(index) && 263 storage->index_dir != NULL) { 264 storage->callbacks->notify_no(&ibox->box, 265 "Couldn't use index files", 266 storage->callback_context); 267 } 268 } (gdb) p index $1 = (struct mail_index *) 0x808c200 (gdb) p *index $2 = {open = 0x8054590 <maildir_index_open>, free = 0x8054abc <maildir_index_free>, set_lock = 0x805c874 <mail_index_set_lock>, try_lock = 0x805c88c <mail_index_try_lock>, set_lock_notify_callback = 0x805c8a4 <mail_index_set_lock_notify_callback>, rebuild = 0x8054f20 <maildir_index_rebuild>, fsck = 0x805de50 <mail_index_fsck>, sync_and_lock = 0x8055db4 <maildir_index_sync>, get_header = 0x805c928 <mail_index_get_header>, lookup = 0x805c968 <mail_index_lookup>, next = 0x805cac0 <mail_index_next>, lookup_uid_range = 0x805cb48 <mail_index_lookup_uid_range>, lookup_field = 0x805cc58 <mail_index_lookup_field>, lookup_field_raw = 0x805ccac <mail_index_lookup_field_raw>, cache_fields_later = 0x805cd70 <mail_index_cache_fields_later>, open_mail = 0x8054de0 <maildir_open_mail>, get_internal_date = 0x8054afc <maildir_get_internal_date>, expunge = 0x805d078 <mail_index_expunge>, update_flags = 0x8054b6c <maildir_index_update_flags>, append_begin = 0x805d3ec <mail_index_append_begin>, append_end = 0x805d4e4 <mail_index_append_end>, append_abort = 0x805d590 <mail_index_append_abort>, update_begin = 0x805f9b0 <mail_index_update_begin>, update_end = 0x805ff68 <mail_index_update_end>, update_abort = 0x8060050 <mail_index_update_abort>, update_field = 0x806022c <mail_index_update_field>, update_field_raw = 0x806025c <mail_index_update_field_raw>, get_last_error = 0x805d618 <mail_index_get_last_error>, get_last_error_text = 0x805d678 <mail_index_get_last_error_text>, data = 0x80821a0, tree = 0x80900c0, modifylog = 0x808d200, custom_flags = 0x808d100, dir = 0x8090000 "/users/48/user9/Maildir/.INBOX", filepath = 0x8090040 "(in-memory index for /users/48/user9/Maildir)", mailbox_path = 0x8082160 "/users/48/user9/Maildir", custom_flags_dir = 0x0, default_cache_fields = 0, never_cache_fields = 0, indexid = 1050439124, sync_id = 6, excl_lock_counter = 1, mbox_fd = 0, mbox_stream = 0x0, mbox_lock_type = MAIL_LOCK_UNLOCK, mbox_dotlock = { dev = 0, ino = 0, mtime = 0}, mbox_lock_counter = 0, mbox_sync_counter = 0, mbox_size = 0, mbox_dev = 0, mbox_ino = 0, uidlist_dev = 18875392, uidlist_ino = 1835546, maildir_lock_fd = -1, fd = -1, error = 0x0, mmap_base = 0x20073000, mmap_used_length = 264, mmap_full_length = 1608, header = 0x20073000, lock_type = MAIL_LOCK_EXCLUSIVE, file_sync_stamp = 1050438868, first_recent_uid = 1, lock_notify_cb = 0x8053238 <lock_notify>, lock_notify_context = 0x808c400, set_flags = 0, set_cache_fields = 0, anon_mmap = 1, opened = 0, rebuilding = 0, mail_read_mmaped = 0, inconsistent = 0, nodiskspace = 0, index_lock_timeout = 0, allow_new_custom_flags = 0, mailbox_readonly = 0, mailbox_lock_timeout = 0} (gdb) p storage $3 = (struct mail_storage *) 0x808f000 (gdb) p *storage $5 = {name = 0x8076805 "maildir", hierarchy_sep = 46 '.', create = 0x804b2c0 <maildir_create>, free = 0x804b428 <maildir_free>, autodetect = 0x804b480 <maildir_autodetect>, set_callbacks = 0x80535e4 <index_storage_set_callbacks>, open_mailbox = 0x804b940 <maildir_open_mailbox>, create_mailbox = 0x804ba5c <maildir_create_mailbox>, delete_mailbox = 0x804bb08 <maildir_delete_mailbox>, rename_mailbox = 0x804bea4 <maildir_rename_mailbox>, list_mailbox_init = 0x804c624 <maildir_list_mailbox_init>, list_mailbox_deinit = 0x804c800 <maildir_list_mailbox_deinit>, list_mailbox_next = 0x804cc48 <maildir_list_mailbox_next>, set_subscribed = 0x8064594 <subsfile_set_subscribed>, get_mailbox_name_status = 0x804bffc <maildir_get_mailbox_name_status>, get_last_error = 0x805455c <mail_storage_get_last_error>, dir = 0x8082100 "/users/48/user9/Maildir", inbox_file = 0x0, index_dir = 0x8082120 "/users/48/user9/Maildir", user = 0x808e050 "user9", error = 0x0, callbacks = 0x8082140, callback_context = 0x0, syntax_error = 0} (gdb) p ibox $6 = (struct index_mailbox *) 0x808c400 (gdb) p *ibox $7 = {box = {name = 0x808e070 "INBOX", storage = 0x808f000, close = 0x805359c <index_storage_close>, get_status = 0x8052ee4 <index_storage_get_status>, sync = 0x8053b94 <index_storage_sync>, auto_sync = 0x804c0c8 <maildir_storage_auto_sync>, expunge = 0x804fa64 <index_storage_expunge>, update_flags = 0x8053d58 <index_storage_update_flags>, copy = 0x804c3e4 <maildir_storage_copy>, fetch_init = 0x804fb00 <index_storage_fetch_init>, fetch_deinit = 0x804fbe8 <index_storage_fetch_deinit>, fetch_next = 0x804fc70 <index_storage_fetch_next>, fetch_uid = 0x804fd5c <index_storage_fetch_uid>, fetch_seq = 0x804fdc0 <index_storage_fetch_seq>, search_get_sorting = 0x8052af4 <index_storage_search_get_sorting>, search_init = 0x8052b08 <index_storage_search_init>, search_deinit = 0x8052be0 <index_storage_search_deinit>, search_next = 0x8052ca0 <index_storage_search_next>, save_init = 0x804cf4c <maildir_storage_save_init>, save_deinit = 0x804cfe0 <maildir_storage_save_deinit>, save_next = 0x804ce04 <maildir_storage_save_next>, is_inconsistency_error = 0x8054578 <mail_storage_is_inconsistency_error>, readonly = 0, allow_custom_flags = 0, inconsistent = 0}, expunge_locked = 0, index = 0x808c200, autosync_to = 0x0, autosync_files = 0x0, autosync_type = MAILBOX_SYNC_NONE, sync_last_check = 0, min_newmail_notify_interval = 0, fetch_mail = {mail = {seq = 0, uid = 0, seen_updated = 0, get_flags = 0, get_parts = 0, get_received_date = 0, get_date = 0, get_size = 0, get_header = 0, get_address = 0, get_first_mailbox = 0, get_stream = 0, get_special = 0}, data = {flags = { flags = 0, custom_flags = 0x0, custom_flags_count = 0}, received_date = 0, size = 0, sent_time = 0, sent_timezone = 0, headers = 0x0, parts = 0x0, envelope = 0x0, body = 0x0, bodystructure = 0x0, envelope_data = 0x0, rec = 0x0, stream = 0x0, hdr_size = {physical_size = 0, virtual_size = 0, lines = 0}, body_size = { physical_size = 0, virtual_size = 0, lines = 0}, parse_header = 0, save_sent_time = 0, save_envelope = 0, hdr_size_set = 0, body_size_set = 0}, pool = 0x0, ibox = 0x0, header_buf = 0x0, wanted_fields = 0, wanted_headers = 0x0}, synced_messages_count = 0, next_lock_notify = 1050439154, last_notify_type = MAIL_LOCK_NOTIFY_MAILBOX_ABORT, sent_diskspace_warning = 0} (gdb) quit % exit Script done on Tue Apr 15 16:53:06 2003

2 3

[dovecot] PATCH allow_zero_gid option
by Dominic Marks 15 Apr '03

15 Apr '03

Hey, Well, that was easy :-) Patch against CVS follows: Summary: Created a boolean option allow_zero_gid, when set to yes it will allow logins from users whose group id is zero. Tested with KMail 3.1.1 on FreeBSD 4.8. I'm not sure if my method for passing the boolean via the environment is correct, it looks a little on the ugly side. Index: src/lib/restrict-access.c =================================================================== RCS file: /home/cvs/dovecot/src/lib/restrict-access.c,v retrieving revision 1.10 diff -u -3 -p -r1.10 restrict-access.c --- src/lib/restrict-access.c 4 Mar 2003 04:00:13 -0000 1.10 +++ src/lib/restrict-access.c 15 Apr 2003 17:37:26 -0000 @@ -31,12 +31,14 @@ #include <grp.h> void restrict_access_set_env(const char *user, uid_t uid, gid_t gid, - const char *chroot_dir) + const char *chroot_dir, int allow_zg) { if (user != NULL && *user != '\0') env_put(t_strconcat("RESTRICT_USER=", user, NULL)); if (chroot_dir != NULL && *chroot_dir != '\0') env_put(t_strconcat("RESTRICT_CHROOT=", chroot_dir, NULL)); + if (allow_zg == TRUE) + env_put(t_strdup("ALLOW_ZERO_GID=TRUE")); env_put(t_strdup_printf("RESTRICT_SETUID=%s", dec2str(uid))); env_put(t_strdup_printf("RESTRICT_SETGID=%s", dec2str(gid))); @@ -45,6 +47,7 @@ void restrict_access_set_env(const char void restrict_access_by_env(int disallow_root) { const char *env; + int allow_zero_gid; gid_t gid; uid_t uid; @@ -97,8 +100,14 @@ void restrict_access_by_env(int disallow i_fatal("We couldn't drop root privileges"); } - if ((gid != 0 && uid != 0) || disallow_root) { + /* allow users with zero group id permission for BSD */ + env = getenv("ALLOW_ZERO_GID"); + allow_zero_gid = env == NULL ? FALSE : TRUE; + + if (allow_zero_gid == FALSE && + ((gid != 0 && uid != 0) || disallow_root)) { if (getgid() == 0 || getegid() == 0 || setgid(0) == 0) i_fatal("We couldn't drop root group privileges"); } + } Index: src/lib/restrict-access.h =================================================================== RCS file: /home/cvs/dovecot/src/lib/restrict-access.h,v retrieving revision 1.4 diff -u -3 -p -r1.4 restrict-access.h --- src/lib/restrict-access.h 4 Mar 2003 04:00:13 -0000 1.4 +++ src/lib/restrict-access.h 15 Apr 2003 17:37:26 -0000 @@ -4,7 +4,7 @@ /* set environment variables so they can be read with restrict_access_by_env() */ void restrict_access_set_env(const char *user, uid_t uid, gid_t gid, - const char *chroot_dir); + const char *chroot_dir, int allow_zg); /* chroot, setuid() and setgid() based on environment variables. If disallow_roots is TRUE, we'll kill ourself if we didn't have the Index: src/master/auth-process.c =================================================================== RCS file: /home/cvs/dovecot/src/master/auth-process.c,v retrieving revision 1.41 diff -u -3 -p -r1.41 auth-process.c --- src/master/auth-process.c 2 Apr 2003 02:09:41 -0000 1.41 +++ src/master/auth-process.c 15 Apr 2003 17:37:27 -0000 @@ -307,7 +307,7 @@ static pid_t create_auth_process(struct /* setup access environment */ restrict_access_set_env(group->set->user, pwd->pw_uid, pwd->pw_gid, - group->set->chroot); + group->set->chroot, set->allow_zero_gid); /* set other environment */ env_put(t_strconcat("AUTH_PROCESS=", dec2str(getpid()), NULL)); Index: src/master/login-process.c =================================================================== RCS file: /home/cvs/dovecot/src/master/login-process.c,v retrieving revision 1.40 diff -u -3 -p -r1.40 login-process.c --- src/master/login-process.c 15 Apr 2003 16:58:48 -0000 1.40 +++ src/master/login-process.c 15 Apr 2003 17:37:27 -0000 @@ -384,7 +384,8 @@ static void login_process_init_env(struc clean_child_process() since it clears environment */ restrict_access_set_env(group->set->user, group->set->uid, set->login_gid, - set->login_chroot ? set->login_dir : NULL); + set->login_chroot ? set->login_dir : NULL, + set->allow_zero_gid); env_put("DOVECOT_MASTER=1"); Index: src/master/mail-process.c =================================================================== RCS file: /home/cvs/dovecot/src/master/mail-process.c,v retrieving revision 1.13 diff -u -3 -p -r1.13 mail-process.c --- src/master/mail-process.c 15 Apr 2003 16:58:48 -0000 1.13 +++ src/master/mail-process.c 15 Apr 2003 17:37:28 -0000 @@ -25,7 +25,7 @@ static int validate_uid_gid(uid_t uid, g return FALSE; } - if (uid != 0 && gid == 0) { + if (set->allow_zero_gid == FALSE && uid != 0 && gid == 0) { i_error("mail process isn't allowed to be in group 0"); return FALSE; } @@ -38,8 +38,9 @@ static int validate_uid_gid(uid_t uid, g return FALSE; } - if (gid < (gid_t)set->first_valid_gid || - (set->last_valid_gid != 0 && gid > (gid_t)set->last_valid_gid)) { + if (set->allow_zero_gid == FALSE && + (gid < (gid_t)set->first_valid_gid || + (set->last_valid_gid != 0 && gid > (gid_t)set->last_valid_gid))) { i_error("mail process isn't allowed to use " "GID %s (UID is %s)", dec2str(gid), dec2str(uid)); return FALSE; @@ -150,7 +151,8 @@ int create_mail_process(int socket, stru (paranoia about filling up environment without noticing) */ restrict_access_set_env(data + reply->system_user_idx, reply->uid, reply->gid, - reply->chroot ? data + reply->home_idx : NULL); + reply->chroot ? data + reply->home_idx : NULL, + set->allow_zero_gid); restrict_process_size(process_size, (unsigned int)-1); Index: src/master/master-settings.c =================================================================== RCS file: /home/cvs/dovecot/src/master/master-settings.c,v retrieving revision 1.16 diff -u -3 -p -r1.16 master-settings.c --- src/master/master-settings.c 2 Apr 2003 02:09:41 -0000 1.16 +++ src/master/master-settings.c 15 Apr 2003 17:37:28 -0000 @@ -46,6 +46,7 @@ static struct setting_def setting_defs[] DEF(SET_INT, max_mail_processes), DEF(SET_BOOL, verbose_proctitle), + DEF(SET_BOOL, allow_zero_gid), DEF(SET_INT, first_valid_uid), DEF(SET_INT, last_valid_uid), DEF(SET_INT, first_valid_gid), @@ -153,6 +154,7 @@ struct settings default_settings = { MEMBER(max_mail_processes) 1024, MEMBER(verbose_proctitle) FALSE, + MEMBER(allow_zero_gid) FALSE, MEMBER(first_valid_uid) 500, MEMBER(last_valid_uid) 0, MEMBER(first_valid_gid) 1, Index: src/master/master-settings.h =================================================================== RCS file: /home/cvs/dovecot/src/master/master-settings.h,v retrieving revision 1.10 diff -u -3 -p -r1.10 master-settings.h --- src/master/master-settings.h 2 Apr 2003 02:09:41 -0000 1.10 +++ src/master/master-settings.h 15 Apr 2003 17:37:29 -0000 @@ -32,6 +32,7 @@ struct settings { unsigned int max_mail_processes; int verbose_proctitle; + int allow_zero_gid; unsigned int first_valid_uid, last_valid_uid; unsigned int first_valid_gid, last_valid_gid; Thanks, -- Dominic <dom at cus.org.uk> <d.marks at student.umist.ac.uk>

2 2

[dovecot] 0.99.9-test4
by Timo Sirainen 15 Apr '03

15 Apr '03

http://procontrol.fi/test/ - Crashfix for multipart messages - More optimized mbox rewriting, should be "good enough" for most uses I think. I've been using it for a while now, seems to work. Still some problems: imap(cras): Apr 15 01:48:48 Warning: Our dotlock file /home/cras/mail//full-disclosure.lock was overridden And I'm sure it wasn't. Or at least shouldn't have been. Have to look more into this..

4 4

[dovecot] Group ID validation and FreeBSD
by Dominic Marks 15 Apr '03

15 Apr '03

Hey, I've been working on making the Dovecot FreeBSD port resemble something which actually works this weekend, it's now much improved - one thing that I did notice is that Dovecot validates a users GID and will not accept a group id of 0. In FreeBSD the group wheel has a the id 0 and only members of the wheel group are allowed to use su and become root. Consequently there are non-root users who have group id's of 0. When you try and open the mailbox of such a user with Dovecot the connection is killed immediately. It would be excellent to have an option in dovecot.conf along the lines of allow_zero_gid which would disable these checks. From a quick look at the source I can see that the validation is being done in src/master/mail-process.c and that src/lib/restrict-access.c is also involved. If I can get a working patch ready quickly I'll pass it along. If anyone would like to take a look at the port you can get a copy at the following address: http://cus.org.uk/~dom/dovecot-0.99.8.1.shar.gz Hopefully this will go into FreeBSD CVS quite soon. Thanks, -- Dominic <dom at cus.org.uk> <d.marks at student.umist.ac.uk>

1 0

[dovecot] 0.99.9-test3
by Timo Sirainen 15 Apr '03

15 Apr '03

Expunging messages caused those "Corrupted index file" errors. That's fixed now. There's probably still some problems, at least this fix didn't fix any crashes.. test3 available from http://dovecot.procontrol.fi/test/

2 3

[dovecot] a crashy message
by Moe Wibble 15 Apr '03

15 Apr '03

Hi everyone, the attached message does reliably crash my dovecot when trying to access a folder containing it. Crash notice in mail.log: Apr 13 17:36:12 rafter dovecot: child 23215 (imap) killed with signal 11 My `dovecot --version` says: 0.99.8 Has this problem been fixed in current dovecot? For now I have just quarantined the offending message but obviously I need to upgrade my dovecot soon because I don't like such kinda things to happen. best regards! -- MW

2 2

[dovecot] Three *very* strange bugs
by Warren Togami 15 Apr '03

15 Apr '03

* Attached is a mbox file that triggers Bug #1 and #2. * Go here if you want to test dovecot for RH9: https://bugzilla.fedora.us/show_bug.cgi?id=160 * If somebody has a different IMAP server than dovecot, could you please test how Evolution reacts to reading this message? Bug #1 dovecot and #2 evolution-1.2.3 ===================================== I am using dovecot-0.99.9-test3 on RH9, reading mail with evolution-1.2.2-5 on RH9. Whenever I attempt to view this one particular spam message, evolution pops up an error like: Error while 'Retrieving message 4': Server unexpectedly disconnected: No such file or directory Simultaneously this appears in my /var/log/maillog: Apr 15 01:44:50 server dovecot: child 20328 (imap) killed with signal 11 If I attempt to keep reading mail, it logs in again to dovecot and works normally until I attempt to read that spam again. Evolution displays the error popup again though I don't see another signal 11 in maillog. After this point I am unable to log back into dovecot without restarting the daemon. Here's the strange part... I browsed the same IMAP folder from KMail, and kmail has no problem reading that spam message. dovecot's [imap] process does not segmentation fault. Does this mean an evolution bug when reading this particular spam exposed a dovecot segmentation fault? Bug #3 kernel? ============== This is an unrelated bug and perhaps not the fault of dovecot. When I attempted to use strace to get some debugging info on the [imap] process, this happened: [root@server /]# strace -p 20486 trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted detach: ptrace(PTRACE_DETACH, ...): Operation not permitted [root@server /]# This isn't normal right? After doing this, dovecot stops working and I need to restart the daemon in order to establish new connections. That [imap] process becomes unkillable, even kill -9 wont work. Unkillable process usually means kernel bug, right? warren 20345 1 7 01:46 ? 00:00:34 [imap] This is kernel-2.4.20-9 in Red Hat Linux 9. Is dovecot exposing a Red Hat kernel bug when I try to strace that process, or is strace supposed to fail, the dovecot daemon ceases to function and [imap] process becomes completely unkillable? =) Warren Togami warren(a)togami.com

2 1