February 2012 - dovecot

[Dovecot] setacl fails - does not find dovecot-acl file
by Michael Stilkerich 29 Apr '12

29 Apr '12

Hi, I'm using dovecot 2.0.13 that ships with Ubuntu 11.10. I tried setting up a shared namespace as documented in the wiki to enable the sharing of a mailbox between two users. I have a Maildir(++) directory for each user. Each user has a system account. The Maildir of each user is owned by the user's system account and group read/writable by the group mail (hence mail_access_groups=mail). Relevant parts of my config: mail_plugins = acl mail_location = maildir:/home/dovecot/%u mail_access_groups = mail namespace { type = private separator = / prefix = inbox = yes hidden = no subscriptions = yes } namespace { type = shared separator = / prefix = shared/%%u/ location = maildir:/home/dovecot/%%u:INDEX=/home/dovecot/%u/shared/%%u subscriptions = no list = children } protocol imap { mail_plugins = $mail_plugins imap_acl } plugin { acl = vfile } plugin { acl_shared_dict = file:/home/dovecot/shared-mailboxes } When I try to create an ACL in a telnet session, the command fails with an internal error. The log shows: dovecot: imap(michael): Error: fstat(/home/dovecot/michael/.test/dovecot-acl.lock) failed: No such file or directory dovecot: imap(michael): Error: file_dotlock_open(/home/dovecot/michael/.test/dovecot-acl) failed: No such file or directory The error occurs whether a (manually created) dovecot-acl file exists or not. The dovecot-acl.lock file is created by not removed afterwards. Subsequent setacl commands will timeout waiting for the lock to be released until I delete it manually. If I create the dovecot-acl file manually and provide access to another user, the getacl command will correctly show the permissions and the other user can access the folder. setacl will still fail to modify the acl file, however (same error). Another thing that irritates me is that dovecot seems to use the dotlock locking method, although I explicitly set lock_method to fcntl (also tried flock, same behavior). I'm not using chroot. I appreciate any help to get this sorted out. Thanks, Michael

3 6

[Dovecot] virtual plugin and shared namespace
by l.chelchowski＠eurocar.pl 23 Apr '12

23 Apr '12

Hi, I have a problem with virtual plugin and geting mails form shared namespace. dovecot-virtual: ---- Shared/* Public/* * unseen ---- dovecot.conf: ---- namespace { inbox = yes location = prefix = separator = / type = private } namespace { list = children location = maildir:/home/vmail/public/:CONTROL=/var/mail/vmail/%d/%u/control/public:INDEX=/var/mail/vmail/%d/%u/index/public:LAYOUT=fs prefix = Public/ separator = / subscriptions = yes type = public } namespace { list = children location = maildir:%%h/:INDEX=/var/mail/vmail/%d/%u/index/shared/%%u prefix = Shared/%%u/ separator = / subscriptions = no type = shared } namespace { list = children prefix = Virtual/ separator = / location = virtual:~/virtual } ---- When I enter the virtual mailbox Unread I get this debug info: virtual mailbox Virtual/Unread: Skipping non-existing mailbox Shared/test(a)domain.pl/ Is it a bug or misconfig? -- Łukasz Chełchowski

2 2

[Dovecot] dbox vs. mdbox
by Douglas Mortensen 20 Apr '12

20 Apr '12

What are the pros and cons of both? Especially in regards to performance, stability, management & maintenance? I really appreciate feedback. We're on a time-crunch to migrate from a debian 5 box w/ dovecot 1.1 to a debian 6 box w/ dovecot 2.0.9 (built from source). Thanks, - Doug Mortensen Network Consultant Impala Networks Inc CCNA, MCSA, Security+, A+ Linux+, Network+, Server+ . www.impalanetworks.com P: (505) 327-7300 F: (505) 327-7545

6 12

[Dovecot] Folder Aliases - Revisited Yet Again
by Daniel L. Miller 11 Apr '12

11 Apr '12

I just did a search through my archives - seems this topic has been requested a few times since my posting two years ago. I asked about a specific implementation - which Mr. Sirainen never commented on. He was probably focused on something more important at the time - like a paying job. So I'll ask again... Calling Timo! If we can't get clients to agree on a "standard" set of folders (probably reasonably safe assumption) and if protocol implementations of variations of "*LIST*" are too far in the future...what about having alternative folder names presented based on login name - maybe by an extension? So where my usual login might be "user(a)domain.com", and that would continue to be supported as the default login, I could now have "user(a)domain.com+thunderbird", "user(a)domain.com+mobile", etc.? And each of those extensions would then have a system-wide map defining folder name relationships, like "Sent=Sent Items". Does this seem doable? -- Daniel

2 4

[Dovecot] Multiple instances
by Timo Sirainen 30 Mar '12

30 Mar '12

v2.1 now saves the base_dir and instance_name to /var/lib/dovecot/instances when starting up. If you have for example two instances with names "backend" and "proxy", you can then use: doveadm -i proxy proxy list instead of something like: doveadm -c /etc/dovecot-proxy/dovecot.conf proxy list The same -i parameter works for all dovecot programs. I also added a couple of new doveadm commands: # doveadm instance list path name last used running /var/run/dovecot proxy 2012-02-06 21:41:39 yes # doveadm instance remove proxy It would be possible to add commands to start/shutdown some/all instances using doveadm, but is it all that useful? I'd guess people would have their own init.d scripts anyway doing that. Anything else that could be useful related to this?

2 2

[Dovecot] IMAP to Maildir Migration preserving UIDs?
by Gedalya 30 Mar '12

30 Mar '12

Hello all, I'm facing the need to migrate from a proprietary IMAP server to Dovecot. The migration must be as smooth and transparent as possible. The mailbox format I would want to use is Maildir++. The storage format used by the current server is unknown, and I don't look forward to trying to reverse-engineer it. This leaves me with the option of reading the mailboxes using IMAP. There are tools like offlineimap or mbsync, and they do store the UID and UIDVALIDITY info. The last piece of the puzzle is a process to properly create the dovecot-uidlist and dovecot-uidvalidity files. So far I wasn't able to find anything on this. Are there any tips? Are there any tools available to do this job, or part of it? In either case I need this done, and I'll have to create whatever I can't find available. If there isn't anything out there that I'm yet to become aware of, then I'm looking at creating something like an offlineimap post-processing routine? Any help would be much appreciated. Gedalya

7 33

[Dovecot] zlib_save per namespace/mailbox?
by Lutz Preßler 29 Mar '12

29 Mar '12

Hi, the zlib_save question reminds me of a wish: I think it's not possible to set zlib_save parameter per namespace (or even mailbox). Per namespace would be something for the wish list to get rid of the cron job method to compress archival mailboxes. And maybe an option to add a "Z" flag to compressed maildir message files as recommended in the wiki regarding compress crob job. Lutz

3 2

[Dovecot] Antispam plugin not compatible with Dovecot 2.1
by interfaSys sàrl 20 Mar '12

20 Mar '12

Here is what I get when I try to compile the antispam plugin agaisnt Dovecot 2.1 ************** mailbox.c: In function 'antispam_save_begin': mailbox.c:138:12: error: 'struct mail_save_context' has no member named 'copying' mailbox.c: In function 'antispam_save_finish': mailbox.c:174:12: error: 'struct mail_save_context' has no member named 'copying' Failed to compile mailbox.c (plugin)! gmake[3]: *** [mailbox.plugin.o] Error 1 ************** The other objects compile fine. Cheers, Olivier

4 5

[Dovecot] Multiple locations, 2 servers - planning questions...
by Charles Marcus 15 Mar '12

15 Mar '12

Hello all/Timo, Up until now, my main Clients office has consisted of a single location, and I have never had to deal with the situation of multiple locations for a single company. They have just told me that they are acquiring an additional floor at a building that is about 4 minutes away - but obviously far enough away that I now have to deal with supporting users in the same domain but at two disparate physical locations. These two locations will be connected via a private Gb ethernet connection, and each location will have its own internet connection (I think - still waiting on some numbers to present to the owner to see what he wants to do in that regard, but that will be my recommendation), so bandwidth for replication won't be an issue. I have a couple of months to get this done, and I am already planning on hiring Timo's new commercial support company to help with the final and actual design and implementation, but obviously first I need to know what my actual options are. Just a rough idea of what I'd like to do is: 1. Set up one dovecot server at each location (these will be VMs), so users at each location are accessing the local server for that office 2. Full replication between the two for the mail/indexes, and configure them such that each can act as a failover for the other in case one goes down for whatever reason This is my first/main question... I recall that 'dsync based replication' is actually on the map for 2.1, but, since apparently dsync can't do this now, Timo, do you have even a rough idea how much work this would be to get it working for only 2 locations (assuming it *may* be easier to get the initial support for only 2 locations, my client may be willing to pay for it if it isn't a huge amount - feel free to reply privately to this question), then you could revisit it later to make it more scalable? Or, if it is going to take more work than my client is willing to pay for (I'm hoping not, since you said it was on the map for 2.1, not 2.2+), maybe the notify plugin could be leveraged in some way to provide something 'close enough' until it is fully implemented in dsync? On that note (something 'close enough' until dsync fully supports this natively), would setting up a dsync cron job, say, every 5 or 10 minutes, be asking for trouble? Our mail server is not all that busy, really, so in 5 or 10 minutes, there wouldn't be many changes at all. If that is not recommended, although I want to avoid the hassles of NFS if at all possible, maybe there is another shared filesystem that will work ok - or... since I will be forcing users to a single server always anyway, maybe NFS or some other shared filesystem is really the best option here, and just let it take care of the syncing? and 3. Configure things such that each offices users are directed to the local server for that office, but connections will fail-over to the remote server in the case of one of them going down for whatever reason? I'm fairly sure that some combination of Dovecot Proxy/Director will accomplish this, but one concern is - for internal users, my understanding is it will redirect them via the private IP, but that would result in lots of traffic across the Gb connection between the two locations, and I'd like to eliminate that if possible - so how will this work when they are accessing it from outside the office, where each office has its own public IP? I'd prefer to not rely on users using the correct hostname (currently, we just use 'mail.example.com', and I know I could set up two new ones - office1.example.com and office2.example.com - but then I'd be relying on the users to get it right, and I'd prefer to avoid that can of worms). I guess a worst case scenario (if there is no better way) would be to do it that way, then watch the logs for users who get it wrong and are using the inter-office connection, and deal with them on a case by case basis. Thanks to any/all for reading this far and for any thoughts, suggestions and/or ideas... -- Best regards, Charles

9 19

Re: [Dovecot] Dovecot 2.1 with custom OpenSSL fails to build
by Andreas M. Kirchwitz 15 Mar '12

15 Mar '12

Timo Sirainen <tss(a)iki.fi> wrote: >> There seems to be a new dependency in some modules (eg, lib-storage, >> libdovecot-lda, libdovecot-ssl) on OpenSSL. In Dovecot 2.0, those >> modules didn't require OpenSSL, but 2.1 does. >> >> For the linking process the path to the OpenSSL library isn't >> specified properly (SSL_LIBS). Dovecot fails to build if OpenSSL >> is in a non-standard path. (Haven't checked if SSL_CFLAGS isn't >> properly used as well.) > > Maybe http://hg.dovecot.org/dovecot-2.1/rev/c07415305d9e fixes > everything? That's the way to go. Makes things better, but I've found three more dependencies. This patch is against the daily snapshot 20120228. (Sorry for the changes to Makefile.in which you won't need. But this way I don't have to rebuild Makefile.in from Makefile.am when compiling. ;-) diff -ur dovecot-20120228.original/src/auth/Makefile.am dovecot-20120228/src/auth/Makefile.am --- dovecot-20120228.original/src/auth/Makefile.am 2012-02-26 04:00:02.000000000 +0100 +++ dovecot-20120228/src/auth/Makefile.am 2012-02-29 01:38:41.000000000 +0100 @@ -167,7 +167,7 @@ libauthdb_imap_la_LIBADD = \ ../lib-imap-client/libimap_client.la \ ../lib-ssl-iostream/libssl_iostream.la \ - $(LIBDOVECOT) + $(LIBDOVECOT) $(SSL_LIBS) libauthdb_imap_la_CPPFLAGS = \ $(AM_CPPFLAGS) \ -I$(top_srcdir)/src/lib-imap \ diff -ur dovecot-20120228.original/src/auth/Makefile.in dovecot-20120228/src/auth/Makefile.in --- dovecot-20120228.original/src/auth/Makefile.in 2012-02-28 04:00:12.000000000 +0100 +++ dovecot-20120228/src/auth/Makefile.in 2012-02-29 01:38:44.000000000 +0100 @@ -499,7 +499,7 @@ libauthdb_imap_la_LIBADD = \ ../lib-imap-client/libimap_client.la \ ../lib-ssl-iostream/libssl_iostream.la \ - $(LIBDOVECOT) + $(LIBDOVECOT) $(SSL_LIBS) libauthdb_imap_la_CPPFLAGS = \ $(AM_CPPFLAGS) \ diff -ur dovecot-20120228.original/src/lib-storage/Makefile.am dovecot-20120228/src/lib-storage/Makefile.am --- dovecot-20120228.original/src/lib-storage/Makefile.am 2012-02-10 04:00:02.000000000 +0100 +++ dovecot-20120228/src/lib-storage/Makefile.am 2012-02-29 01:38:21.000000000 +0100 @@ -85,7 +85,7 @@ pkglib_LTLIBRARIES = libdovecot-storage.la libdovecot_storage_la_SOURCES = -libdovecot_storage_la_LIBADD = $(shlibs) $(MODULE_LIBS) +libdovecot_storage_la_LIBADD = $(shlibs) $(MODULE_LIBS) $(SSL_LIBS) libdovecot_storage_la_DEPENDENCIES = $(shlibs) libdovecot_storage_la_LDFLAGS = -export-dynamic diff -ur dovecot-20120228.original/src/lib-storage/Makefile.in dovecot-20120228/src/lib-storage/Makefile.in --- dovecot-20120228.original/src/lib-storage/Makefile.in 2012-02-28 04:00:15.000000000 +0100 +++ dovecot-20120228/src/lib-storage/Makefile.in 2012-02-29 01:38:21.000000000 +0100 @@ -397,7 +397,7 @@ pkglib_LTLIBRARIES = libdovecot-storage.la libdovecot_storage_la_SOURCES = -libdovecot_storage_la_LIBADD = $(shlibs) $(MODULE_LIBS) +libdovecot_storage_la_LIBADD = $(shlibs) $(MODULE_LIBS) $(SSL_LIBS) libdovecot_storage_la_DEPENDENCIES = $(shlibs) libdovecot_storage_la_LDFLAGS = -export-dynamic test_programs = \ diff -ur dovecot-20120228.original/src/login-common/Makefile.am dovecot-20120228/src/login-common/Makefile.am --- dovecot-20120228.original/src/login-common/Makefile.am 2011-11-09 04:00:01.000000000 +0100 +++ dovecot-20120228/src/login-common/Makefile.am 2012-02-29 01:38:21.000000000 +0100 @@ -40,6 +40,6 @@ pkglib_LTLIBRARIES = libdovecot-login.la libdovecot_login_la_SOURCES = -libdovecot_login_la_LIBADD = liblogin.la ../lib-ssl-iostream/libssl_iostream.la ../lib-dovecot/libdovecot.la +libdovecot_login_la_LIBADD = liblogin.la ../lib-ssl-iostream/libssl_iostream.la ../lib-dovecot/libdovecot.la $(SSL_LIBS) libdovecot_login_la_DEPENDENCIES = liblogin.la libdovecot_login_la_LDFLAGS = -export-dynamic diff -ur dovecot-20120228.original/src/login-common/Makefile.in dovecot-20120228/src/login-common/Makefile.in --- dovecot-20120228.original/src/login-common/Makefile.in 2012-02-28 04:00:18.000000000 +0100 +++ dovecot-20120228/src/login-common/Makefile.in 2012-02-29 01:38:21.000000000 +0100 @@ -320,7 +320,7 @@ pkginc_lib_HEADERS = $(headers) pkglib_LTLIBRARIES = libdovecot-login.la libdovecot_login_la_SOURCES = -libdovecot_login_la_LIBADD = liblogin.la ../lib-ssl-iostream/libssl_iostream.la ../lib-dovecot/libdovecot.la +libdovecot_login_la_LIBADD = liblogin.la ../lib-ssl-iostream/libssl_iostream.la ../lib-dovecot/libdovecot.la $(SSL_LIBS) libdovecot_login_la_DEPENDENCIES = liblogin.la libdovecot_login_la_LDFLAGS = -export-dynamic all: all-am

2 3