- dovecot - dovecot.org

doveadm backup fails (compromised single attachment storage)
by Webert de Souza Lima 03 Oct '16

03 Oct '16

Hi, A couple of months ago I had a problem with Single Attachment Storage after infrastructure migration; All mailboxes were rsynced to another filesystem, and that may have broken Single Attachment Storage. Many, many (if not all) mailboxes show the below logs on dovecot: imap(foo(a)bar.com): Error: read(attachments-connector(zlib(/dovecotdir/mail/ bar.com/foo/mailboxes/INBOX/dbox-Mails/u.26426))) failed: read(/dovecotdir/attach/ bar.com/de/86/de8673894d6fb3f4460e3c26436eefa9a73517fa0f000452f553822367220… b/l]) failed: open(/dovecotdir/attach/ bar.com/de/86/de8673894d6fb3f4460e3c26436eefa9a73517fa0f000452f553822367220…) failed: No such file or directory When that happens, the MUA keeps syncing forever. Now, I need to migrate all mailboxes (again) to another dovecot instance (with no SAS), which works perfectly for new users but when I try to migrate users from my current dovecot server for this new server, I get such errors again, and I can't migrate: 2016-09-29T12:20:50.995934059Z Sep 29 12:20:50 dsync-server(foo(a)bar.com): Error: dsync(cf7d091311eb): read(attachments-connector(zlib(/dovecotdir/mdbox/bar.com/foo/storage/m.1))) failed: read(/dovecotdir/attach/ bar.com/0c/df/0cdf86b1920938fe3a043f87e2ee9e63dda276bd5b9fba687e4a0c63d181c… b/l]) failed: open(/dovecotdir/attach/ bar.com/0c/df/0cdf86b1920938fe3a043f87e2ee9e63dda276bd5b9fba687e4a0c63d181c…) failed: No such file or directory (last sent=mail, last recv=mail_request (EOL)) Is there a way to fix the attachments problem? (I know I can't recover such files, that's Ok) Is there a way to migrate (dsync backup) ignoring such problems? Thanks in advance.

1 2

shared folders
by Scherff 03 Oct '16

03 Oct '16

Hi, i am stuck. Try to install shared folders - dovecot is running fine. ACL is working. But i can't get running the shared folders. Maybe someone can help. This are the relevant conf. I think i have some mistake there - perhaps in location - changed try and error - stuck: mail_home = /var/vmail/mailboxes/%d/%n mail_location = maildir:~/mail:LAYOUT=fs namespace { hidden = no ignore_on_failure = no list = children location = maildir:%%h/mail:INDEX=%h/mail/shared/%%u:CONTROL=%h/mail/shared/%%u prefix = shared/%%u/ separator = / subscriptions = yes type = shared } namespace inbox { inbox = yes location = mailbox Archives { auto = subscribe special_use = \Archive } mailbox Drafts { auto = subscribe special_use = \Drafts } mailbox Notes { auto = subscribe } mailbox Sent { auto = subscribe special_use = \Sent } mailbox Spam { auto = subscribe special_use = \Junk } mailbox Trash { auto = subscribe special_use = \Trash } prefix = } plugin { # global acl - prevent expunche for some folder acl = vfile:/var/vmail/dovecot-acl acl_shared_dict = file:/var/vmail/db/shared-mailboxes.db } protocol imap { imap_idle_notify_interval = 15 mins mail_max_userip_connections = 30 mail_plugins = " acl imap_acl" } protocol lmtp { mail_plugins = " acl" } Need some hint. Thanks Alfred

2 1

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 30 Sep '16

30 Sep '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 30 Sep '16

30 Sep '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 30 Sep '16

30 Sep '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