- dovecot - dovecot.org

[Dovecot] Problem with rc10
by Steven F Siirila 20 Nov '06

20 Nov '06

I just upgraded our test server from rc6 to rc10... ISSUE #1 I noticed that we no longer are getting two "From_" lines. However, the one that was good (had the original sender e-mail address) is now gone. The one with "dovecot.deliver" remains. I attempted to add "-d test" to the mailbox_command line in main.cf as follows: mailbox_command = /opt/dovecot/libexec/dovecot/deliver -d test and things turned ugly and caused Postfix to defer messages: Oct 17 16:31:50 hostname postfix/local[7230]: D14632C9C: to=<someuser@somehost>, relay=local, delay=3.6, delays=3/0.02/0/0.62, dsn=4.3.0, status=deferred (temporary failure) I removed the "-d test" from the Postfix main.cf and the problem went away. So, how do I fix the "From_" lines? ISSUE #2 After upgrading, messages cannot be moved from the INBOX to a folder. Thunderbird claims there was an internal error and to consule the server logs, but I see nothing in the dovecot logs that would indicate what's going on. For example, I attempted to move a message into my Trash folder which did not currently have any index files. Here is a Solaris truss output of that attempt: poll(0x000B4C98, 2, 999) = 0 poll(0x000B4C98, 2, 0) = 0 poll(0x000B4C98, 2, 999) = 1 read(0, " D O N E\r\n", 3323) = 6 write(1, " 2 8 O K I d l e c".., 23) = 23 read(0, 0x000BC5BB, 3317) Err#11 EAGAIN poll(0x000B4C98, 2, 675) = 1 read(0, " 3 0 u i d c o p y ".., 3317) = 27 stat64("/home/sfs/Trash", 0xFFBFF5C8) = 0 alarm(120) = 0 fcntl(6, F_SETLKW64, 0xFFBFF308) = 0 alarm(0) = 120 stat64("/home/sfs/Trash", 0xFFBFF640) = 0 mkdir("/home/sfs/.imap/Trash", 0770) Err#17 EEXIST stat64("/home/sfs/.imap/Trash", 0xFFBFF4C0) = 0 stat64("/home/sfs/Trash", 0xFFBFF4C0) = 0 time() = 1161122396 open64("/home/sfs/.imap/Trash/dovecot.index", O_RDWR) Err#2 ENOENT open64("/home/sfs/.imap/Trash/dovecot.index", O_RDWR) Err#2 ENOENT write(1, " 3 0 N O I n t e r n".., 96) = 96 poll(0x000B4C98, 2, 588) = 0 poll(0x000B4C98, 2, 0) = 0 poll(0x000B4C98, 2, 410) = 0 Someone else using a different IMAP client caused these errors to occur (this is even after I wiped all of their dovecot index files): Oct 17 16:43:11 earth.tc.umn.edu dovecot: IMAP(kor): Corrupted transaction log file /home/kor/.imap/INBOX/dovecot.index.log: invalid indexid (1161121145 != 1156185395) Oct 17 16:43:11 earth.tc.umn.edu dovecot: IMAP(kor): Corrupted transaction log file /home/kor/.imap/INBOX/dovecot.index.log: invalid new transaction log sequence (6 >= 6) Oct 17 16:47:09 earth.tc.umn.edu dovecot: IMAP(kor): Corrupted transaction log file /home/kor/.imap/INBOX/dovecot.index.log: invalid indexid (1161121145 != 1161120959) Oct 17 16:47:09 earth.tc.umn.edu dovecot: IMAP(kor): Corrupted transaction log file /home/kor/.imap/INBOX/dovecot.index.log: invalid new transaction log sequence (2 >= 2) Oct 17 17:05:59 earth.tc.umn.edu dovecot: IMAP(kor): Corrupted transaction log file /home/kor/.imap/INBOX/dovecot.index.log: invalid indexid (1161121145 != 1161120959) Oct 17 17:05:59 earth.tc.umn.edu dovecot: IMAP(kor): Corrupted transaction log file /home/kor/.imap/INBOX/dovecot.index.log: invalid new transaction log sequence (4 >= 4) Here are our non-standard dovecot.conf items: protocols = imap imaps pop3 pop3s shutdown_clients = no syslog_facility = local6 ssl_cert_file = /etc/opt/openssl/certs/dovecot.pem ssl_key_file = /etc/opt/openssl/private/dovecot.pem default_mail_env = mbox:~/:INBOX=/var/mail/%u # Default namespace namespace private { separator = / prefix = location = mbox:~/:INBOX=/var/mail/%u inbox = yes hidden = yes } mail_full_filesystem_access = yes first_valid_uid = 100 max_mail_processes = 8192 mbox_min_index_size = 128 imap_client_workarounds = delay-newmail outlook-idle tb-extra-mailbox-sep pop3_uidl_format = %08Xu%08Xv protocol lda { postmaster_address = postmaster(a)umn.edu mail_plugins = cmusieve } auth_verbose = yes auth_debug = yes auth default { passdb pam { args = session=yes * } } I am now backing out to rc6 for now... we never saw this behavior on rc6. -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs(a)umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593

2 4

[Dovecot] Problems Creating Core Dumps
by Joseph D. Wagner 20 Nov '06

20 Nov '06

Dovecot 1.0.rc15 crashed on my FC4 server, but it didn't create a core dump. Upon further research, I found these lines tucked away in the /etc/rc.d/init.d/functions file: # make sure it doesn't core dump anywhere unless requested ulimit -S -c ${DAEMON_COREFILE_LIMIT:-0} >/dev/null 2>&1 The /etc/rc.d/init.d/functions file is a master file that is referenced by all of the init scripts, so I didn't want to change it. Instead, I created a file /etc/sysconfig/dovecot with the following line: DAEMON_COREFILE_LIMIT=unlimited If I'm reading the /etc/rc.d/init.d/functions file correctly, this should work, but my bash is rusty. I was hoping someone else could check my work. Joseph D. Wagner

2 1

[Dovecot] Backtraces without core dumps
by Timo Sirainen 19 Nov '06

19 Nov '06

Since getting core dumps seems to be difficult sometimes, especially with login processes, I've now added code to log the backtrace when Dovecot crashes in some assert check (or some other reason why it decides to abort()). This code works with Linux and Solaris, but I don't know about BSDs. Apparently there exists libexecinfo library which could be used. I think this code could be used to log backtraces also for segfaults, but that's more risky so I didn't do it yet. Maybe it should be done only optionally. If you're interested in trying, the code is now in CVS and in the latest nightly snapshot. When it crashes, it prints something like: Panic: file client.c: line 55 (client_create): assertion failed: (my_client != NULL) Error: Backtrace: ./imap [0x80b2ffa] -> ./imap [0x80b2ecc] -> ./imap [0x805bbb3] -> ./imap(main+0x426) [0x80634a6] -> /lib/tls/libc.so.6 (__libc_start_main+0xc8) [0xb7e53ea8] -> ./imap [0x80566a1] Looks like the symbol name resolving doesn't work all that great. But here gdb will help you: gdb ./imap (gdb) b *0x80b2ffa Breakpoint 1 at 0x80b2ffa: file failures.c, line 126. (gdb) b *0x80b2ecc Breakpoint 2 at 0x80b2ecc: file failures.c, line 185. (gdb) b *0x805bbb3 Breakpoint 3 at 0x805bbb3 (gdb) b *0x80634a6 Breakpoint 4 at 0x80634a6: file main.c, line 223. That went pretty well, except for some reason it couldn't figure out where 0x805bbb3 was. To get some kind of an idea about that, you can do: (gdb) x 0x805bbb3 0x805bbb3 <client_create+467>: 0x90909090 If someone knows better ways to do all of this, please tell me too :)

1 0

[Dovecot] Dovecot (unofficial) patches
by Egbert Jan 19 Nov '06

19 Nov '06

Dear list, As a recent dovecot addict, I'm a bit puzzled by the sheer amount of patches available. I have not seen the history of these patches and I could not find a README explainng the patches. Are all these personal wishes/nice to have things or are they (to be) incorporated in dovecot-final? I use rpmbuild to create new rpms from the latest tarball but in that process still several patches are included during the build. I wonder if they are still needed in rc15. I use the orignal spec file (the latest I could find) was created for rc7 and in there I see: Patch2 dovecot-0.99.10-mbox-patch Seems to be to change the order of ./Mail before ./mail Patch3 dovecot-CVE-2006-2414 Overview from CVE db:Directory traversal vulnerability in Dovecot 1.0 beta and 1.0 allows remote attackers to list files and directories under the mbox parent directory and obtain mailbox names via ".." sequences in the (1) LIST or (2) DELETE IMAP command. I'm not a spec file wizard, so I change as less as possible. Unfortunately the maintainer (Jerome Soyer) has never responded to my emails. My server runs Mandriva Official 2007.0 and Postfix 2.3.3 and dovecot rc14 (will move to rc15 soon). TNX EgbertJan (NL)

2 1

[Dovecot] TLS timeout with Thunderbird
by Jason Dixon 19 Nov '06

19 Nov '06

I'm trying to get dovecot working with various clients on my new mailserver. I installed the base rc2 that comes with OpenBSD 4.0, then upgraded to rc14 when I ran into problems with TLS and Thunderbird. The server has no problems with Mail.app on my laptop, but any connection attempts from Thunderbird timeout after the TCP handshake. 13:53:41.074438 66.x.x.2.50483 > 38.x.x.248.993: S 3787736038:3787736038(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 2064284084 0,sackOK,eol> (DF) 13:53:41.074554 38.x.x.248.993 > 66.x.x.2.50483: S 1565942120:1565942120(0) ack 3787736039 win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 2681405076 2064284084> (DF) 13:53:41.459434 66.x.x.2.50483 > 38.x.x.248.993: . ack 1 win 65535 <nop,nop,timestamp 2064284084 2681405076> (DF) 13:53:47.028621 66.x.x.2.50483 > 38.x.x.248.993: F 1:1(0) ack 1 win 65535 <nop,nop,timestamp 2064284096 2681405076> (DF) The only thing logged by dovecot is a disconnection event. There is nothing else logged, even with ssl_verbose enabled. Nov 17 14:23:05 colo2 dovecot: imap-login: Disconnected: rip=66.x.x. 2, lip=38.x.x.248, TLS handshake This happens with Thunderbird 1.5.0.4 and 1.5.0.8 on Mac OS X, and Thunderbird 1.5.0.7 on Windows 2000. Any ideas would be greatly appreciated. Thanks, -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net

7 11

[Dovecot] 1.0.rc15 released
by Timo Sirainen 19 Nov '06

19 Nov '06

http://dovecot.org/releases/dovecot-1.0.rc15.tar.gz http://dovecot.org/releases/dovecot-1.0.rc15.tar.gz.sig * Fixed an off-by-one buffer overflow in cache file handling. The code is executed only with mmap_disable=yes and only if index files are used (ie. INDEX=MEMORY is safe). * passdb checkpassword: Handle vpopmail's non-standard exit codes. - rc14 sometimes assert-crashed if .log.2 file existed in a mailbox (earlier versions leaked memory and file descriptors) - io_add() assert-crashfixes - Potential SSL hang fix at the beginning of the connection

1 0

[Dovecot] Security hole #2: Off-by-one buffer overflow with mmap_disable=yes
by Timo Sirainen 19 Nov '06

19 Nov '06

Version: 1.0test53 .. 1.0.rc14 (ie. all 1.0alpha, 1.0beta and 1.0rc versions so far). 0.99.x versions are safe (they don't even have mmap_disable setting). Problem: When mmap_disable=yes setting is used, dovecot.index.cache file is read to memory using "file cache" code. It contains a "mapped pages" bitmask buffer. In some conditions when updating the buffer it allocates one byte too little. Exploitability: I think it's going to be pretty difficult to cause anything else than a crash, but I wouldn't say impossible. Only logged in IMAP/POP3 users can exploit this. In theory you might be able to exploit this for other users as well by sending them a lot of specially crafted emails, but this requires knowing what dovecot.index.cache file contains. Normally its contents can't be predicted, although perhaps with POP3 users it gets empty often enough that the exploit could be tried. Then again, the exploit requires having at least 4MB cache file, which won't happen with POP3 users before the mailbox has about 170k mails (if I counted right). With IMAP the cache file is used more, so it's easier to fill the 4MB with for example a lot of To-headers. Workaround: Use INDEX=MEMORY so the cache files aren't used at all. Fix: 1.0.rc15 fixes this. You can also use this patch: http://dovecot.org/patches/1.0/file-cache-buffer-overflow-fix.diff

1 0

[Dovecot] I/O leak
by Jim Horner 19 Nov '06

19 Nov '06

I upgraded from rc12 to rc14 last night... sifting through the logs I noticed the following. I point this out since it appears dovecot is in high gear bug-fix mode. This issue is not big for me; I rarely stop dovecot. My init.d script for dovecot is basically stop) killall dovecot imap-login I am guessing there might be a more graceful way to stop dovecot? Or rc14 fixed this? I see in rc14 changelog: - rc13 crashed if client disconnected while IDLEing but only user1 was IDLE. Nov 15 21:53:23 myserver dovecot: IMAP(user1(a)arinbe.com): Disconnected in IDLE Nov 15 21:53:23 myserver dovecot: imap-login: Killed with signal 15 Nov 15 21:53:23 myserver dovecot: IMAP(user2(a)arinbe.com): Disconnected Nov 15 21:53:23 myserver dovecot: imap-login: Killed with signal 15 Nov 15 21:53:23 myserver dovecot: IMAP(user3(a)arinbe.com): Disconnected Nov 15 21:53:23 myserver dovecot: imap-login: Killed with signal 15 Nov 15 21:53:23 myserver dovecot: I/O leak: 0x804d7a0 (17) Nov 15 21:53:23 myserver dovecot: I/O leak: 0x804d7a0 (15) Nov 15 21:53:23 myserver dovecot: I/O leak: 0x804d7a0 (19) Nov 15 21:53:30 myserver postfix/master[31974]: terminating on signal 15 Nov 15 21:54:02 myserver dovecot: Dovecot v1.0.rc14 starting up Jim

2 2

[Dovecot] 1.0.rc14 released
by Timo Sirainen 19 Nov '06

19 Nov '06

http://dovecot.org/releases/dovecot-1.0.rc14.tar.gz http://dovecot.org/releases/dovecot-1.0.rc14.tar.gz.sig More fixes. "Duplicate header extension keywords" is the only known problem (or if I forgot something, remind me). I'll try to figure out a way to reproduce it easily and then get it fixed. * LDAP: Don't try to use ldap_bind() with empty passwords, since Windows 2003 AD skips password checking with them and just returns success. * verbose_ssl=yes: Don't bother logging "syscall failed: EOF" messages. No-one cares about them. + Dovecot sources should now compile without any warnings with gcc 3.2+ - rc13 crashed if client disconnected while IDLEing - LDAP: auth_bind=yes fixes - %variables: Fixed zero padding handling and documented it. %0.1n shouldn't enable it, and it really shouldn't stay for the next %variable. -sign also shouldn't stay for the next variable. - Don't leak opened .log.2 transaction logs. - Fixed a potential hang in IDLE command (probably really rare). - Fixed potential problems with client disconnecting while master was handling the login. - quota plugin didn't work in Mac OS X

4 7

[Dovecot] quota plugin enhancement request
by Michael Tibben 19 Nov '06

19 Nov '06

Hi am having a small issue with the quota plugin In Squirrelmail when a message is deleted, it seems to be copied to the Trash folder *before* it is deleted from the current folder. However if it is a large message being deleted and the mailbox is close to its quota limit, it means dovecot will deny the copy operation as the quota will be exceeded if the message is copied Because of this, I am wondering if it is possible to have an option for the quota plugin to track, but not enforce the quota. This is because I don't require quota enforcement on IMAP, as Postfix will enforce quota on incoming mail anyway. I hope this makes sense... Michael

5 6