- dovecot - dovecot.org

[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

[Dovecot] Apparent corruption of dovecot.uidlist
by AnneWilson 25 Sep '09

25 Sep '09

I have been using Dovecot for about three years, and am currently using version 1.0.7 under CentOS. One of my users can no longer access his Inbox, although he can read mail in other folders. After a fair bit of log-viewing and looking for clues it suddenly began to make a sort of sense. The error message in the logs is Error: IMAP(david): unlink(/home/david/Maildir/cur/cur:2,ST) failed: Is a directory Eventually I came to /home/david/Maildir/dovecot-uidlist and compared it with my own. The second line in the problem account file is 'cur:2,ST. I backed up the file, then deleted that line. Sure enough, I could then open the messages. Unfortunately, when I close KMail I saw the line 'cur:2,ST' added to the end of dovecot-uidlist, and of course I'm back with the error. Can someone please explain to me what is causing this, and how I can correct it? Thanks Anne

2 2

[Dovecot] Feature request: 'dovecot-shared' files to be configurable
by Hendrik Pahl 24 Sep '09

24 Sep '09

Hi list, using dovecot in a more complex environment nearly always requires use of ACLs and shared mailboxes/folders. Now, to make life more easy for the users, we can use 'dovecot-shared' files to eable per-user \seen-flagging. Is it possible to make this issue configurable in the dovecot config, something like "always keep a 'dovecot-shared' file in users maildir, even if that mailbox is not shared"? That would be nice, since creating that files by hand is really time-consuming. Or are there any relations which avoid making this issue configurable? Thanks in advance, hendrik -- LWsystems GmbH & Co. KG ++ http://www.lw-systems.de/impressum Tel: +49 (0)5403 / 5556 ++ Fax: +49 (0)5403 / 7 95 89 97 LWsystems: Open Source IT Solutions - Linux Systemhaus - IT-Sicherheit ### ### LWsystems veranstaltet den LINUX SOLUTION DAY 2009 ### 29. Oktober 2009 ab 13.30 Uhr in Osnabrück ### Alle Details und Agenda unter: http://www.linux-solution-day.de ### ### Gleich anmelden: mailto:info@linux-solution-day.de?subject=Anmeldung ### ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ LWsystems GmbH & Co. KG Sitz der Gesellschaft: Tegelerweg 11, 49186 Bad Iburg Telefon +49 (0)5403 5556 Telefax +49 (0)5403 7958997 Handelsregister: Amtsgericht Osnabrück, HRA 110668 USt.-ID-Nr. DE244573220 Persönlich haftende Gesellschafterin: LWsystems Verwaltungs GmbH Sitz der Gesellschaft: Tegelerweg 11, 49186 Bad Iburg Handelsregister: Amtsgericht Osnabrück, HRB 111163 Geschäftsführer: Dipl.-Ing. Ansgar H. Licher, Bad Iburg Dipl.-Ing. Martin Werthmöller, Ibbenbüren Für weitere Firmendetails zu LWsystems siehe / For further company details please look at: http://www.lw-systems.de/impressum ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

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

24 Sep '09

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. -- 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.

1 0