- dovecot - dovecot.org

[Dovecot] rc25: need_space assert, core
by Jeff A. Earickson 06 Mar '07

06 Mar '07

Timo, I see where at least one other person reported this, but here goes. I went from rc24 to rc25 this morning, and I got an assert and core from my own mailbox withing five minutes: Mar 2 06:52:26 karst dovecot: [ID 107833 mail.error] IMAP(jaearick): file mbox-sync-rewrite.c: line 408: assertion failed: (need_space == (uoff_t)-mails[idx].space) Mar 2 06:52:26 karst dovecot: [ID 107833 mail.error] IMAP(jaearick): Raw backtrace: 0x89720 -> 0x46e50 -> 0x47410 -> 0x426d4 -> 0x42d60 -> 0x438b0 -> 0x43b38 -> 0x2a828 -> 0x2ada4 -> 0x231dc -> 0x23368 -> 0x23450 -> 0x8fe14 -> 0x8f638 -> 0x2cd64 -> 0x1dad8 Unfortunately, I switched compilers at rc24 and rc25. Before I used to compile with gcc -g -O so I could poke at cores. Now I use (Sun Studio 11) cc -O, so no useful information on a gdb traceback: (gdb) backtrace #0 0xff1c16e0 in _lwp_kill () from /lib/libc.so.1 #1 0xff15ff38 in raise () from /lib/libc.so.1 #2 0xff140160 in abort () from /lib/libc.so.1 #3 0x00089cd4 in i_internal_panic_handler () #4 0x00089728 in i_panic () #5 0x00046e58 in mbox_sync_read_and_move () #6 0x00047418 in mbox_sync_rewrite () #7 0x000426dc in mbox_sync_handle_eof_updates () #8 0x00042d68 in mbox_sync_do () #9 0x000438b8 in mbox_sync () #10 0x00043b40 in mbox_storage_sync_init () #11 0x0002a830 in imap_sync_init () #12 0x0002adac in cmd_sync () #13 0x000231e4 in client_handle_input () #14 0x00023370 in client_handle_input () #15 0x00023458 in _client_input () #16 0x0008fe1c in io_loop_handler_run () #17 0x0008f640 in io_loop_run () #18 0x0002cd6c in main () My setup: Solaris 10, homedirs (imap cache files) on a local zfs filesystem, mailboxes NFS mounted from another Sun system (NFS v4) which is also zfs on the mail server. Mbox format, no disk quotas anyplace, no plugins. I have rolled back to rc24. Jeff Earickson Colby College

4 3

[Dovecot] dovecot-example.conf glitches
by Steffen Kaiser 06 Mar '07

06 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, for a nice v1.0 release, there are some glitches in the example: 1) # allow shell access for users. See doc/configuration.txt for more information. #valid_chroot_dirs = There is no "doc/configuration.txt" (anymore) 2) spots like: #login_executable = /usr/libexec/dovecot/imap-login The path is where the file belongs to in a "real" production environment, however, the file should reflect the place "make install" uses, esp. because the default "./configure" uses --prefix /usr/local. Bye, - -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBReb7Ay9SORjhbDpvAQJaqwgA2AEoit4BVUn8ahxveDT3lMQVzfpKR68X K415T2oZOFW8F1jtovTShp3yVDEpKem3Mw4JvHPZmlR89IAdPpZLWgahW3t0tP8n DAb8tqph7t4Ct5m9MGN/yyg5aTxz8gR7C6oZDuP/XAC/OlbS3XRfLele3i+v6sch LEI6y5MRYkCubbFzRJCBvgxWJZ5Au7q8Rvn9WVotVp1oTf0cgYG6z3mzNwHQcZLk sqSKQdzwsiMloO0mM+iVa2T8qmF4EAwjsO9XnRJy197xlxrCLdC/ZVRdFMVKE7Nd 0doyKkSiiSKdSUBr0ewEuy+Ikp2m8+5z5n0U2trvSMYd31pylA/Q0Q== =SC/q -----END PGP SIGNATURE-----

3 2

[Dovecot] File descriptor leak in 1.0rc2[45]?
by Victor Duchovni 06 Mar '07

06 Mar '07

I upgraded (NetBSD 2.99 i386) from 1.0rc7 to 1.0rc24 and then tried rc25, and in both cases need to restart Dovecot every day or so (low volume server). It seems to run out of file descriptors. I have now raised the file descriptor limit to 1024, but that is not a long-term solution... ... Mar 5 11:41:38 arioch dovecot: pipe() failed: Too many open files Mar 5 11:42:38 arioch dovecot: pipe() failed: Too many open files Mar 5 11:43:38 arioch dovecot: pipe() failed: Too many open files Mar 5 11:44:38 arioch dovecot: pipe() failed: Too many open files Mar 5 11:46:38 arioch dovecot: pipe() failed: Too many open files Mar 5 11:47:38 arioch dovecot: pipe() failed: Too many open files Mar 5 11:48:38 arioch dovecot: pipe() failed: Too many open files Mar 5 11:49:38 arioch dovecot: pipe() failed: Too many open files Mar 5 11:50:38 arioch dovecot: pipe() failed: Too many open files ... lsof(1) output for dovecot-auth and dovecot: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME dovecot-a 22627 root cwd VDIR 0,6 512 405514 /var/run/dovecot dovecot-a 22627 root txt VREG 0,5 175256 1083551 /usr (/dev/wd0f) dovecot-a 22627 root txt VREG 0,5 7399 101747 /usr/lib/libcom_err.so.4.1 dovecot-a 22627 root txt VREG 0,0 1083908 67635 /lib/libcrypto.so.2.1 dovecot-a 22627 root txt VREG 0,0 866469 67587 /lib/libc.so.12.125 dovecot-a 22627 root txt VREG 0,0 24557 67605 /lib/libcrypt.so.0.2 dovecot-a 22627 root txt VREG 0,5 52783 101743 /usr/lib/libroken.so.12.3 dovecot-a 22627 root txt VREG 0,5 41436 101739 /usr/lib/libdes.so.7.0 dovecot-a 22627 root txt VREG 0,5 145345 101759 /usr/lib/libasn1.so.6.1 dovecot-a 22627 root txt VREG 0,5 251589 102046 /usr/lib/libkrb5.so.19.1 dovecot-a 22627 root txt VREG 0,5 66856 101775 /usr/lib/libgssapi.so.5.0 dovecot-a 22627 root txt VREG 0,0 56172 101377 /libexec/ld.elf_so dovecot-a 22627 root 0u unix 0xc0f773c4 0t0 ->0xc115a144 dovecot-a 22627 root 1r VCHR 2,2 0t0 45067 /dev/null dovecot-a 22627 root 2w PIPE 0xcb000e10 0 ->0xcb000d80 dovecot-a 22627 root 3u unix 0xc0f9fbe4 0t0 /var/run/dovecot/login/default dovecot-a 22627 root 4u KQUEUE 0xc0f11c30 dovecot-a 22627 root 5r VCHR 46,1 0t4 45571 /dev/urandom dovecot-a 22627 root 6r PIPE 0xcb0006c0 16384 ->0xcc08b2d0 dovecot-a 22627 root 7w PIPE 0xcc08b2d0 0 ->0xcb0006c0 dovecot-a 22627 root 12r VCHR 46,1 0t1024 45571 /dev/urandom ---------- COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME dovecot 5161 root cwd VDIR 0,6 512 405514 /var/run/dovecot dovecot 5161 root txt VREG 0,5 119872 1109297 /usr (/dev/wd0f) dovecot 5161 root txt VREG 0,0 866469 67587 /lib/libc.so.12.125 dovecot 5161 root txt VREG 0,0 56172 101377 /libexec/ld.elf_so dovecot 5161 root 0r VCHR 2,2 0t0 45067 /dev/null dovecot 5161 root 1r VCHR 2,2 0t0 45067 /dev/null dovecot 5161 root 2r VCHR 2,2 0t0 45067 /dev/null dovecot 5161 root 3r VCHR 2,2 0t0 45067 /dev/null dovecot 5161 root 4r VCHR 2,2 0t0 45067 /dev/null dovecot 5161 root 5u IPv4 0xc0f13500 0t0 TCP *:imap (LISTEN) dovecot 5161 root 6u KQUEUE 0xc0f11410 dovecot 5161 root 7u unix 0xc0d3cd80 0t0 ->0xc0d3c0d8 dovecot 5161 root 8r PIPE 0xcb000a20 16384 ->0xcb000cf0 dovecot 5161 root 9w PIPE 0xcb000cf0 0 ->0xcb000a20 dovecot 5161 root 10u unix 0xc0f15bd4 0t0 /var/run/dovecot/dict-server dovecot 5161 root 11u unix 0xc0f9fbe4 0t0 /var/run/dovecot/login/default dovecot 5161 root 12u unix 0xc115a144 0t0 ->0xc0f773c4 dovecot 5161 root 14r PIPE 0xcb000900 16384 dovecot 5161 root 16r PIPE 0xcb000d80 16384 ->0xcb000e10 dovecot 5161 root 17r PIPE 0xcd4a7994 16384 dovecot 5161 root 18r PIPE 0xcd4a7bd4 16384 dovecot 5161 root 19r PIPE 0xcd659634 16384 dovecot 5161 root 20r PIPE 0xcb000870 16384 dovecot 5161 root 21r PIPE 0xcd4a7c64 16384 dovecot 5161 root 22r PIPE 0xcd4a7cf4 16384 dovecot 5161 root 23r PIPE 0xce11dac4 16384 dovecot 5161 root 24r PIPE 0xce11d914 16384 dovecot 5161 root 25r PIPE 0xcd4a71b4 16384 dovecot 5161 root 26r PIPE 0xce11d644 16384 dovecot 5161 root 27r PIPE 0xcd6592d4 16384 dovecot 5161 root 28r PIPE 0xcd659094 16384 dovecot 5161 root 29r PIPE 0xcd659874 16384 dovecot 5161 root 30r PIPE 0xcb000990 16384 dovecot 5161 root 31r PIPE 0xce11d374 16384 dovecot 5161 root 32r PIPE 0xce11d254 16384 dovecot 5161 root 33r PIPE 0xce11d764 16384 dovecot 5161 root 34r PIPE 0xcd4a72d4 16384 dovecot 5161 root 35r PIPE 0xce11de24 16384 dovecot 5161 root 36r PIPE 0xce11d404 16384 dovecot 5161 root 37r PIPE 0xce11d9a4 16384 dovecot 5161 root 38r PIPE 0xcd659754 16384 dovecot 5161 root 39r PIPE 0xcd659c64 16384 dovecot 5161 root 40r PIPE 0xcc08b5a0 16384 dovecot 5161 root 41r PIPE 0xcc08b870 16384 dovecot 5161 root 42r PIPE 0xcc08b360 16384 dovecot 5161 root 43r PIPE 0xcc08bc60 16384 dovecot 5161 root 44r PIPE 0xcc08bab0 16384 dovecot 5161 root 45r PIPE 0xcc08b000 16384 dovecot 5161 root 46r PIPE 0xcc08b120 16384 dovecot 5161 root 47r PIPE 0xcc08b6c0 16384 dovecot 5161 root 48r PIPE 0xcc08b990 16384 dovecot 5161 root 49u unix 0xc0f77214 0t0 /var/run/dovecot/auth-worker.22627 dovecot 5161 root 50r PIPE 0xcc08b630 16384 dovecot 5161 root 51r PIPE 0xcc08b240 16384 dovecot 5161 root 52r PIPE 0xcc08bbd0 16384 dovecot 5161 root 53r PIPE 0xcc08b750 16384 dovecot 5161 root 54r PIPE 0xcc08b900 16384 dovecot 5161 root 55r PIPE 0xcc08bb40 16384 dovecot 5161 root 56r PIPE 0xcccd5018 16384 dovecot 5161 root 57r PIPE 0xcc08b1b0 16384 dovecot 5161 root 58r PIPE 0xcccd5528 16384 dovecot 5161 root 59r PIPE 0xcccd52e8 16384 dovecot 5161 root 60r PIPE 0xcd659514 16384 dovecot 5161 root 61r PIPE 0xcccd5138 16384 dovecot 5161 root 62r PIPE 0xcccd59a8 16384 -- Viktor.

2 4

[Dovecot] Migration
by John s 06 Mar '07

06 Mar '07

Hi, I have a Mailserver setup with Qmail+Vpopmail+courier-imap with 2000 users.The authentication in vpopmail was in plaint text file based.Right now the issue is while opening a user email box with 50-100 mails it is opening fastly.Butfor email-boxes with attachments and increased number of mails it take long time to open the Imap connection. So I would like to change the Imaps to Dovecot.Please suggest if I can migrate from courier-imap to dovecot with vpopmail and qmail without changing the present username and passwords. Thanks in advance for any help. Regards John

2 1

[Dovecot] new crashes: is the index/mail cache endian neutral?
by Dan Price 06 Mar '07

06 Mar '07

Part of our migration plan takes our users from one endianness to another (big to little). Will the index and mail cache files survive? I'm seeing some new core dumps as the first test user is migrated, which makes me think... not. What about if we want to build dovecot 64 bit in the future? Will that cause problems too? Stack trace is below the log messages. I've edited the user's name out and replaced it with foobar, and cleansed out a few sensitive things. -dp dovecot: Mar 01 08:46:49 Info: imap-login: Login: user=<foobar>, method=PLAIN, r ip=WWW.XXX.YYY.ZZ, lip=AAA.BBB.CC.DD, TLS dovecot: Mar 01 08:46:49 Info: IMAP(foobar): Effective uid=88442, gid=10, home=/ home/foobar dovecot: Mar 01 08:46:49 Info: IMAP(foobar): mbox: data=/home/foobar:INBOX=/var/ mail/foobar:INDEX=/home/foobar/Mail/imapd-indices dovecot: Mar 01 08:46:49 Info: IMAP(foobar): mbox: root=/home/foobar, index=/hom e/foobar/Mail/imapd-indices, inbox=/var/mail/foobar dovecot: Mar 01 08:46:50 Error: IMAP(foobar): Corrupted index file /home/foobar/ Mail/imapd-indices/.imap/INBOX/dovecot.index: messages_count too large (0 > 0) dovecot: Mar 01 08:46:50 Error: IMAP(foobar): Corrupted index file /home/foobar/ Mail/imapd-indices/.imap/INBOX/dovecot.index: messages_count too large (0 > 0) dovecot: Mar 01 08:46:50 Error: IMAP(foobar): Corrupted index cache file /home/f oobar/Mail/imapd-indices/.imap/INBOX/dovecot.index.cache: field header points ou tside file dovecot: Mar 01 08:46:51 Error: IMAP(foobar): Corrupted transaction log file /ho me/foobar/Mail/imapd-indices/.imap/INBOX/dovecot.index.log: unknown record type 0x10 dovecot: Mar 01 08:46:51 Warning: IMAP(foobar): fscking index file /home/foobar/ Mail/imapd-indices/.imap/INBOX/dovecot.index dovecot: Mar 01 08:46:51 Error: IMAP(foobar): Unexpected transaction log desync with index /home/foobar/Mail/imapd-indices/.imap/INBOX/dovecot.index dovecot: Mar 01 08:46:51 Info: IMAP(foobar): Disconnected: Mailbox is in inconsi stent state, please relogin. dovecot: Mar 01 08:48:06 Info: imap-login: Login: user=<foobar>, method=PLAIN, r ip=WWW.XXX.YYY.ZZ, lip=AAA.BBB.CC.DD, TLS dovecot: Mar 01 08:48:06 Info: IMAP(foobar): Effective uid=88442, gid=10, home=/ home/foobar dovecot: Mar 01 08:48:06 Info: IMAP(foobar): mbox: data=/home/foobar:INBOX=/var/ mail/foobar:INDEX=/home/foobar/Mail/imapd-indices dovecot: Mar 01 08:48:06 Info: IMAP(foobar): mbox: root=/home/foobar, index=/hom e/foobar/Mail/imapd-indices, inbox=/var/mail/foobar dovecot: Mar 01 09:07:09 Error: IMAP(foobar): Corrupted index file /home/foobar/ Mail/imapd-indices/Mail/.imap/zfs/dovecot.index: messages_count too large (27853 45536 > 1) dovecot: Mar 01 09:07:10 Error: IMAP(foobar): Corrupted index cache file /home/f oobar/Mail/imapd-indices/Mail/.imap/zfs/dovecot.index.cache: field header points outside file dovecot: Mar 01 09:20:44 Error: IMAP(foobar): Corrupted index file /home/foobar/ Mail/imapd-indices/Mail/.imap/NDMP/dovecot.index: messages_count too large (5200 93696 > 3) dovecot: Mar 01 09:20:44 Error: IMAP(foobar): Corrupted transaction log file /ho me/foobar/Mail/imapd-indices/Mail/.imap/NDMP/dovecot.index.log: start_offset (61 44) > file size (1768) dovecot: Mar 01 09:20:44 Warning: IMAP(foobar): fscking index file /home/foobar/ Mail/imapd-indices/Mail/.imap/NDMP/dovecot.index dovecot: Mar 01 09:20:44 Error: child 111112 (imap) killed with signal 11 -dp #0 0x0809eaa1 in mail_index_lock_exclusive (index=0x8117c70, lock_id_r=0x8047490) at mail-index-lock.c:326 ret = 0 __PRETTY_FUNCTION__ = "mail_index_lock_exclusive" #1 0x0809e15e in mail_index_fsck (index=0x8117c70) at mail-index-fsck.c:169 error = 0x80e9498 "" lock_id = 135173240 file_seq = 16777216 file_offset = 6144 ret = 134509928 lock_log = true #2 0x080a5c49 in mail_transaction_log_file_set_corrupted (file=0x8101c30, fmt=0x80d51a8 "start_offset (%llu) > file size (%llu)") at mail-transaction-log.c:64 No locals. #3 0x080a785e in mail_transaction_log_file_map (file=0x8101c30, start_offset=6144, end_offset=18446744073709551615) at mail-transaction-log.c:1313 index = (struct mail_index *) 0x8117c70 st = {st_dev = 47777187, st_pad1 = {0, 0, 0}, st_ino = 15761, st_mode = 33152, st_nlink = 1, st_uid = 88442, st_gid = 10, st_rdev = 4294967295, st_pad2 = {0, 0}, st_size = 1768, st_atim = { tv_sec = 1172769644, tv_nsec = 151892829}, st_mtim = {tv_sec = 1172522367, tv_nsec = 0}, st_ctim = {tv_sec = 1172732240, tv_nsec = 566025559}, st_blksize = 2048, st_blocks = 4, st_fstype = "lofs", '\0' <repeats 11 times>, st_pad4 = {0, 0, 0, 0, 0, 0, 0, 0}} ret = 1768 use_mmap = 1 __PRETTY_FUNCTION__ = "mail_transaction_log_file_map" #4 0x080a7bca in mail_transaction_log_sync_lock (log=0x8101bd8, file_seq_r=0x0, file_offset_r=0x0) at mail-transaction-log.c:1373 __PRETTY_FUNCTION__ = "mail_transaction_log_sync_lock" #5 0x0809dad3 in mail_index_open (index=0x8117c70, flags=17, lock_method=MAIL_INDEX_LOCK_FCNTL) at mail-index.c:1423 i = 0 ret = 135294216 #6 0x08096241 in index_storage_mailbox_init (ibox=0x81164b8, name=0x0, flags=0, move_to_memory=false) at index-storage.c:360 storage = (struct mail_storage *) 0x80f62a0 index_flags = 17 lock_method = MAIL_INDEX_LOCK_FCNTL ret = 0 __PRETTY_FUNCTION__ = "index_storage_mailbox_init" #7 0x0807cbfc in mbox_alloc (storage=0x80f62a0, index=0x0, name=0x80f68b0 "Mail/NDMP", path=0x80e92f0 "/home/foobar/Mail/NDMP", flags=14) at mbox-storage.c:546 mbox = (struct mbox_mailbox *) 0x81164b8 pool = 0x1 #8 0x0807cd7c in mbox_open (storage=0x80f62a0, name=0x80f68b0 "Mail/NDMP", flags=14) at mbox-storage.c:662 mbox = (struct mbox_mailbox *) 0x80e9310 index = (struct mail_index *) 0x0 path = 0x80e92f0 "/home/foobar/Mail/NDMP" index_dir = 0x80e9310 "/home/foobar/Mail/imapd-indices/Mail/.imap/NDMP" #9 0x0807cf67 in mbox_mailbox_open (_storage=0x80f62a0, name=0x80f68b0 "Mail/NDMP", input=0x0, flags=14) at mbox-storage.c:773 path = 0x80e92d8 "/home/foobar/Mail/NDMP" st = {st_dev = 47777187, st_pad1 = {0, 0, 0}, st_ino = 15330, st_mode = 33152, st_nlink = 1, st_uid = 88442, st_gid = 10, st_rdev = 4294967295, st_pad2 = {0, 0}, st_size = 1189083, st_atim = { tv_sec = 1172732807, tv_nsec = 577163661}, st_mtim = {tv_sec = 1172679608, tv_nsec = 0}, st_ctim = {tv_sec = 1172731930, tv_nsec = 691932658}, st_blksize = 131072, st_blocks = 2224, st_fstype = "lofs", '\0' <repeats 11 times>, st_pad4 = {0, 0, 0, 0, 0, 0, 0, 0}} #10 0x080acbf6 in mailbox_open (storage=0x0, name=0x80f68b0 "Mail/NDMP", input=0x0, flags=14) at mail-storage.c:365 No locals. #11 0x08067f63 in cmd_copy (cmd=0x80f65cc) at cmd-copy.c:83 client = (struct client *) 0x80f6588 storage = (struct mail_storage *) 0x80f62a0 destbox = (struct mailbox *) 0x8 t = (struct mailbox_transaction_context *) 0x806bec0 search_arg = (struct mail_search_arg *) 0x80f8800 messageset = 0x80f68a8 "542506" mailbox = 0x80f68b0 "Mail/NDMP" sync_flags = 0 ret = 134511032 #12 0x0806affd in cmd_uid (cmd=0x80f65cc) at cmd-uid.c:19 cmd_name = 0x80f68a0 "copy" #13 0x0806b9ce in client_handle_input (cmd=0x80f65cc) at client.c:331 client = (struct client *) 0x80f6588 __PRETTY_FUNCTION__ = "client_handle_input" #14 0x0806b962 in client_handle_input (cmd=0x80f65cc) at client.c:388 client = (struct client *) 0x80f6588 __PRETTY_FUNCTION__ = "client_handle_input" #15 0x0806bb10 in _client_input (context=0x80f6588) at client.c:428 client = (struct client *) 0x80f6588 cmd = (struct client_command_context *) 0x80f65cc ret = 2 #16 0x080bdc35 in io_loop_handler_run (ioloop=0x80f3d80) at ioloop-poll.c:199 ctx = (struct ioloop_handler_context *) 0x80f3db8 pollfd = (struct pollfd *) 0x2 tv = {tv_sec = 0, tv_usec = 617423} io = (struct io *) 0x8105460 t_id = 2 msecs = 0 ret = 0 call = true -- Daniel Price - Solaris Kernel Engineering - dp(a)eng.sun.com - blogs.sun.com/dp

2 1

[Dovecot] Plugins in Python?
by Maykel Moya 06 Mar '07

06 Mar '07

Timo Do you have plans of adding support for writing plugins in high level languages like Python? Regards maykel

2 1

[Dovecot] messages lingering in .Trash/new instead of .Trash/cur
by Glenn Leavell 06 Mar '07

06 Mar '07

We're running Dovecot rc15 on Solaris 9, providing IMAP access to e-mail stored in Maildir++. I've noticed that a significant number of message files are currently sitting in the directories ~/Maildir/.Trash/new/. I would have expected that all messages in .Trash would be in the /cur subdirectory (as most are), and I'm not sure how they're landing in /new. If I connect to Dovecot and run something like the following, the messages all *do* immediately end up in .Trash/cur/ : x select blah * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags * permitted. * 4 EXISTS * 0 RECENT * OK [UIDVALIDITY 1150071896] UIDs valid * OK [UIDNEXT 5] Predicted next UID x OK [READ-WRITE] Select completed. x copy 4 "Trash" x OK Copy completed. Most of our users are using Thunderbird, and after looking at various outputs of rawlog, TB seems to be simply issuing uid copy commands to "Trash" like the ones above when a user deletes a message. Do any of you know what IMAP interaction with Dovecot can lead to message files appearing in .Trash/new/ ? Thanks very much, Glenn -- Glenn Leavell <glenn(a)usg.edu> Office of Information and Instructional Technology Board of Regents of the University System of Georgia

2 1

[Dovecot] Driving quota out of a database.
by David Craigon 06 Mar '07

06 Mar '07

Hi there, I'm using postgres as a userdb for dovecot. I'm am trying to get the quota plugin to work. I have a column in my table that returns the quota in KB. I am using the postgres expression "('maildir:storage=' || mailstore_control.mailbox.quota) AS quota" as recommended in the manuals. This expression is NULL to start with, which I take to mean unlimited quota. Trouble is, if I change it to a value, and then change it back to null, I don't seem to go back to unlimited quota. I'm using maildir++ quotas. What gives? :-) David Griffin Information Systems Ltd 20 St Christopher's Way, Pride Park, Derby DE24 8JY www.griffin.com <http://www.griffin.com/> Registered in England and Wales. Company Registration Number: 3676297.

3 2

[Dovecot] Replacing qmail + vpopmail with: sendmail + dovecot
by Oliver Schulze L. 06 Mar '07

06 Mar '07

Hi, I wonder if it posible to replace qmail + vpopmail with sendmail + dovecot? The idea is like this: - use sendmail + milter API to filter spam/virus and deliver the email to the dovevot MDA (LDA) - dovecot should save the email to the directory as specified in the vpopmail DB - maintain the vpopmail BD (users + passwd) - use dovecot pop3/imap for the clients - use sendmail again to receive the email from the pop3/imap users and deliver the email to the internet as usual. Anyone has done this? It is posible in the paper, in the real world? many thanks Oliver -- Oliver Schulze L. | Get my e-mail after a captcha in: Asuncion - Paraguay | http://tinymailto.com/oliver

5 6

[Dovecot] My "fighting spam" article is live!
by Esther Schindler 06 Mar '07

06 Mar '07

Getting Clueful: Five Things You Should Know About Fighting Spam The battle for your users’ e-mail inboxes probably will never end, but it’s not a failure of technology. Experienced e-mail and system administrators share the key points they really, really wish you understood. http://www.cio.com/technology/infrastructure/security/spam/ five_things_about_fighting_spam.html?CID=28830 Thanks to everybody who contributed. :-) Esther

10 14