- dovecot - dovecot.org

[dovecot] mbox & Maildir
by james broermann 18 Jan '03

18 Jan '03

Hi, Is it possible for a client to read both mbox and Maildir formats from one server running dovecot? Without changing default_mail_env in dovecot.conf, Maildir folders are working ... they're located in ~/Maildir. No /var/mail/username exists. I have mbox format folders in ~/mail and have been trying to get pine to find them by adding pine folder collections. I always end up back in ~/Maildir, though. Thanks, Jim

2 1

[dovecot] 0.99.7 out
by Timo Sirainen 17 Jan '03

17 Jan '03

This one seems to be actually working. Also rewrote doc/index.txt in case someone is interested.

3 7

[dovecot] 0.99.6 buggy
by Timo Sirainen 14 Jan '03

14 Jan '03

Just a note, the hash table code in it was still buggy. Especially with maildir it could leave the processes to infinite loop. Have to think a bit more how to fix this properly..

1 0

[dovecot] security audit of the code
by seth vidal 14 Jan '03

14 Jan '03

Timo, I know that you're taking an effort to make sure that dovecot is written securely, but I was wondering if you've asked any third party to audit the code yet. I don't have the skills necessary to do this but I bet there is someone out there who does and might be willing to do so. -sv

5 7

[dovecot] 0.99.6 released
by Timo Sirainen 14 Jan '03

14 Jan '03

Several bugfixes since 0.99.6rc3. Here's again the change summary since 0.99.5: v0.99.6 2003-01-13 Timo Sirainen <tss(a)iki.fi> + THREAD=REFERENCES extension support. ORDEREDSUBJECT would be easy to add, but I think it's pretty useless. + SORT is much faster now. + mbox: If ~/mail directory isn't found, create it. + Log login usernames * Some coding style changes (less typedefs) - Mails with nested MIME parts might have caused incorrect BODY and BODYSTRUCTURE fetches and sometimes might have crashed dovecot (assert at imap-bodystructure.c). If client had already successfully done the BODY fetching a couple of times, the bug couldn't happen anymore since Dovecot then began caching the BODY data. So, this mostly happened with new users. - non-UID SEARCH might gave wrong replies in certain conditions. - SORT replied always with UIDs instead of sequences. - If authentication was aborted by client ("*" reply to AUTHENTICATE), the login process crashed later. - STATUS command gave invalid reply for mailboxes with spaces in name - Timezones were parsed wrong with message dates - Digest-MD5: We used "qop-options" instead of "qop", which was incompatible with at least Cyrus SASL. - Realms in passwd-file were buggy - Literals didn't work when logging in - Crashed if it had to wait for mbox lock - With invalid configuration auth and login processes were just dying and master filling log files infinitely. - We didn't work with some 64bit systems

1 0

[dovecot] dovecot-0.99.6rc3 compilation problems on (Open|Free)BSD
by Johan Fredin 13 Jan '03

13 Jan '03

Hi there! Dovecot-0.99.6rc3 barfs at me when I try to compile it on OpenBSD 3.2 or FreeBSD 4.7, both with the same error: [ ..snip.. ] gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/lib -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -c charset-iconv.c gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/lib -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -c charset-utf8.c charset-utf8.c:42: storage size of `ascii_translation' isn't known charset-utf8.c:42: storage size of `utf8_translation' isn't known *** Error code 1 Stop in /usr/home/griffin/dovecot-0.99.6rc3/src/lib-charset. *** Error code 1 Stop in /usr/home/griffin/dovecot-0.99.6rc3/src (line 134 of Makefile). *** Error code 1 Stop in /usr/home/griffin/dovecot-0.99.6rc3 (line 202 of Makefile). *** Error code 1 Stop in /usr/home/griffin/dovecot-0.99.6rc3 (line 330 of Makefile). I didn't use any fancy parameters for ./configure. Any config.* files I can post to help? /Regards, Johan

2 3

[dovecot] 0.99.6rc3
by Timo Sirainen 13 Jan '03

13 Jan '03

Well, "release candidate" wasn't really right name for last two versions. Maybe not for this one either, it has a few changes that could potentially break things badly (new hash table code especially). Anyway, seems to work with me. If I don't see any problems with it for a few days it'll be the final. The really great news is that we support threading. A lot of people have not used Dovecot simply because it couldn't be used for webmails. Hmm. What's the next most important feature? .. Better mbox support? Shared folders? Quota? LDAP/MySQL/etc. authentication? Here's the change summary: v0.99.6 2003-01-xx Timo Sirainen <tss(a)iki.fi> + THREAD=REFERENCES extension support. ORDEREDSUBJECT would be easy to add, but I think it's pretty useless. + SORT is much faster now. + mbox: If ~/mail directory isn't found, create it. + Log login usernames * Some coding style changes (less typedefs) - Mails with nested MIME parts might have caused incorrect BODY and BODYSTRUCTURE fetches and sometimes might have crashed dovecot (assert at imap-bodystructure.c). If client had already successfully done the BODY fetching a couple of times, the bug couldn't happen anymore since Dovecot then began caching the BODY data. So, this mostly happened with new users. - non-UID SEARCH might gave wrong replies in certain conditions. - SORT replied always with UIDs instead of sequences. - If authentication was aborted by client ("*" reply to AUTHENTICATE), the login process crashed later. - STATUS command gave invalid reply for mailboxes with spaces in name - Timezones were parsed wrong with message dates - Digest-MD5: We used "qop-options" instead of "qop", which was incompatible with at least Cyrus SASL. - Realms in passwd-file were buggy - Literals didn't work when logging in - Crashed if it had to wait for mbox lock - With invalid configuration auth and login processes were just dying and master filling log files infinitely. - We didn't work with some 64bit systems

2 4

[dovecot] Failed to create storage
by M 10 Jan '03

10 Jan '03

Hi, I'm impressed so far, I tested this before trying to run it on a mail server and it worked find. However on the mail server with the same config I get the following message when I try and authenticate, and it drops the connection. Failed to create storage with data: mbox:/var/mail/martin The test box is running debian unstable and the mail server is running debian stable so I had to recompile and install. I'm failry sure that I got all the permissions right, I feel like I'm missing something obvious, can anyone advise? The file and permissions on the mailbox look right: -rw-rw---- 1 martin mail 14743740 Jan 10 06:29 /var/mail/martin -- Thanks, M

2 2

[dovecot] Re: Thread extension
by Timo Sirainen 10 Jan '03

10 Jan '03

On Fri, 2003-01-10 at 06:00, Jonas Smedegaard wrote: > > Also it looks like I've found a couple of bugs in uw-imap and courier's > > implementation.. > > Something you want to reveal? Well, one was just my misunderstanding of the specs, but another still exists: These should be grouped together, but aren't: Subject: =?iso-8859-1?Q?foo?= Subject: =?iso-8859-1?Q?RE=3A_foo?= UW doesn't seem to handle MIME encoded-words properly. I mentioned this already to Mark Crispin who apparently has a lot to do with UW's code. I didn't look too closely at Courier's output, except it was somewhat different from Dovecot's. Also, Crispin said it was totally broken.

1 0

[dovecot] Thread extension
by Timo Sirainen 10 Jan '03

10 Jan '03

Just figured I'd mention that CVS supports now THREAD extension. I also did a bit of benchmarking using a folder with 4685 mails (evolution mailing list): dovecot+mbox: - 0.59s user 0.01s system 98% cpu 0.608 total - malloc() memory usage 45072 -> 825685 dovecot+maildir: - 0.60s user 0.17s system 98% cpu 0.780 total - malloc() memory usage: 45003 -> 825480 Meaning it takes almost 800kbytes of memory and it's quite fast :) Comparing to other servers then: uw-imap: - 1.11s user 0.27s system 100% cpu 1.376 total - malloc() memory usage: 529408 -> ~4348k courier: - 7.27s user 0.28s system 99% cpu 7.567 total - malloc() memory usage: 181689 -> ~850k cyrus: - 1.403 total (through TCP connection, I couldn't figure out how to start it separately) Whoa, we beat everyone :) Courier uses a bit less memory though, but that's most likely because we allocate it in larger chunks which is faster. I ran the tests several times and picked the best values, although the changes were minimal once they got the messages into OS's cache. Also it looks like I've found a couple of bugs in uw-imap and courier's implementation..

1 0