- dovecot - dovecot.org

[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

[dovecot] Re: Logging suggestions?
by Jesse Peterson 09 Jan '03

09 Jan '03

-------- Original Message -------- From: - Wed Jan 08 15:28:42 2003 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 Message-ID: <3E1CB429.3040704(a)attbi.com> Date: Wed, 08 Jan 2003 15:28:41 -0800 From: Jesse Peterson <jpeterson275(a)attbi.com> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020901 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timo Sirainen <tss(a)iki.fi> Subject: Re: [dovecot] Re: Logging suggestions? References: <1042022871.28651.93.camel@hurina> <20030108175006.GB27418(a)dust.uchicago.edu> <20030108181142.GB12010(a)talsever.com> <1042066760.28651.144.camel@hurina> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Timo Sirainen wrote: > > Something like that, yes. I'd like to avoid adding too many (mostly) > useless options though. > Make it customizable! =) Maybe something similar to Apache LogFormat-style or similar? Just a suggestion, -- Jesse Peterson / jesse(a)pixeltechs.com -- Jesse Peterson / jesse(a)pixeltechs.com

1 0

[dovecot] Logging suggestions?
by Timo Sirainen 09 Jan '03

09 Jan '03

Any suggestions how user login/logouts should look like in log files? I was thinking: (connected to imaps port) Login: username [IP 1.2.3.4, imaps, compressed] Logout: username [IP 1.2.3.4, imaps, compressed] [1000/100000 bytes (50%), 00:00:12] Bytes being upload/download and the 50% meaning compression ratio for downloaded bytes, probably not worth it for upload. Or if uncompressed, it'd show the extra space used by SSL/TLS protocol: (using STARTTLS) Login: username [IP 1.2.3.4, TLS] Logout: username [IP 1.2.3.4, TLS] [2020/202000 bytes (101%), 00:00:12] (no SSL) Login: username [IP 1.2.3.4] Logout: username [IP 1.2.3.4] [2000/200000 bytes, 00:00:12] I think the only configuration needed would be if to log login, logout or both.

4 6

[dovecot] Bug#175509: dovecot: init.d script should add some syslog statements on startup/shutdown (fwd)
by Jaldhar H. Vyas 08 Jan '03

08 Jan '03

[Amelia and Timo. As you are both on the dovecot list, I'm replying there to avoid cluttering up your inboxes.] This bug was reported to Debian but I feel it should be fixed upstream. Adding logging in th init script itself would require adding additional dependencies to the package and not be as convenient. ---------- Forwarded message ---------- From: Amelia A Lewis <amyzing(a)talsever.com> It would be nice if the init.d script could add some statements in the system log on startup and shutdown. For postfix, postfix-script (called from the init script) uses: starting the Postfix mail system stopping the Postfix mail system These are useful; one can start the daemon and check that it's initialized (netstat works as well, I suppose, but this is still useful docco). -- Jaldhar H. Vyas <jaldhar(a)debian.org>

2 1

[dovecot] Re: Bug#175507: dovecot: Accidental denial of service via syslog
by Jaldhar H. Vyas 08 Jan '03

08 Jan '03

This bug was reported to Debian but I feel it is an upstream issue. On Sat, 4 Jan 2003, Amelia A Lewis wrote: > If dovecot is misconfigured, such that imap-auth cannot find passwd.imap > (which probably needs to get copied; maybe need more docco in the config > file? This happens if the digest-md5 auth method is uncommented and the > auth_userinfo is set to passwd-file /etc/passwd.imap), imap-auth dies once a > second with error 89, which it reports to imap-master, and both log to > syslog. > > I've got 30,000 line pairs from a ten hour run. I would think that if it > dies more than, say, a thousand times in a single hour, imap-master maybe > ought to consider that there's a serious configuration problem preventing > use, and exit instead of continuing to fill the log. > > Granted, it's a shoot-yourself sort of error. But still ... after a certain > point, the program ought to be able to die *gracefully* if the sysadmin has > shot it, by accident or not. > Personally, I would be even stricter than Amelia is suggesting. If there is a serious configuration error, dovecot should die immediately. -- Jaldhar H. Vyas <jaldhar(a)debian.org>

2 1

[dovecot] Bug reports from Debian BTS
by Jaldhar H. Vyas 08 Jan '03

08 Jan '03

Timo, Are you (or any other interested list readers for that matter) interested in directly receiving bug reports about dovecot sent to Debian? If you are, you can go to http://packages.qa.debian.org/d/dovecot.html and sign up to have notifications sent to you or the list or wherever. Or I can screen them and only send you ones I think are relevant as I'm doing now. -- Jaldhar H. Vyas <jaldhar(a)debian.org> It's a girl! See the pictures - http://www.braincells.com/shailaja/

1 0

[dovecot] 0.99.6rc1 released
by Timo Sirainen 07 Jan '03

07 Jan '03

Again rc, just in case I broke something. Or maybe I should just start creating nightly CVS snapshots. Anyway, fixes the few bugs people have reported lately: - 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. - If authentication was aborted by client ("*" reply to AUTHENTICATE), the login process crashed later. - Digest-MD5: We used "qop-options" instead of "qop", which was incompatible with at least Cyrus SASL. - We didn't work with some 64bit systems - Realms in passwd-file were buggy * Some coding style changes (less typedefs)

2 2