- dovecot - dovecot.org

Shared folder in a sharded cluster setup
by Peer Heinlein 03 Oct '16

03 Oct '16

Hi! With Dovecot Director and Proxy or the new (great!) TAG-feature from Dovecot it's easy to set up a shared IMAP-Cluster with individual local filesystems. But I'm unsure if it's possible to build a setup where shared mailboxes still can work. If user A is on Cluster (1) and user B is on (2), and Cluster (1) does not have access to the mail-home from B on (2), then user A can not reach the shared folders provided from User B on (2). I hope that there is a kind of backend-proxy-mechanism, so that the imap process of A on (1) can imap-proxy the requests for the shared folder to a node from cluster shard (2). And: To be exact, the imap process on (1) should forward the request to cluster (2) by the director system to make sure, that the connection will terminate on the right active backend of User B. This sounds like a special problem if local filesystems with mdbox are used and I now the great features of using Dovecot on Object Store, where every node can check out all mail-locations from all users. But especially on obox-systems it is very important that requests for a user are always terminated on the same backend. So how can shared folders work there?! Node (1) can not checkout the shared folders from User B if his obox storage is already active on another host (2)! Peer -- Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-42 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin

2 1

Requiring client certificate on only one interface
by Braden Thomas 02 Oct '16

02 Oct '16

Hi, I'm trying to require client certificates on only one interface. I'm running dovecot 2.1.7. There have been a couple of recent threads about this kind of configuration: http://dovecot.org/list/dovecot/2016-August/105244.html (Aug 2016) http://www.dovecot.org/list/dovecot/2016-February/103067.html (Feb 2016) However, these threads recommend an approach that no longer works. Specifically, the "-l" or "-P" arguments to imap-login no longer work. Is there currently a recommended way to configure dovecot like this? Braden

1 0

Re: Bug: Shared Mailbox - Case Sensitivity
by Aki Tuomi 01 Oct '16

01 Oct '16

Can you provide doveconf -n? ---Aki TuomiDovecot oy -------- Original message --------From: Leander Schäfer <info(a)netocean.de> Date: 01/10/2016 03:41 (GMT+02:00) To: Aki Tuomi <aki.tuomi(a)dovecot.fi>, Dovecot Mailing List <dovecot(a)dovecot.org>, Timo Sirainen <tss(a)iki.fi> Subject: Re: Bug: Shared Mailbox - Case Sensitivity Am I missing something, or might this be a bug as it seems to me? Am 16.09.16 um 14:21 schrieb Leander Schäfer: > Hi Aki, > > > Thanks for your advice. Yes, I'm aware of this. Yet lowercasing should > be the default since Dovecot 2.1.x., isn't it? Yet I wouldn't know > where exactly to implement this %L, since the ACLs are set through > IMAP commands through the users mailclient like Thunderbird. So in > other words, the email address to whom the user want to grant ACLs > provided by the user's mailclient, has nothing to do with my auth > backend where e.g. %u => %Lu would apply. PLease correct me if I'm > wrong here. > > > It clearly looks like a bug of the internal processing of the > "dovecot-acl-list" files. It simply lacks on a lowercase enforcement > in the code, like it already seems to do for the "dovecot-acl" file. > > > Best regards > > Leander Schäfer > > > > Am 16.09.16 um 12:53 schrieb Aki Tuomi: >> >> On 16.09.2016 12:54, Leander Schäfer wrote: >>> Hi, >>> >>> unfortunately I found a bug in Dovecot's ACL handling for shared >>> mailboxes. It turns out Dovecot doesn't enforce lower casing the >>> privileged username to whom the mailbox should be shared to. This >>> results in a invalid configuration. Users get confused, since they >>> passed on a valid email address in their ACL setup. >>> >>> /usr/local/www/default/mail/test(a)mydomain.localdomain/maildir/.Spam/dovecot-acl >>> >>> >>> user=leander(a)mydomain.localdomain eilrwts >>> ^^ works >>> >>> /usr/local/www/default/mail/leander(a)mydomain.localdomain/maildir/dovecot-acl >>> >>> >>> user=test(a)mydomain.localdomain eilrwts >>> ^^ works >>> >>> /usr/local/www/default/mail/test(a)mydomain.localdomain/maildir/.Drafts/dovecot-acl >>> >>> >>> user=Leander(a)MyDomain.LocalDomain eilrwts >>> ^^ Doesn't work >>> >>> Best regards >>> Leander Schäfer >> Hi! Did you know you can use %Lu instead of %u to force lowercasing? >> >> Aki

1 0

Re: NFSv4 and Maildir
by Joseph Tam 01 Oct '16

01 Oct '16

> we have a setup with (CentOS 6) Director+Dovecot, Maildir as storage on > NetApp NFS v3. Every time I try to switch to NFS v4 I found issue with > lock (and others). So for me NFSv4 with Maildir is "unstable" or need a > fine tuning that I don't know. I found the same thing, and turning off write delegation seemed to have solved the problem. I still don't know why, though. Joseph Tam <jtam.home(a)gmail.com>

2 1

Bug: Shared Mailbox - Case Sensitivity
by Leander Schäfer 01 Oct '16

01 Oct '16

Hi, unfortunately I found a bug in Dovecot's ACL handling for shared mailboxes. It turns out Dovecot doesn't enforce lower casing the privileged username to whom the mailbox should be shared to. This results in a invalid configuration. Users get confused, since they passed on a valid email address in their ACL setup. /usr/local/www/default/mail/test(a)mydomain.localdomain/maildir/.Spam/dovecot-acl user=leander(a)mydomain.localdomain eilrwts ^^ works /usr/local/www/default/mail/leander(a)mydomain.localdomain/maildir/dovecot-acl user=test(a)mydomain.localdomain eilrwts ^^ works /usr/local/www/default/mail/test(a)mydomain.localdomain/maildir/.Drafts/dovecot-acl user=Leander(a)MyDomain.LocalDomain eilrwts ^^ Doesn't work Best regards Leander Schäfer

3 4

acl_group not working not working correctly
by Leander Schäfer 01 Oct '16

01 Oct '16

Hi, I'm trying to setup group based ACLs coming from OpenLDAP. My setup doesn't require a POSIX Group match. In the Dovecot configuration file I have this: "user_attrs = [...], mailAclGroups=acl_groups" as well as "acl = vfile:/usr/local/etc/dovecot/global-acls:cache_secs=300". The user has "public" in the LDAP attribute "mailAclGroups". It seems to get everything right. I checked with doveadm - and I see public ist listed as expected: cat /var/log/debug.log [...] Sep 16 23:39:04 WM-01 dovecot: auth: Debug: client passdb out: OK 1 user=leander(a)mydomain.localdomain acl_groups=public [...] cat /usr/local/etc/dovecot/global-acls INBOX owner lrwstipekxa Drafts owner lrwstipeka Sent owner lrwstipeka Spam owner lrwstipeka Trash owner lrwstipeka Public authenticated l Public group-override=public lrwstipekx Public/* group-override=public lrwstipekx doveadm mailbox list -u leander(a)mydomain.localdomain Drafts Sent Trash Spam Shared Public Public/Service Center Shared/test(a)mydomain.localdomain Shared/test(a)mydomain.localdomain/Drafts Shared/test(a)mydomain.localdomain/Sent Shared/test(a)mydomain.localdomain/Trash Shared/test(a)mydomain.localdomain/Spam INBOX But here comes the strange thing: telnet equal to Thunderbird: . LIST "" "*" * LIST (\HasNoChildren \Drafts) "/" Drafts * LIST (\HasNoChildren \Sent) "/" Sent * LIST (\HasNoChildren \Trash) "/" Trash * LIST (\HasNoChildren \Junk) "/" Spam * LIST (\Noselect \HasChildren) "/" Shared * LIST (\HasChildren) "/" Shared/test(a)mydomain.localdomain * LIST (\HasNoChildren) "/" Shared/test(a)mydomain.localdomain/Drafts * LIST (\HasNoChildren) "/" Shared/test(a)mydomain.localdomain/Sent * LIST (\HasNoChildren) "/" Shared/test(a)mydomain.localdomain/Trash * LIST (\HasNoChildren) "/" Shared/test(a)mydomain.localdomain/Spam * LIST (\HasNoChildren) "/" INBOX . OK List completed (0.000 + 0.000 + 0.092 secs). Public and Public/* shoul be listed as well, but it isn't. Any idea why it is behaving like this? Thanks Best regards Leander Schäfer

1 1

[patch] Improved error checking for the dovecot-antispam-plugin
by Robert Munteanu 30 Sep '16

30 Sep '16

Hi, Hopefully this is the right channel for such a patch. I have a minor enhancement to submit for the antispam plugin http://hg.dovecot.org/dovecot-antispam-plugin It adds minimal error checking for the sendmail_binary, otherwise the reported error in case of a missing binary or one with missing permissions is generic and not useful. Thanks, Robert -- http://robert.muntea.nu/

3 6

NFSv4 and Maildir
by Robert Blayzor 30 Sep '16

30 Sep '16

Recently moving to newer storage platforms for mailbox storage so looking at moving mounts from NFSv3 with lots of issues with locking and caching to NFSv4. There seems to be a lot of benefits to v4 along with some other new features, namely “delegation”. So the question boils down to, to delegate or not delegate on Maildir storage. There may be many reasons based on actual platform why to do (or not to do this), but I want to get the general opinion from others that may have more experience with this. Our setup is several FreeBSD 10.x clients running Dovecot/Exim, NetApp NFS mail storage (probably moving to TrueNAS) and using F5 load balancers for client side connections/SSL offload. From what I’ve found (and what i’ve read in the RFC) is that delegation seems to work best when there is NOT a lot of file contention from clients accessing the same files. I realize that in some situations many people are using director to try and keep users on the same client; in our case we’re doing it with F5 iRules. The F5 iRules work great for POP3 and IMAP session persistence, but unfortunately that doesn’t work for SMTP and Dovecot LDA, so we still have possible race conditions from the MTA’s delivering into “INBOX”. (mostly dovecot indexes updating at the same time). So the big question is, who is using Dovecot with maildirs with NFSv4 mounts. What has your experience been? Are you using delegation? By choice and why did you come to that decision. I’m drawing up the conclusion that if you can *mostly* control client control to specific files (ie: directing access to a mailbox to come from one client), then delegation might be ok. However, if you’re not using director and have several NFS mail clients racing to access mailboxes, then delegation might turn into chaos. Your comments welcome and appreciated. -- Robert inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu

2 1

Re: Dovecot 2.2.25 fails on SSL
by Andreas M. Kirchwitz 30 Sep '16

30 Sep '16

Joseph Tam <jtam.home(a)gmail.com> wrote: >>> OK, the origin of your problem becomes clearer. You can hardcode these >>> paths into the executables by doing something like >>> >>> env CFLAGS='-I/my'ssl/include' \ >>> LDFLAGS='-L/your/ssl/lib -Wl,-rpath,/my/ssl/lib' \ >>> configure ... >> >> Based on your mail I've tried CFLAGS/LDFLAGS again, and >> now Dovecot didn't even compile any longer. > > I don't use the same OS as you, but what errors dis you get? To be exact here, it's not the compiler but the linker failing (of course, the whole problem is about the linking process). With "--as-needed", the crypto/ssl libraries are not linked at all with the object files. I don't quite understand why it doesn't fall back to the system crypto/ssl libraries because they are in the default pathes with all other libraries. (That's basically what most other software packages do if my custom pathes for "-L" "-Wl,-R" somehow get ignored in the building process.) IMHO, the unusual option "--as-needed" should be removed. There seems to be no benefit but it basically keeps Dovecot to be linked against any custom-specified library. Maybe it's just a problem with RHEL/CentOS 6 and the GCC that ships with it. I'm compiling a lot of software myself and link it against my custom OpenSSL. Never had this problem before, otherwise I would have known to specify "-Wl,--no-as-needed" to reverse ld's behavior to the default. Well, at least I've learned something new. :-) Regards, Andreas

2 1

Softlinks
by Chris 29 Sep '16

29 Sep '16

All, I'm using Maildir. Is it possible to move all (or only some) maildirs with softlinks to another partition? - Chris

2 2