- dovecot - dovecot.org

[Dovecot] Debian woody backport of 0.99.10.6 now available on backports.org
by Jaldhar H. Vyas 10 Jul '04

10 Jul '04

Well, the backports.org people finally installed my backport of the latest stable version of dovecot. Please remove the Braincells apt source form /etc/apt/sources.list and add these lines instead. deb http://www.backports.org/debian stable dovecot openldap2 postgresql openssl deb-src http://www.backports.org/debian stable dovecot (If you are using other backports you can merge dovecot etc. into an existing line.) I have also updated the wiki. If there are any other places which mention the old location, please change them. -- Jaldhar H. Vyas <jaldhar(a)debian.org> La Salle Debain - http://www.braincells.com/debian/

1 1

[Dovecot] NUL characters in POP3 conversation cause Outlook to hang
by Matthew Reimer 10 Jul '04

10 Jul '04

We're being bitten an Outlook bug [1,2] that is triggered by a NUL character in a message being sent through POP3. I see that dovecot's imap implementation converts 0x00 to 0x80, but this conversion is not done for POP3. Would it be possible to add an option to do this mapping for POP3 as well? Matt [1] http://xforce.iss.net/xforce/xfdb/15859 [2] http://www.derkeiler.com/Mailing-Lists/NT-Bugtraq/2004-04/0014.html

2 1

[Dovecot] pop3 usernames
by Vlad Mazek 10 Jul '04

10 Jul '04

Hello, I would like to allow users to login as user(a)domain.tld instead of providing their login name; I'm coming from the sendmail/qpopper land and am trying to migrate to postfix/maildir/dovecot one step at a time and I've been able to find a way to do most of what I want except for the above requirement. Do I have to use a SQL server or is there any way to easilly map an email address to a mailbox or even a maildir? Thank you. -Vlad

2 1

[Dovecot] permission problem ??
by Joachim Dostal 09 Jul '04

09 Jul '04

version dovecot-1.0-test27: Jul 9 21:49:07 server dovecot: IMAP(testtest): mprotect() failed with index file /home/testtest/mail/.imap/INBOX/dovecot.index: Permission denied with version 0.99.10.6 i have no such troubles ... ? tx4hlp, joachim

2 3

[Dovecot] Re : Permission denied
by Frédéric Sapin 09 Jul '04

09 Jul '04

Hello Timo, I'm using linux Fedora Core 2. The permissions are : drwxrwxrwt 2 root mail 32 2004-06-16 04:45 /var/spool/mail/ These permissions are made buy the command chmod a+rwxt /var/spool/mail. So if someone wants to erase the /var/spool/mail directory, it's possible unfortunately. If there are theses permissions the user can receive his mails but it's dangerous I think. And if I modify the dovecot.conf file : mail_extra_groups = mail and if the permissions are the initial permission, and if I enter chmod +t /var/spool/mail the user can't receive his mail. Thanks Frederic

4 6

[Dovecot] bug in openssl proxy code (1.0-test24) ?
by Andrey Panin 09 Jul '04

09 Jul '04

Hi all, If client connects to pop3 server, issues STLS command and then drops connection dovecot starts flooding syslog with this message repeated endlessly: Jul 9 14:31:40 smtp dovecot: pop3-login: SSL_accept() syscall failed: EOF [80.254.111.9] Best regards. -- Andrey Panin | Linux and UNIX system administrator pazke(a)donpac.ru | PGP key: wwwkeys.pgp.net

2 3

[Dovecot] passing remote ip to pam
by dean gaudet 09 Jul '04

09 Jul '04

to improve forensic log info i want to set the PAM_RHOST value to the remote ip (which pam logs as rhost=foo in failure messages). i didn't look to see if anything has been done in this way on CVS because i'm still on 0.99.10.6. below is a bit of a hack. in some sense the remote_ip might make more sense in the AUTH_LOGIN_REQUEST_NEW packet rather than the continue packet... but that looked like i'd have to change more code :) btw -- is there anything which stops mech_plain_auth_continue from doing a somewhat unbounded pstrdup if you send "a\0b" for the auth string? -dean diff -rpu dovecot-0.99.10.6.deborig/debian/changelog dovecot-0.99.10.6/debian/changelog --- dovecot-0.99.10.6.deborig/debian/changelog 2004-07-08 18:11:55.000000000 -0700 +++ dovecot-0.99.10.6/debian/changelog 2004-07-08 18:34:40.000000000 -0700 @@ -1,3 +1,9 @@ +dovecot (0.99.10.6-3.dg1) unstable; urgency=low + + * hack a solution to pass PAM_RHOST the remote ip + + -- dean gaudet <dean(a)arctic.org> Thu, 8 Jul 2004 18:34:26 -0700 + dovecot (0.99.10.6-3) unstable; urgency=low * Patched so dovecot follows symlinks to directories again. diff -rpu dovecot-0.99.10.6.deborig/src/auth/auth-login-interface.h dovecot-0.99.10.6/src/auth/auth-login-interface.h --- dovecot-0.99.10.6.deborig/src/auth/auth-login-interface.h 2003-05-18 05:26:28.000000000 -0700 +++ dovecot-0.99.10.6/src/auth/auth-login-interface.h 2004-07-08 18:32:22.000000000 -0700 @@ -1,6 +1,8 @@ #ifndef __AUTH_LOGIN_INTERFACE_H #define __AUTH_LOGIN_INTERFACE_H +#include "network.h" + /* max. size for auth_login_request_continue.data[] */ #define AUTH_LOGIN_MAX_REQUEST_DATA_SIZE 4096 @@ -57,6 +59,8 @@ struct auth_login_request_continue { enum auth_login_request_type type; /* AUTH_LOGIN_REQUEST_CONTINUE */ unsigned int id; + struct ip_addr remote_ip; + size_t data_size; /* unsigned char data[]; */ }; diff -rpu dovecot-0.99.10.6.deborig/src/auth/mech-plain.c dovecot-0.99.10.6/src/auth/mech-plain.c --- dovecot-0.99.10.6.deborig/src/auth/mech-plain.c 2003-05-18 05:26:28.000000000 -0700 +++ dovecot-0.99.10.6/src/auth/mech-plain.c 2004-07-08 18:25:14.000000000 -0700 @@ -21,6 +21,7 @@ mech_plain_auth_continue(struct auth_req size_t i, count, len; auth_request->callback = callback; + auth_request->remote_ip = request->remote_ip; /* authorization ID \0 authentication ID \0 pass. we'll ignore authorization ID for now. */ diff -rpu dovecot-0.99.10.6.deborig/src/auth/mech.h dovecot-0.99.10.6/src/auth/mech.h --- dovecot-0.99.10.6.deborig/src/auth/mech.h 2003-05-18 05:26:28.000000000 -0700 +++ dovecot-0.99.10.6/src/auth/mech.h 2004-07-08 18:31:42.000000000 -0700 @@ -1,6 +1,7 @@ #ifndef __MECH_H #define __MECH_H +#include "network.h" #include "auth-login-interface.h" struct login_connection; @@ -11,6 +12,7 @@ typedef void mech_callback_t(struct auth struct auth_request { pool_t pool; char *user; + struct ip_addr remote_ip; struct login_connection *conn; unsigned int id; diff -rpu dovecot-0.99.10.6.deborig/src/auth/passdb-pam.c dovecot-0.99.10.6/src/auth/passdb-pam.c --- dovecot-0.99.10.6.deborig/src/auth/passdb-pam.c 2003-11-08 06:17:51.000000000 -0800 +++ dovecot-0.99.10.6/src/auth/passdb-pam.c 2004-07-08 18:32:52.000000000 -0700 @@ -166,13 +166,23 @@ static int pam_userpass_conv(int num_msg return PAM_SUCCESS; } -static int pam_auth(pam_handle_t *pamh, const char *user, const char **error) +static int pam_auth(pam_handle_t *pamh, const char *user, + const struct ip_addr *remote_ip, const char **error) { void *item; int status; + const char *addr; *error = NULL; + if ((addr = net_ip2addr(remote_ip)) + && (status = pam_set_item(pamh, PAM_RHOST, addr)) + != PAM_SUCCESS) { + *error = t_strdup_printf("pam_set_item(PAM_RHOST, %s) failed: %s", + addr, pam_strerror(pamh, status)); + return status; + } + if ((status = pam_authenticate(pamh, 0)) != PAM_SUCCESS) { *error = t_strdup_printf("pam_authenticate(%s) failed: %s", user, pam_strerror(pamh, status)); @@ -205,7 +215,8 @@ static int pam_auth(pam_handle_t *pamh, static void pam_verify_plain_child(const char *service, const char *user, - const char *password, int fd) + const char *password, const struct ip_addr *remote_ip, + int fd) { pam_handle_t *pamh; struct pam_userpass userpass; @@ -228,7 +239,7 @@ pam_verify_plain_child(const char *servi str = t_strdup_printf("pam_start(%s) failed: %s", user, pam_strerror(pamh, status)); } else { - status = pam_auth(pamh, user, &str); + status = pam_auth(pamh, user, remote_ip, &str); if ((status2 = pam_end(pamh, status)) == PAM_SUCCESS) { /* FIXME: check for PASSDB_RESULT_UNKNOWN_USER somehow? */ @@ -353,7 +364,7 @@ pam_verify_plain(struct auth_request *re if (pid == 0) { (void)close(fd[0]); - pam_verify_plain_child(service, request->user, password, fd[1]); + pam_verify_plain_child(service, request->user, password, &request->remote_ip, fd[1]); _exit(0); } diff -rpu dovecot-0.99.10.6.deborig/src/imap-login/client-authenticate.c dovecot-0.99.10.6/src/imap-login/client-authenticate.c --- dovecot-0.99.10.6.deborig/src/imap-login/client-authenticate.c 2003-11-24 11:50:55.000000000 -0800 +++ dovecot-0.99.10.6/src/imap-login/client-authenticate.c 2004-07-08 18:21:19.000000000 -0700 @@ -140,7 +140,7 @@ static void login_callback(struct auth_r case 0: /* continue */ ptr = buffer_get_data(client->plain_login, &size); - auth_continue_request(request, ptr, size); + auth_continue_request(request, ptr, size, &client->common.ip); buffer_set_used_size(client->plain_login, 0); break; @@ -270,7 +270,8 @@ static void client_auth_input(void *cont } else { auth_continue_request(client->common.auth_request, buffer_get_data(buf, NULL), - buffer_get_used_size(buf)); + buffer_get_used_size(buf), + &client->common.ip); } /* clear sensitive data */ diff -rpu dovecot-0.99.10.6.deborig/src/login-common/auth-connection.c dovecot-0.99.10.6/src/login-common/auth-connection.c --- dovecot-0.99.10.6.deborig/src/login-common/auth-connection.c 2003-05-26 08:27:13.000000000 -0700 +++ dovecot-0.99.10.6/src/login-common/auth-connection.c 2004-07-08 18:33:38.000000000 -0700 @@ -335,13 +335,21 @@ int auth_init_request(enum auth_mech mec } void auth_continue_request(struct auth_request *request, - const unsigned char *data, size_t data_size) + const unsigned char *data, size_t data_size, + const struct ip_addr *remote_ip) { struct auth_login_request_continue auth_request; /* send continued request to auth */ auth_request.type = AUTH_LOGIN_REQUEST_CONTINUE; auth_request.id = request->id; + if (remote_ip) { + auth_request.remote_ip = *remote_ip; + } + else { + memset(&auth_request.remote_ip, + 0, sizeof(auth_request.remote_ip)); + } auth_request.data_size = data_size; if (o_stream_send(request->conn->output, &auth_request, diff -rpu dovecot-0.99.10.6.deborig/src/login-common/auth-connection.h dovecot-0.99.10.6/src/login-common/auth-connection.h --- dovecot-0.99.10.6.deborig/src/login-common/auth-connection.h 2003-02-09 23:56:23.000000000 -0800 +++ dovecot-0.99.10.6/src/login-common/auth-connection.h 2004-07-08 18:20:58.000000000 -0700 @@ -48,7 +48,8 @@ int auth_init_request(enum auth_mech mec const char **error); void auth_continue_request(struct auth_request *request, - const unsigned char *data, size_t data_size); + const unsigned char *data, size_t data_size, + const struct ip_addr *remote_ip); void auth_abort_request(struct auth_request *request); diff -rpu dovecot-0.99.10.6.deborig/src/pop3-login/client-authenticate.c dovecot-0.99.10.6/src/pop3-login/client-authenticate.c --- dovecot-0.99.10.6.deborig/src/pop3-login/client-authenticate.c 2003-11-24 11:52:09.000000000 -0800 +++ dovecot-0.99.10.6/src/pop3-login/client-authenticate.c 2004-07-08 18:21:32.000000000 -0700 @@ -141,7 +141,7 @@ static void login_callback(struct auth_r case 0: ptr = buffer_get_data(client->plain_login, &size); - auth_continue_request(request, ptr, size); + auth_continue_request(request, ptr, size, &client->common.ip); buffer_set_used_size(client->plain_login, 0); break; @@ -259,7 +259,8 @@ static void client_auth_input(void *cont } else { auth_continue_request(client->common.auth_request, buffer_get_data(buf, NULL), - buffer_get_used_size(buf)); + buffer_get_used_size(buf), + &client->common.ip); } /* clear sensitive data */

2 1

[Dovecot] Permission denied
by Frédéric Sapin 09 Jul '04

09 Jul '04

Hello all, I'm a new user of dovecot and I've got a permission denied problem. I've read the VarMailDotLock wiki paper but there is still a security problem. If I enter : chmod a+rwxt /var/spool/mail it works but I think it's very dangerous to have thaht rights. So I've tried to edit the dovecot.conf file and to change the mail_extra_groups = mail and to change the rights : chmod +t /var/spool/mail but it doesn't work ! The mails are in /var/spool/mail/unix_user_name Could you please help me to configure the /var/spool/mail to have a good security and to allow people to receive their mails ? Thanks Frederic

2 1

[Dovecot] a yum install with mysql support??
by alex＠alution.com 09 Jul '04

09 Jul '04

Hello, Well im guessing i have already answered this question myself. Im using FC1 and installed dovecot the easy way (yum install dovecot) It has stated that it installed version 0.99.10.5 and from what I have looked at in the mailing list archives, this version SHOULD have mysql authentication support. However what I don´t know is if by installing the yum package it will allow this support. Im guessing that I will have to install it the real way, as if I take a look in the logs, it states... ============== dovecot-auth: "Jul 09 00:37:38 "Fatal: Unknown userdb type 'mysql' dovecot: "Jul 09 00:37:38 "Error: Auth process died too early - shutting down dovecot: "Jul 09 00:37:38 "Error: child 31532 (auth) returned error 89 ============== Am i correct in thinking this? Or is there something else a miss?? Thanks Alex

1 0

Re: [Dovecot] 1.0-test26
by Matthew Reimer 09 Jul '04

09 Jul '04

Timo Sirainen wrote: > On 9.7.2004, at 00:57, Mark E. Mallett wrote: > >> On Fri, Jul 09, 2004 at 12:34:04AM +0300, Timo Sirainen wrote: >> >>> http://dovecot.org/test/ >>> >>> - Fixed APPEND hanging if the whole message was sent in one TCP packet >>> (ie. fixes the "Sent mail" hangs) >> >> >> Curious-- how does the application-level code care about TCP packets? > > > It reads all of it into buffer, then later tries to read more even > though everything was already in that buffer so it gets stuck at > waiting. Dovecot's istream-limit wrapper stream specifically was a > problem. It called parent stream's read() function without checking > first if there was already data in it's buffer. > > These wrapper streams have been quite difficult in general. mbox support > is implemented using one of those too and it took quite a while to get > it working correctly. I guess I should write some comments there how > exactly they should be implemented. Is this a problem in 0.99 as well? Matt

2 1

[Dovecot] 1.0-test26
by Timo Sirainen 09 Jul '04

09 Jul '04

http://dovecot.org/test/ - Fixed APPEND hanging if the whole message was sent in one TCP packet (ie. fixes the "Sent mail" hangs) - Some changes in MySQL defaults - Working APOP auth - Fixes/improvements for cache file code. Still isn't as smart as it could, but it seems to work again. The code is nearing a state where plugins could add their own data into cache file.

2 3

Re: [Dovecot] Logging "issue" with PAM authentication
by Steve Johnson 07 Jul '04

07 Jul '04

Great, thanks a lot, solved the problem. No more annoying logs every 2-5 seconds :) Steve Johnson On Wed, 2004-07-07 at 14:39, Ray Miller wrote: > On Wed, Jul 07, 2004 at 02:21:04PM -0400, Steve Johnson wrote: > > > > I've tried with just the following: > > > > auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass > > password sufficient /lib/security/$ISA/pam_ldap.so use_authtok > > session optional /lib/security/$ISA/pam_ldap.so > > [...] > > In both of these situations, users can't authenticate. Is there > > something I'm doing wrong? I'm not that familiar with pam, so it's a > > very plausible cause! :) > > I'm fairly sure you don't need the password line, but that's not > likely to be causing your problem - more likely it's the use_first_pass > option. Try: > > auth required /lib/security/$ISA/pam_ldap.so > account required /lib/security/$ISA/pam_ldap.so > password required /lib/security/$ISA/pam_deny.so > session required /lib/security/$ISA/pam_ldap.so

1 0

[Dovecot] Peer Config Review
by Eric Kahklen 07 Jul '04

07 Jul '04

I am trying to setup a mail server using Postfix and Squirrelmail. The mail server will ONLY use webmail for access. I will not be using any email clients other than Squirrelmail. I've got the server working in a testing environment. Could people who are dovecot savy look over the config I have set? I've only included the directives that are enabled with no comments. I want a simple but secure backup mail server for about 75 users. Thank you, Eric base_dir = /var/run/dovecot/ protocols = imap login_dir = /var/run/dovecot/login login = imap login_executable = /usr/libexec/dovecot/imap-login mbox_locks = fcntl imap_executable = /usr/libexec/dovecot/imap imap_modules = /usr/lib/dovecot/imap auth = default auth_mechanisms = plain auth_userdb = passwd auth_passdb = pam auth_executable = /usr/libexec/dovecot/dovecot-auth auth_user = root --

1 0

[Dovecot] Logging "issue" with PAM authentication
by Steve Johnson 07 Jul '04

07 Jul '04

Hi, We currently have a postfix/dovecot setup using nss_ldap with PAM for authentication. Everything is working fine, but there are excessive "error" messages in /var/log/messages that I'd like to prevent from happening. Since auth_userdb defaults to passwd and that our users are not in the passwd file, we get the following message everytime a user logs in: Jul 7 13:34:37 hostname dovecot(pam_unix)[32206]: check pass; user unknown Jul 7 13:34:37 hostname dovecot(pam_unix)[32206]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= We of course also get the input that a user has logged in, in /var/log/maillog: imap-login: Jul 07 13:34:37 Info: Login: username [xxx.xxx.xxx.xxx] I've tried changing auth_verbose to no, and I still get those messages. Is there any way to prevent this from happening? Thanks a lot, Steve Johnson

2 2

[Dovecot] mbox:~/%u-mail/
by justin 07 Jul '04

07 Jul '04

Is it possible to use something like: default_mail_env = mbox:~/%u-mail/:INBOX=/var/mail/%u such that for a user: user1 with a home directory: /home/share the imap files would then be stored in: /home/share/user1-mail/ ???

2 1

[Dovecot] UID Error on Test 24 and 25
by Doug Eubanks 07 Jul '04

07 Jul '04

I started testing Dovecot 1.0 Test 22! I loved the performance improvements, althought dovecot has been very fast for us from the beginning. However, now I am testing test 24 and 25, and I am seeing these errors in the dovecot log and squirrelmail is giving me a ERROR : Connection dropped by imap-server. Query: STATUS "Mailing Lists.SpamAssassin" (MESSAGES UNSEEN RECENT) This is the dovecot error from the log file dovecot: Jul 07 08:52:33 Info: imap-login: Login: admin [208.*.*.*] dovecot: Jul 07 08:52:33 Error: IMAP(admin): file mail-index-view.c: line 286 (_view_lookup_uid_range): assertion failed: (first_uid > 0) dovecot: Jul 07 08:52:33 Error: child 12469 (imap) killed with signal 6 The user I am loggin in with has a uid and gid of 501, not 0! I am using passwd and shadow auth with Maildirs. If anyone has any pointers, they would greatly be appreciated. Sincerely, Doug Eubanks doug(a)simflex.com Post Hoc, Ergo Propter Hoc *** DISCLAIMER *** This e-mail and any attachments thereto may contain information, which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation.

2 1

[Dovecot] 1.0-test25 with new cache file code
by Timo Sirainen 07 Jul '04

07 Jul '04

http://dovecot.org/test/ Pretty much the only change since test24 is a redesign of how cache file writing works. Reading works as before - without locks. Before (in 1.0-tests, 0.99 was worse) we used to just try to lock it. If it failed, we just didn't update cache. If it didn't fail, the lock could have been kept a long time. For example if a user was downloading a 10MB mail, the lock could have been kept the whole time and no-one else could have modified the cache. The old behaviour wasn't actually too bad, as normally it didn't matter if something couldn't be written to cache. It would have been the next time, all it did was cost some I/O. The new behaviour is more reliable as the locks are kept only a very short time. It works by first writing the updates only into internal 32kB buffer. Once the buffer gets full, or the transaction completes, it's written to disk. When buffer gets full, space is reserved from the cache file for the current transaction. The amount of space is more than is needed for writing the internal buffer, so we don't have to lock the cache file every time the buffer gets full (and so we don't need a huge buffer). Once transaction completes, we lock the cache again and try to free the extra reserved space we have left. If multiple processes weren't updating the cache file at the same time, the freeing should be as simple as decreasing "used_file_size" field in header. Alternatively we'll update a linked list of "holes" in the file. When reserving space, we first try to use those holes instead of appending to end of file. Pointers to new cache records are also written to transaction log at the end of cache transaction. They'll get written to index at next sync after which they become visible to other processes. Each cache record contains a pointer to previous record, so there can be multiple cache records for a single message. The bad thing with the new logic is that nothing prevents two processes from writing the same cache records and so using twice as much space as necessary. But I don't think it's much of a problem. They'll go away at next cache compression. These changes also make it quite simple to make cache file work with shared filesystems. I'd just need to implement some kind of internal caching buffer which remembers what parts of file are read into memory. These changes also make it possible to easily and reliably store X-UIDL headers into cache file, where the POP3 UIDL command could quickly get them. Not in this release yet, though..

3 2

[Dovecot] appenduid?
by Johannes Berg 06 Jul '04

06 Jul '04

Hi, Does dovecot support APPENDUID? If not, would it be possible to add? johannes

2 1

Re: [Dovecot] [PATCH, RFC] add APOP authentication mechanism
by Timo Sirainen 06 Jul '04

06 Jul '04

On 1.7.2004, at 16:26, Andrey Panin wrote: >> + if (strcmp(auth_request->protocol, "POP3")) { >> + if (verbose) >> + i_info("apop(%s): wrong protocol %s", >> get_log_prefix(auth_request), >> + auth_request->protocol); >> + mech_auth_finish(auth_request, NULL, 0, FALSE); >> + return TRUE; >> + } >> >> I don't think there's really any point in checking this? Maybe someone >> really wants to use APOP with another protocol :) > > This will be RFC violation isn't it ? (I'll send a public reply, the last question could need input from others) Well, it's not compatible with any RFC of course, but I don't think it would violate anything? I'd just rather like to avoid unnecessary code bloat. Well, except now that I thought about the logic instead of just the code, there are problems. APOP prevents replay attacks by sending different timestamp in greeting, but you're sending the greeting to dovecot-auth as user input to APOP authentication mechanism. So, a user could simply say "AUTH APOP" and send wanted timestamp as input. One way to fix this would be to disallow APOP mechanism to be used with AUTH command in pop3-login and require that the request was done with POP3 protocol. But I think that's pretty ugly kludge. It also requires that processes connecting to dovecot-auth are trusted, which is something I've tried to avoid as much as possible. So dovecot-auth doesn't really know if it's pop3-login which connects to it.. Better fix would be to get part of the timestamp from dovecot-auth itself. It could send a growing ID number as handshake which would be used as part of the timestamp, and APOP mechanism processing would check that timestamp really contains the ID. So timestamp would be <authid.unixtime@hostname>. That also makes the PID go away, which was another thing I would have suggested. POP3 RFC also says: It is conjectured that use of the APOP command provides origin identification and replay protection for a POP3 session. Accordingly, a POP3 server which implements both the PASS and APOP commands should not allow both methods of access for a given user; that is, for a given mailbox name, either the USER/PASS command sequence or the APOP command is allowed, but not both. But I don't know if there's any nice way to do it, except perhaps by defining APOP password scheme which would actually be plaintext but wouldn't work with anything but APOP authentication. Do any other servers prevent it either?

2 5

[Dovecot] Debian dovecot news
by Jaldhar H. Vyas 04 Jul '04

04 Jul '04

I uploaded 0.99.10.6 to sid. Owing to the importance of the dot lock fix, I've tried to have this pushed to sarge quickly. Let's see how that goes. I've prepared a backport of 0.99.10.6 to woody which should be showing up on www.backports.org soon hopefully. In the meantime, if you desperately need it and don't mind working out dependencies yourself, you can find it at http://www.braincells.com/backports/ I uploaded 1.0test18 to http://src.braincells.com/dovecot-test/ (I'll do test20 tomorrow) I told Timo I'd port dovecot's gnutls support from gnutls7 to gnutls10 but I have absolutely no time for it so if someone would volunteer, contact me, I'd really appreciate it. -- Jaldhar H. Vyas <jaldhar(a)debian.org> La Salle Debain - http://www.braincells.com/debian/

4 7

[Dovecot] index file regeneration?
by Paul Reilly 02 Jul '04

02 Jul '04

Quick question: How does dovecot keep the message headers index file updated? Eg: if my MDA delivers an extra 10 messages while I'm logged in. How does the message index get updated? At what points is it regenerated? Thanks, Paul

2 7

[Dovecot] 1.0-test24 and some mbox benchmarking
by Timo Sirainen 02 Jul '04

02 Jul '04

http://dovecot.org/test/ Again only mbox fixes. I found some more bugs which could have also caused some of the mbox problems that people reported. They were found when I today thought I'd again do a bit of testing with my favourite 1.4GB mbox. Then I thought I might as well see how it compares against UW-IMAP. First a bit of explanations how they work internally: Dovecot 1.0-test24 ------------------ Dovecot works by trying to do everything in one "sync" function. It reads new mails, inserts missing headers, writes header modifications and expunges messages. Dovecot leaves 100 bytes of padding in every mail's headers, which it can use to avoid moving the rest of the file forward when it needs to insert space. However, if there's not enough space (and with new mails there isn't), it needs to do the moving. Moving is done by first reading messages and counting how many bytes we're short. Once we've seen enough padding we'll rewrite those messages. If we read until end of file, we'll grow the file and rewrite the messages. Rewriting is made backwards, so we don't have to do much buffering, and in case the rewriting gets interrupted (crash, power loss, etc.) the data loss is very small, a few kilobytes maximum. UW-IMAP 2004 ------------ UW-IMAP first only reads the mbox with SELECT, rewrite is only triggered by LOGOUT, EXPUNGE and CHECK commands. UW-IMAP also inserts padding, but less than Dovecot. It tries to get added headers to fit into 50 bytes, and what's not used is left as padding. Normally this seems to get it around 15-20 bytes of padding. Perhaps I should shrink it from Dovecot too. Rewriting works by reading the file forward into buffer and writing the changes as needed. This is quite fast, but it means the buffer can grow large, and if the rewrite gets interrupted everything in the buffer gets lost. In my test mbox this would have been 23MB of lost data, but normally much less. Benchmarks ---------- I simply rewrote a 1.4GB mbox containing 361052 mails, Linux kernel mailing list archives from years 96-02. Computer is Athlon XP 2700+ with 1GB of memory. reads/writes were counted using Linux's iostat command. Nothing else was being used in that partition, so the numbers should be accurate. Except UW-IMAP's read count is a few blocks too much because I got tired of waiting it and started looking into the mbox to see how far it had gotten. Read counts could also be somewhat wrong if some of the mbox was already in buffer cache. I tried to trash it anyway by catting 2x4GB of data into /dev/null. Kernel used around 900MB of memory for caching. Total CPU times may also be a bit off, as the computer was being used at the same time. Dovecot 1.0-test24 ------------------ reads : 4007432 blocks = 1956 MB writes: 2947381 blocks = 1439 MB original mbox : 1420611590 B = 2774632 blocks = 1354 MB rewritten mbox: 1472684487 B = 2876336 blocks = 1404 MB indexes : 14452732 B = 28227 blocks = 14 MB 7221164 dovecot.index 10436 dovecot.index.cache 7221132 dovecot.index.log (this will be truncated after a while) - 16064 VSZ, 8012 RSS after SELECT completed - 14MB is mmaped index files - 216kB heap left of which 70kB actually in use - heap usage was 25MB VSZ/RSS constantly while syncing, but allocations were so large that libc used anonymous mmap()s so they got dropped after sync - VSZ peaked at 32MB, most likely because index file(s) were temporarily being mmap()ed more than once - 63.37s user - 16.56s system - 24% cpu - 5:22.75 total UW-IMAP 2004 ------------ Reading: - memory: 70044 VSZ, 67724 RSS - CPU: 7s user, 53s total Totally: reads : 5549640 blocks = 2709 MB writes: 2875581 blocks = 1404 MB original mbox : 1420611590 B = 2774632 blocks = 1354 MB rewritten mbox: 1444411190 B = 2821115 blocks = 1377 MB - 93416 VSZ, 91120 RSS - 2295.81s user - 23.99s system - 96% cpu - 39:57.90 total Notes ----- Not counting Dovecot's indexes UW-IMAP wrote 21MB less. But Dovecot wrote 27MB more padding, so just by shrinking it Dovecot would have written 6MB less data. Also because Dovecot writes the file backwards, it needs to do some extra jumping around and overlapping writes, but I guess OS nicely merged them. I'm not exactly sure why UW-IMAP uses so much CPU for rewriting, but it does and so Dovecot is over 7x faster in total (with 36x less CPU). Dovecot should also support delaying the rewrite. This is mostly useful for POP3 clients which deletes all the mail at logout, so they won't need the rewriting at all. Dovecot also writes all flag changes to disk immediately while UW-IMAP leaves it later to do more at once. That results in less total I/O as well.

1 0

[Dovecot] 1.0-test22 - maildir fixed?
by Timo Sirainen 02 Jul '04

02 Jul '04

http://dovecot.org/test/ Well, remember when I said: > Here you go, maildir syncing problems finally fixed (I hope). Well, > except there's this "new-dir-only syncing" optimization which I'm not > really sure if it works as it should. Just before I found the expunge bug in index, I was trying to fix the new-dir-only syncing because the code looked wrong. Then I figured out the indexing problem and thought maybe this one wasn't broken after all, and then forgot about it. Finally after lots of debugging, I came to same conclusion again. The code was wrong, and cause of the remaining "Maildir sync: UID < next_uid (312 < 3)" errors. So, please try and see if you still can break this release. Other changes include some crashfixes for cache file and fix for mbox which kept constantly rewriting headers for \recent messages if we had selected the mailbox as read-only (EXAMINE, STATUS).

11 30

[Dovecot] building dovecot 1.0 test19 over fc1
by Luis Miguel Cruz 02 Jul '04

02 Jul '04

[root@fc1-devel tmp]# rpmbuild -ta dovecot-1.0-test19.tar.gz error: line 7: Illegal char '-' in version: Version: 1.0-test19 Seems to be an error into the .spec file I am not sure. I will check it. Did anyone get this problem in the past? Thanks.

2 1

[Dovecot] 1.0-test23 and caching decisions
by Timo Sirainen 30 Jun '04

30 Jun '04

http://dovecot.org/test/ mbox fixes mostly. Began some other things, but none of them actually work yet: - Use X-UIDL header in mboxes for POP3 UIDL list - Cache file compression - Some cleverness for cache file for figuring out what to cache Well, I might as well explain the last one now. Users can be divided to three groups: 1. Most users will use only a single IMAP client which caches everything locally. For these users it's quite pointless to do any kind of caching as it only wastes disk space. That might also mean more disk I/O. 2. Some users use multiple IMAP clients which cache everything locally. These could benefit from caching until all clients have fetched the data. After that it's useless. 3. Some clients don't do permanent local caching at all. For example Pine and webmails. These clients would benefit from caching everything. Some locally caching clients might also access some data from server again, such as when searching messages. They could benefit from caching only these fields. After thinking about these a while, I figured out that people who care about performance most will be using the upcoming Dovecot LDA anyway which updates the indexes/cache immediately. In that case even the first user group would benefit from caching the same way as second group. LDA reads the mail anyway, so it might as well extract some information about it and store them into cache. So, group 1. and 2. could be optimally implemented by keeping things cached only for a while. I thought a week would be good. When cache file is compressed, everything older than week will be dropped. But how to figure out if user is in group 3? One quite easy rule would be to see if client is accessing messages older than a week. But with only that rule we might have already dropped useful cached data. It's not very nice if we have to read and cache it twice. Most locally caching clients always fetch new messages (all but body) when they see them. They fetch them in ascending order. Noncaching clients might fetch messages in pretty much any order, as they usually don't fetch everything they can, only what's visible in screen. Some will use server side sorting/threading which also makes messages to be fetched in random order. Second rule would then be that if a session doesn't fetch messages in ascending order, the fetched field type will be permanently cached. So, we have three caching decisions: 1. Don't cache: Clients have never wanted the field 2. Cache temporarily: Clients want this only once 3. Cache permanently: Clients want this more than once Different mailboxes have different decisions. Different fields have different decisions. There are some problems, such as if a client accesses message older than a week, we can't know if user just started using a new client which is just filling it's local cache for the first time. Or it might be a client user hasn't just used for over a week. In these cases we shouldn't have marked the field to be permanently cached. User might also switch clients from non-caching to caching. So we should re-evaluate our caching decisions from time to time. This is done by checking the above rules constantly and marking when was the last time the decision was right. If decision hasn't matched for two months, it's changed. I picked two months because people go to at least one month vacations where they might still be reading mails, but with different clients.

1 0