- dovecot - dovecot.org

[Dovecot] Anyone using Dovecot LDA on OS X?
by Dean Blackburn 15 May '06

15 May '06

I'm curious if anyone can get the LDA running on OS X, and what their experiences have been... We are still having index corruption issues that result in many temp files being created and client-side timeouts using a straight Postfix local delivery under 1.0beta7. The LDA does not come packaged with the Darwinports version of Dovecot, so any tips on compiling it would be most appreciated... Thanks, -deano

1 0

[Dovecot] dovecot ldap auth bind and different directories
by Andrew Bates 15 May '06

15 May '06

I have recently begun playing with Dovecot (1.0.beta8) and have run into an interesting scenario. The way my email system is set up is that users of different domains have completely different base dn's. For instance, if a user is part of test.com the bind dn would be uid=user,ou=People,dc=test,dc=com. The bind dn for user(a)domain.com would be uid=user,ou=People,dc=domain,dc=com. I could not seem to figure out a way to have the binddn adjusted based on a user's @domain so I modified auth-request.c and var-expand.c to include a new variable expansion concept. In the configuration I'm now able to include the following: auth_bind_userdn = uid=%n,ou=People,dc=%c2,dc=%c1 and %c1 will be expanded to the tld, %c2 will be expanded to the next level domain (domain or test in the above example). This will work up to 9 levels of subdomain (1-9). This is very similar in how postfix expands variables with ldap. I'm a bit rusty with my C, so I'd love some feedback on the patch. If this idea isn't included in the main code, that's fine, but I thought I'd contribute my experiences! Thanks for a great product everyone! Andrew =================================================================== --- dovecot-1.0.beta8/src/auth/auth-request.c 2006-04-12 22:00:06.000000000 -0400 +++ dovecot-1.0.beta8.new/src/auth/auth-request.c 2006-05-15 12:37:06.000000000 -0400 @@ -852,6 +852,7 @@ auth_request_get_var_expand_table(const struct auth_request *auth_request, const char *(*escape_func)(const char *)) { + char *str; static struct var_expand_table static_tab[] = { { 'u', NULL }, { 'n', NULL }, @@ -869,7 +870,27 @@ if (escape_func == NULL) escape_func = escape_none; - tab = t_malloc(sizeof(static_tab)); + /* count the number of domain components + in the given auth_request->user string + so we can allocate the correct sized + array + */ + int dc_count = 0; + str = strchr(auth_request->user, '@'); + while (str != NULL && *str != '\0' && str++) { + if (*str == '.') + dc_count++; + if (dc_count == 9) + break; + } + + /* allocate memory big enough for the static + tab plus each domain compononet. Since we + can only use 1-9 as identifiers, there is + no point in allocating more then 9 + */ + dc_count = (dc_count < 9 ? dc_count : 9); + tab = t_malloc(sizeof(static_tab) + (dc_count*(sizeof(char) + sizeof(char *)))); memcpy(tab, static_tab, sizeof(static_tab)); tab[0].value = escape_func(auth_request->user); @@ -886,6 +907,27 @@ tab[7].value = dec2str(auth_request->client_pid); if (auth_request->mech_password != NULL) tab[8].value = escape_func(auth_request->mech_password); + + char *domain = p_strdup(auth_request->pool, strchr(auth_request->user, '@')); + if (domain != NULL) { + int count = 0; + str = domain + strlen(domain); + do { + str--; + if (*str == '.' || *str == '@') { + *str = '\0'; + count++; + tab[count + 8].key = (char)(48+count); + tab[count + 8].value = escape_func(str+1); + } + if (*str == '@') { + count++; + tab[count + 8].key = '\0'; + tab[count + 8].value = NULL; + break; + } + } while (str != domain && count < 9); + } return tab; } =================================================================== --- dovecot-1.0.beta8/src/lib/var-expand.c 2006-04-12 22:00:06.000000000 -0400 +++ dovecot-1.0.beta8.new/src/lib/var-expand.c 2006-05-12 17:06:42.000000000 -0400 @@ -162,6 +162,11 @@ break; var = NULL; + + /* domain component expansion */ + if (*str == 'c') + str++; + for (t = table; t->key != '\0'; t++) { if (t->key == *str) { var = t->value != NULL ? t->value : "";

2 1

[Dovecot] re: ssl-build-param
by Jackie Hunt 15 May '06

15 May '06

Hi all, I posted a message last week about a problem with ssl-build-param, shown below. I may have a lead on this, and was hoping someone can confirm my theory. On AIX, a malloc of 0 bytes returns NULL, which is different than on Solaris and HP-UX (and probably Linux?) I'm guessing the NULL pointer returned is causing the abort of the ssl-build-param, since that was an unexpected result. Looking briefly at the code in ssl-init-openssl.c that seems reasonable. Can anyone please confirm this? And if so, any suggestions on the best way to proceed? Thanks much, Jackie --- Jackie Hunt ACNS Voice: (970) 663-3789 Colorado State University FAX: (970) 491-1958 Fort Collins, CO 80523 Email: jackie.hunt(a)colostate.edu > I'm trying to get dovecot up and running on an AIX 5.2 system > with openssl 0.9.8a. Everything compiles fine, but when I start > dovecot I find in the log: > > dovecot: May 08 13:39:14 Info: Dovecot v1.0.beta7 starting up > dovecot: May 08 13:39:14 Info: Generating Diffie-Hellman parameters for the firs > t time. This may take a while.. > dovecot: May 08 13:39:14 Error: ssl-build-param: Trying to allocate 0 bytes > dovecot: May 08 13:39:14 Error: child 18998 (ssl-build-param) killed with signal > 6 > I searched the archives of the mailing list and didn't have any luck. > Any help would be created appreciated. Please reply directly to me > as well as the list. Thanks much! > > Jackie

1 0

[Dovecot] Downloading Previous Versions??
by Jackie Hunt 15 May '06

15 May '06

Hi all, How do I get to previous versions of the dovecot source code? I wanted to download dovecot-1.0.beta7, but can't find it via the web, only the latest version (beta8). It's probably obvious how to do this...but I'm not seeing it. Thanks much! Jackie ---- Jackie Hunt ACNS Voice: (970) 663-3789 Colorado State University FAX: (970) 491-1958 Fort Collins, CO 80523 Email: jackie.hunt(a)colostate.edu

2 1

[Dovecot] beta8 compile error
by Thomas Hummel 15 May '06

15 May '06

Hello, On FreeBSD 5.4-RELEASE dovecot-1.0.beta8 build cause the following error : --------------------------------------------- make all-recursive Making all in src Making all in lib if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I /usr/local/include/db41 -I/usr/local/include -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -MT mempool-alloconly.o -MD -MP -MF ".deps/mempool-alloconly.Tpo" -c -o mempool-alloconly.o mempool-alloconly.c; then mv -f ".deps/mempool-alloconly.Tpo" ".deps/mempool-alloconly.Po"; else rm -f ".deps/mempool-alloconly.Tpo"; exit 1; fi mempool-alloconly.c: In function `check_nuls': mempool-alloconly.c:85: error: too many arguments to function `check_nuls' *** Error code 1 --------------------------------------------- Compiler used : munster# gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728 -- Thomas Hummel | Institut Pasteur <hummel(a)pasteur.fr> | Pôle informatique - systèmes et réseau

2 2

[Dovecot] dovecot and vmailmgr
by Mij 15 May '06

15 May '06

hello now that dovecot supports authentication with checkpassword-compatible modules, I tried to get it working for IMAP on a qmail + vmailmgr server. For a subtle detail, while claiming to be "a drop-in replacement for the standard checkpassword", checkvpw (auth module for vmailmgr) is not "drop in". It actually expects 2 args on its command line, not 1. So, a wrapper is needed to get it authenticating correctly with dovecot; a very simple one (argswrapper.c below). This wrapper is not sufficient though. In fact, vmailmgr represents user homes like this: $HOME_LOCUSER/users/virtual_username this is ok with default_mail_env = maildir:%h/users/%n $HOME_LOCUSER depends on the domain part of the user's email. The relation is held in /var/qmail/control/virtualdomains . However, on the local part (virtual_username) some rewriting is done on the username, as dots are replaced by ":". So in the end j.doe(a)foo.com becomes "~mxfoocom/users/j:doe". Now, var-expand does not support any rewriting. I patched it by adding another modifier, m_str_replace(), which replaces REPLACE_SOURCE with REPLACE_TARGET in a given string. By defining REPLACE_SOURCE to '.' and REPLACE_TARGET to ':' one accomplishes the vmailmgr username rewriting. This modifier is applied with "P", so: default_mail_env = maildir:%h/users/%Pn A better, general solution would be for dovecot to implement some kind of general rewriting, say with regexps and sed-like replacement rules, or with an external process in a cgi fashion. With this patch, dovecot gets the correct path for any user mailbox. However, there's a bug in dovecot storage modules (both maildir and mbox) which truncates the path in the first ":", when expecting ":INBOX" etc specifiers: /* <Maildir> [:INBOX=<dir>] [:INDEX=<dir>] [:CONTROL=<dir>] */ if (debug) i_info("maildir: data=%s", data); p = strchr(data, ':'); if (p == NULL) root_dir = data; else { root_dir = t_strdup_until(data, p); this way, a former data = /var/maildirs/foo/users/j:doe:INDEX=... is truncated to /var/maildirs/foo/users/j . This opens the much worse possibility for user "j:doe" to be accounted into user "j" account after authentication. It is difficult to get a solid fix here, because the grammar is ambiguous for INBOX, INDEX and CONTROL tokens. Since they are not separated with an illegal path symbol from the rest of the path in default_mail_env, it is not possible to state when a ":INBOX=" token belongs to the path and when it is a user directive. The Best is to move the specifiers into a different configuration directive. However, a more solid check with the current modus operandi is /* <Maildir> [:INBOX=<dir>] [:INDEX=<dir>] [:CONTROL=<dir>] */ if (debug) i_info("maildir: data=%s", data); /* extracting INBOX / INDEX / CONTROL suffices */ if (((p = strstr(data, ":INBOX=")) != NULL) || ((p = strstr(data, ":INDEX=")) != NULL) || ((p = strstr(data, ":CONTROL=")) != NULL)) { root_dir = t_strdup_until(data, p); which expects the full ":INBOX=" etc strings to be present in data instead of the single ":" separator. The patches that implement this for both {maildir,mailbox}-storage are also appended below. I will take a couple of hours tomorrow to wrap all the iter up on a web page here http://mij.oltrelinux.com/net/dovecot-qmail-vmailmgr/ All the patches are applied wrt 1.0-beta7 bye

2 4

[Dovecot] more unexpected results from 0.99.13 -> 1.0beta8 upgrade
by Alan Premselaar 15 May '06

15 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just to give some more information about this: Apparently some of our POP3 users are saying that when they checked for new mail this morning that all the mail that was saved on the server was downloaded again as unread mail. I followed the guidelines in the wiki [1] with regards to upgrading from 0.99 to 1.0, made sure the .subscriptions and .customflags files were renamed to subscriptions and dovecot-keywords respectively yet the subscriptions were not maintained (i.e. users had to re-subscribe after the update) here's my config information, can you give me any hints as to what went wrong? [root@mail root]# dovecot -n protocols: imap imaps pop3 pop3s ssl_cert_file: /usr/share/ssl/certs/dovecot.pem ssl_key_file: /usr/share/ssl/private/dovecot.pem disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(pop3): no verbose_proctitle: yes default_mail_env: maildir:~/Maildir:INDEX=/var/indexes/%u:CONTROL=/var/control/%u maildir_copy_with_hardlinks: yes mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(pop3): /usr/lib/dovecot/pop3 pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh namespace: type: private separator: / location: maildir:~/Maildir:INDEX=/var/indexes/%u:CONTROL=/var/control/%u inbox: yes auth default: master_user_separator: * passdb: driver: pam userdb: driver: passwd [root@mail root]# dovecot --version 1.0.beta8 the machine is running RHEL 3 and kept up to date on a regular basis. Thanks, Alan [1] http://wiki.dovecot.org/UpgradingDovecot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEZ9hBE2gsBSKjZHQRAnSuAJ929R90J8eBhi25528jwXN1HaR7mgCg42sv t16Eyhc3G+CSLVjTTdTzaEw= =OtX8 -----END PGP SIGNATURE-----

2 1

[Dovecot] Semi-OT: Backing up maildir
by Shayne Hardesty 14 May '06

14 May '06

We switched our mail server over from mbox to maildir a few months ago and couldn't be happier - the performance under normal load is incredible. However we now have a problem with backup.. Typically we would run tar on the mail server, sending its output to another server via ssh.. Like this: tar cfp - /home | gzip | ssh other.server (cd /backups && tar xfp -).. I have tried gzipping the stream on the source side, gzipping on the destination, and running without gzip, all three take an amazingly long time to complete (> 14 hours). Ours is a modest server with about 1300 users, about 300GB of mail total. The whole thing sits on hardware RAID-10, so I'm primarily guarding against a MAJOR hardware failure, a config blunder, or a hacker wiping out files. How do you guys back up your maildir? I've considered exporing the maildir with NFS and backing it up from another server.. Any opinions on that? Thanks, Shayne

7 6

[Dovecot] 1.0beta8 won't start: Fatal: Protocol imaps given more than once
by Mike Brudenell 14 May '06

14 May '06

Greetings - I've just built Dovecot 1.0beta8 and find it refuses to start. This under Solaris 10 on an Intel-based Sun system. The error message Dovecot displays (on standard error) in response to /usr/local/sbin/dovecot is Fatal: Protocol imaps given more than once I've checked through my configuration file and the only mention of "imaps" is here: # Protocols we want to be serving: # imap imaps pop3 pop3s protocols = imap imaps The same settings file worked OK with 1.0beta7. I've also tried using the standard dovecot-example.conf that comes with 1.0beta8 which has the "protocols" line commented out and, after adding appropriate settings for "ssl_cert_file" and "ssl_key_file", still have the same problem. I popped a few dubugging i_info() calls into src/master/main.c to try and see what was going on and the output was as follows: Info: set->protocols = >imap imaps< Info: imap: *fd = -1 Info: imaps: *fd = 0 Fatal: Protocol imaps given more than once The first line is displaying the value of the keywords in set->protocols The second and third are within the if/then/else sequence: the first for the "imap" keyword and the second for the "imaps" keyword. Then comes the fatal error, caused by the "fd" variable not being equal to -1 (it is "0" for "imaps") above. Changing the dovecot.conf file to read protocols = imap lets Dovecot start up OK. Changing it to protcols = imaps causes it to fail in the same way as before(!). Seems to be a problem with the initialisation of set->ssl_listen_fd therefore, as this should apparently be -1? Is this likely to be something I've got wrong (wouldn't have thought so as 1.0beta7 is happy with the same config file) or is there a problem in 1.0beta8? Cheers, Mike B-) -- The Computing Service, University of York, Heslington, York Yo10 5DD, UK Tel:+44-1904-433811 FAX:+44-1904-433740 * Unsolicited commercial e-mail is NOT welcome at this e-mail address. *

4 5

[Dovecot] FSF - dovecot
by Matt 13 May '06

13 May '06

Will dovecot always be open FREE source for all? I am currently migrating my www.digipanel.com from Courier to dovecot as I think courier is overly complicated and a pain in the arse to manage all those files. anyways, I have dovecot IMAP working with MySQL auth but reading the Maildir each time takes up to 30 secs to complete. ANy ideas why? Maybe a dns resolve issue? how can I fix..

1 0