- dovecot - dovecot.org

[Dovecot] Proxying Performance vs imapproxy
by Dan Poltawski 28 Sep '09

28 Sep '09

Hi, I'm planning on a new mail infrastructure which constists of multiple 'frontends' running webmail & public access pop/imap, which would communicate over imap/pop to 'backend mail stores'. My original idea was to run dovecot on the backends, use a predition on the frontends to proxy imap/pop and also run imapproxy in front of webmail [squirrelmail]. I've since read about the dovecot proxying features and it seems to make sense to replace predition in that above scenario. I'm unclear about the benefits of the auth_cache and how it compares to the using imapproxy in front of webmail client? Does it make sense to have authcaching switched on in the proxy and not on the backend server? (Doesn't the authentication just have to happen on the backend server?) Are there any performance benefits to using a proxying server, or is it just for splitting mailstores? thanks for your work, Dan Poltawski

4 6

[Dovecot] Upgrading Dovecot on CentOS 4 from 0.99 to 1.x
by Josep L. Guallar-Esteve 28 Sep '09

28 Sep '09

(sorry for my previous message, I sent it by mistake before finishing it) Hello, We have a production mail server running dovecot 0.99 (dovecot-0.99.14-1.rf). We are getting several errors corrected in dovecot 1.x versions: * corrupted inboxes (garbage at beggining of mbox files), * corrupted index files (Error: Corrupted file index /home/jsmith/.imap/Drafts/.imap.index: Sequence 6 not found from binary tree (6 msgs says header)), * others (Error: fcntl() failed with mbox file /var/mail/jsmith: Resource deadlock avoided), etc. I'm planning to upgrade using the instructions found at dovecot's wiki. On http://atrpms.net/dist/el4/ it is offered in 3 different versions: * dovecot 1..0.15-1_73.el4 * dovecot 1.1.19-1_96.el4 * dovecot 1.2.5-0_100.el4 I have a separated test system, where I'll test upgrading from 0.99 to final selected version, to discover any possible gotchas found while upgrading. Two questions: 1. Which version is the recommended to upgrade? I'd like stability and as little problems as possible over anything else, as we have a simple set up. 2. What is the preferred upgrade method? straight upgrade? (099 -> rpm -Fvh dovecot-1.2 ? Or upgrading one release at a time? (0.99 > 1.0 > 1.1 ...) Thank you in advance for any recommendation. Regards, Josep -- Josep L. Guallar-Esteve This transmission is intended for the use of the entity or individual to which or whom it is addressed. The transmission or any documents accompanying the transmission may contain confidential information. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or action taken in reliance on the contents of the transmission or the documents is strictly prohibited. If you have received this confidential transmission in error, please destroy it and any accompanying documents and notify the sender immediately. Thank you.

3 5

[Dovecot] require SSL certs only for encrypted connections?
by Florin Andrei 28 Sep '09

28 Sep '09

# 1.1.11: /etc/dovecot/dovecot.conf # OS: Linux 2.6.28-14-server x86_64 Ubuntu 9.04 Here's the situation: I have several local clients (Thunderbird) which do not use TLS at all. It's plaintext completely, on port 143, because the connection is local and there are no unauthorized users on this network (it's a home network). I want to keep it that way to keep things simple. Tools / Account Settings / Server Settings: Use Secure Connection: Never Use Secure Authentication: unchecked Until now, this has worked very well. No problems so far. But now I am also setting up IMAPS for remote iPhone clients, with client/server certificates. This is how I generated the certs: http://impetus.us/~rjmooney/projects/misc/clientcertauth.html On the iPhone I uploaded the client.crt file (couldn't import client.p12 for some reason). For Dovecot I am using ca.crt, server.crt and server.key. ssl_listen: *:993 ssl_disable: no ssl_ca_file: /blah/ca.crt ssl_cert_file: /blah/server.crt ssl_key_file: /blah/server.key ssl_key_password: ssl_parameters_regenerate: 168 ssl_cipher_list: ALL:!LOW:!SSLv2 ssl_cert_username_field: commonName ssl_verify_client_cert: yes disable_plaintext_auth: no auth default: mechanisms: plain login ssl_require_client_cert: no ssl_username_from_cert: no I analyzed the connection on 993 with Wireshark and apparently all is good: it's encrypted, I see the certificate exchanges taking place. But I am worried about authenticating the connections from the iPhone and I would like to configure "ssl_require_client_cert: yes" so that a valid certificate is always required. But if I do that then Thunderbird fails to login because it's required a certificate. This is puzzling. I thought that setting would only influence SSL connections. But apparently it also affects plaintext logins from Thunderbird. Is there a way to require a cert from the iPhone TLS connections on port 993, but do not require it from clients connecting to port 143? -- Florin Andrei http://florin.myip.org/

2 6

[Dovecot] Segfault in quota-fs plugin
by Brandon Davidson 28 Sep '09

28 Sep '09

Hi all, We recently attempted to update our Dovecot installation to version 1.2.5. After doing so, we noticed a constant stream of crash messages in our log file: Sep 22 15:58:41 hostname dovecot: imap-login: Login: user=<USERNAME>, method=PLAIN, rip=X.X.X.X, lip=X.X.X.X, TLS Sep 22 15:58:41 hostname dovecot: dovecot: child 6339 (imap) killed with signal 11 (core dumps disabled) We rolled back to version 1.2.4, and installed 1.2.5 on a test system - something we'll have to make sure to do *before* rolling new versions into production. Anyway, after examining a few core files from the test system, it looks like the recent changes to the quota plugin (specifically the maildir backend's late initialization fix) have broken the other backends. Stack trace and further debugging are available here: http://uoregon.edu/~brandond/dovecot-1.2.5/bt.txt The relevant code seems to have been added in changeset 9380: http://hg.dovecot.org/dovecot-1.2/rev/fe063e0d7109 Specifically, quota.c line 447 does not check to see if the backend implements init_limits before calling it, resulting in a null function call for all backends that do not do so. Since this crash would appear to affect all quota backends other than maildir, it should be a pretty easy to reproduce. I've attached a patch which seems to fix the obvious code issue. I can't guarantee it's the correct fix since this is my first poke at the Dovecot source, but it seems to have stopped the crashing on our test host. Regards, -Brandon

3 2

[Dovecot] Running dovecot master processes across multiple IPs
by Steven F Siirila 28 Sep '09

28 Sep '09

We are running dovecot 1.1.8 and are currently running it with 4 master processes (one for each of the protocols: imap, imaps, pop3, pop3s). The idea was to spread out the load so as to not overwhelm any one master. This has worked well. To take it further, we're contemplating running masters across multiple IP addresses, where the host/service name DNS records would be something like this: imap-server.domain A 10.1.1.1 A 10.1.1.2 A 10.1.1.3 A 10.1.1.4 The default route would either be through the first address (10.1.1.1 in this example) or potentially across all of them in presumably a round-robin fashion. Do you see any problems with this? Has anyone done this? -- Steven F. Siirila Office: WBOB, 624J Internet Services E-mail: sfs(a)umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota

2 1

[Dovecot] Ubuntu 9.x segmentation fault with vpopmail auth
by Timothy Timmons 28 Sep '09

28 Sep '09

I've been trying for 24 hours now, to get an IMAP server which will autenticate off of vpopmail cdb database and the auth module always segfaults on login. I'm using vpopmail 5.5.0 only because it is the only version which seems to create a dynamically linked version of the library. I tried latest releases dovecot 1.0, 1.1, and 1.2. Also latest mercurial pulls of 1.1 and 1.2. Even old versions of courier-imap and courier-authlib do it, but with these I can try older versions of vpopmail cause they don't require the dynamically linked version of libvpopmail. So I'm thinking it is something with Ubuntu 9.04 and pretty much all third party vpopmail authentication code. Strangely qmail-pop3d works fine with vchkpwd, just I cannot find any IMAP server that will work no matter what combination of vpopmail and version of the IMAP server. If anyone can figure this out I'd greatly appreciate it. Sep 25 14:43:37 mail kernel: [41432.282133] dovecot-auth[14048]: segfault at 0 ip 00000000 sp bf88c8ec error 14 in dovecot-auth[8048000+40000] Sep 25 15:07:16 mail kernel: [42852.136667] dovecot-auth[21185]: segfault at 0 ip 00000000 sp bfdcce2c error 14 in dovecot-auth[8048000+40000] Sep 25 15:23:59 mail kernel: [43855.048512] dovecot-auth[6927]: segfault at 0 ip 00000000 sp bfd81ecc error 14 in dovecot-auth[8048000+40000] Sep 25 15:55:22 mail kernel: [45737.522566] dovecot-auth[12458]: segfault at 0 ip 00000000 sp bfcc8dfc error 14 in dovecot-auth[8048000+40000] Sep 25 16:14:15 mail kernel: [46870.968589] dovecot-auth[30127]: segfault at 0 ip 00000000 sp bff59f9c error 14 in dovecot-auth[8048000+3d000] Sep 25 16:23:26 mail kernel: [47421.947792] dovecot-auth[15832]: segfault at 0 ip 00000000 sp bf9121ec error 14 in dovecot-auth[8048000+31000] Sep 25 16:27:06 mail kernel: [47641.662788] authvchkpw[17265]: segfault at 0 ip 00000000 sp bf8f240c error 14 in authvchkpw[8048000+5000] etc.. Thanks, Tim P.S. I'm going nuts here, trying to get Squirrelmail back up for customers, but I'm absolutely stuck.

3 3

[Dovecot] Sieve: problems installing in different prefix
by Andreas Ntaflos 28 Sep '09

28 Sep '09

Hi list, but mainly Stephan :) when building and subsequently installing the new Sieve plugin I am coming across a small difficulty when it comes to "make install". The libraries lib90_sieve_plugin.* always get installed in the directory /usr/local/lib/dovecot/lda, no matter what "prefix" argument is supplied to "make install". Only the libraries seem affected, not the rest of the Sieve plugin distribution (i.e. sieve, sievec, sieve-test, ...). Background: I like using XStow [1] to manage packages built from source. With XStow one can configure and build software like Dovecot and Sieve as usual (./configure && make) but then install it under a custom directory/prefix, like /usr/local/stow/dovecot-1.2.5. The "prefix" argument for "make install" is used for this, i.e.: make install prefix=/usr/local/stow/dovecot-1.2.5 XStow is then used to create symlinks to the correct places in the file system. For example the Dovecot binary gets installed in /usr/local/stow/dovecot-1.2.5/sbin/dovecot and a symbolic link is created by XStow: /usr/local/sbin/dovecot -> ../stow/dovecot-1.2.5/sbin/dovecot The advantages are clear: installing a software package is a matter of configuring, building and then installing under a custom directory, and letting XStow create symlinks. Updating is as easy as installing the new version in a parallel custom directory and letting XStow update the symlinks. Removing a software package just involves letting XStow remove the symlinks and doing an rm -rf on the custom directory. No more accidentally orphaned files or the need to keep the compiled source distribution around to be able to issue a "make uninstall". Back to the problem: The Sieve source distribution seems to have some hard-coded setting to always install the libraries under /usr/local/lib/dovecot/lda and not honouring the "prefix" argument for "make install". This is probably a libtool issue, but I am not sure. I know my way around the Autotools but here I am a bit lost. Looking at the generated Makefile in dovecot-1.2-sieve-0.1.12/src I can see the following: moduledir = /usr/local/lib/dovecot/ It *should* look like this: exec_prefix = ${prefix} ... moduledir = ${exec_prefix}/lib/dovecot/ This explains why the install prefix is not honoured here. The "moduledir" has already been hardcoded, instead of prefixed. For comparison look at the Dovecot source distribution. Here all libraries are installed correctly under the specified prefix. An example is src/lib-sql. The generated Makefile includes these lines, which are correctly honouring the prefix: exec_prefix = ${prefix} ... moduledir = ${exec_prefix}/lib/dovecot ... #sql_moduledir = $(moduledir)/sql AM_CPPFLAGS = \ -I$(top_srcdir)/src/lib \ -DMODULEDIR=\""$(moduledir)"\" \ $(SQL_CFLAGS) The last few lines seems to make sure that gcc uses the defined moduledir, but as usual generated code is not immediately comprehensible for the casual viewer :) The top-level generated Makefile also contains a correctly defined moduledir: moduledir = ${exec_prefix}/lib/dovecot So, which knobs have to be turned to have the Sieve source distribution use a correct "moduledir" and not a hardcoded path? I hope I could explain the problem correctly and haven't drawn any wrong conclusions here. I will continue to investigate this and maybe even provide a patch if I find a solution but it is probably easier for the maintainer and author of the build system to look at this and determine what to do. Anyway, apologies for this lengthy post. I hope it wasn't too long to read. Andreas [1] http://xstow.sourceforge.net/ -- Andreas Ntaflos GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4

2 1

[Dovecot] Sieve: redirect and keep action, possible bug
by Andreas Ntaflos 27 Sep '09

27 Sep '09

Hi, Using Dovecot 1.2.4 and the new Sieve implementation in version 0.1.12, I ran into a problem that could indicate a bug in Sieve. The following is a simple script (as generated by Horde's Ingo application) to redirect incoming mail and also keep a copy of the message in the local inbox: if true { redirect "foo(a)example.org"; } if true { keep; stop; } Problem is, it doesn't work as expected: no copy of the message is kept in the local inbox. However, if I explicitly tell Sieve to "fileinto" it works fine: require ["fileinto"]; if true { redirect "foo(a)example.org"; } if true { fileinto "INBOX"; stop; } Is this a bug in Sieve or am I wrong about how "keep" works? Thanks in advance! Andreas -- Andreas Ntaflos Vienna, Austria GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4

3 6

[Dovecot] Dovecot + DRBD/GFS mailstore
by Guy 26 Sep '09

26 Sep '09

Hi guys, I'm looking at the possibility of running a pair of servers with Dovecot LDA/imap/pop3 using internal drives with DRBD and GFS (or other clustered FS) for the mail storage and ext3 for the root drive. I'm currently using maildrop for delivery and Dovecot imap/pop3 with the stores over NFS. I'm looking for better performance but still keeping the HA element I have now with shared storage over NFS. Has anyone had experience with a setup like the one I'm suggesting? What was performance like with Dovecot using GFS? Thanks Guy -- Don't just do something...sit there!

5 9

[Dovecot] lda protocol
by Darvin Denmian 25 Sep '09

25 Sep '09

Hello, why the output of command "dovecot -n" doesn't show anything about protocol lda? Bellow my lda configuration: protocol lda { mail_plugins = sieve quota expire log_path = /var/log/dovecot-local-deliver.log mail_debug = yes postmaster_address = postmaster(a)domain.com hostname = mail01.domain.com mail_plugin_dir = /usr/lib/dovecot/modules/lda } Thanks.

3 5