- dovecot - dovecot.org

[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

[Dovecot] Is "Resource temporarily unavailable" an old problem?
by Ricardo Dias Campos 19 Nov '06

19 Nov '06

Hi. I've installed dovecot recently in a Fedora 5 Linux. It seemed to be OK but I begun to get the message "Can't connect to auth server at default: Resource temporarily unavailable". When I get the message, dovecot hangs. The problem is that "temporarily" is not quite true since the only way to get dovecot running again is to restart it. As a matter of fact, I cannot say that it never recovers. What I know is that it is out for a long, long time. Then a new problem arose: the time between hang-ups begun to diminish. Trying to find why I discovered that the number or dovecot-auth processes was too high (last time I got 169 processes, a lot of them <defuncts>). It seems that, if I kill all these processes, it takes more time before it hangs again. I looked up for messages in the Internet and I found a mail exchange between people from this list. The first hint I got was to upgrade dovecot. As I said, I'm using Fedora 5 and the version distributed with it was dovecot-1.0-0.beta2.7.i386. I upgraded it to dovecot-1.0-0.beta8.2.fc5.i386. I couldn't make any direct relantionship between this versions and the ones in dovecot site so I cannot tell what dovecot version I'm using in terms of dovecot site versioning. Any help is welcome. Thanks, Ricardo

3 3

[Dovecot] CHANGE REQUEST: Move config files out of main $sysconfdir
by Brian G. Peterson 19 Nov '06

19 Nov '06

Currently, dovecot places it's config files in $sysconfdir In Makefile.am, this is defines as: confdir = $(sysconfdir) It would be far more friendly to an already overloaded /etc/ directory, and easier to locate the files, to follow the now-common convention and place files in $sysconfdir / dovecot / ... on most systems this would mean: /etc/dovecot/ If there is only a dovecot.conf, it doesn't really matter, but when additional config files get added for ldap, sql, sieve, it starts to add up. Some distributions already make this change, but placing this change in the dovecot core would make it unnecessary for downstream packagers to make a change to the core dovecot distribution files. Regards, - Brian

3 2