[Dovecot] make archive emails undeletable?
I've been using dovecot for a year or two now, and really like it. I have a fairly simple setup, but I think it's time to get a little more advanced. I keep an "archive" of all my email, both sent and received. Every once in a while I get confused, and accidentally delete something from my archive. I also worry that I'll misconfigure a mail client some day and accidentally wipe out my "trash" folder. I would like some way to prevent deletion in several mailboxes. Is that possible? It looks like ACL could do this, but I can't quite figure out where to start. Any pointers would be greatly appreciated. Thanks, Rob
Re: [Dovecot] dovecot behind loadbalancers
Brandon Lamb schrieb: > On Fri, Oct 31, 2008 at 5:37 AM, Robert Schetterer > <[EMAIL PROTECTED]> wrote: >> Hi @ll, >> has anbody experience with >> dovecot behind load balancers >> im planning to test >> ha-proxy >> pen >> balance(ng) on ubuntu hardy in a HA-Cluster >> in front of dovecot servers >> >> -- >> Best Regards >> >> MfG Robert Schetterer >> >> Germany/Munich/Bavaria > > We use Linux Virtual Server as a frontend to almost all of our ISP > services (dns, smtp, pop3, imap, http). This gives you a single point > of failure so you should probably make sure you have two directors > (one as a backup). Hi Brandon HA means 2 Load Balancer with failover so no single point of failure -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] patch: list shared namespace
On Oct 31, 2008, at 10:03 PM, Bernhard Herzog wrote: On 31.10.2008, Timo Sirainen wrote: Right, it could (would) cause mailboxes to be listed that aren't supposed to be listed. I think you'll also have a problem if e.g. "foo" exists but doesn't have 'l' right and "foo/bar" exists and has 'l' right. I think % will currently not list "foo". If it behaved correctly it should list it as non-existing mailbox. That case seems to work correctly with my patch. Oh. Wonder why.. In my tests so far, it basically behaves exactly like you explain: LIST % -> List "foo" as non-existing LIST foo -> List "foo" as non-existing LIST * -> List "foo/bar" only Maybe there are circumstances that I didn't encounter yet, where it does indeed fail. Well, the main failure is that if the child mailboxes aren't listable, the parent mailbox shouldn't be listed either. Like if I share a secret/dovecot corp/contracts/google/october mailbox to someone then other people really shouldn't be seeing secret/dovecot corp/contracts/ google :) PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] patch: list shared namespace
On 31.10.2008, Timo Sirainen wrote: > Right, it could (would) cause mailboxes to be listed that aren't > supposed to be listed. I think you'll also have a problem if e.g. "foo" > exists but doesn't have 'l' right and "foo/bar" exists and has 'l' > right. I think % will currently not list "foo". If it behaved correctly > it should list it as non-existing mailbox. That case seems to work correctly with my patch. In my tests so far, it basically behaves exactly like you explain: > LIST % -> List "foo" as non-existing > LIST foo -> List "foo" as non-existing > LIST * -> List "foo/bar" only Maybe there are circumstances that I didn't encounter yet, where it does indeed fail. Bernhard -- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: This is a digitally signed message part.
Re: [Dovecot] patch: list shared namespace
On Oct 31, 2008, at 9:42 PM, Bernhard Herzog wrote: The behavior of the _verify funtion is the problem. It only rebuilds if any of the already referenced acl files has changed but not if new acl files have been created. I'm not sure yet what the best way is to determine whether new mailbox whose acllist is being verified has a new acl file. Doesn't it notice the new ACL file when that mailbox is being listed (or selected)? That's at least how I planned that it should work. Also your IMAP ACL plugin probably should somehow trigger the dovecot- acl-list rebuild whenever an ACL is added to a new mailbox. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] patch: list shared namespace
On 28.10.2008, Bernhard Herzog wrote: > - The dovecot-acl-list is not always rebuilt, even when it should have >been, AFAICT. In particular, if the file exists but is empty, it's >never updated, even when ACL later change. Maybe this is a bug in >the Kolab branch. It happens with vanilla dovecot 1.2 too. Here's my analysis so far: The dovecot-acl-list is rebuilt by acl_backend_vfile_acllist_rebuild which called in two places, acl_backend_vfile_acllist_refresh and acl_backend_vfile_acllist_verify. The _refresh-funtion rereads the file if it has changed and rebuilds it if it cannot be read. The _verify-function checks whether any of the acl files referenced by the dovecot-acl-list file has been changed and rebuilds the dovecot-acl-list file if that's the case. The behavior of the _verify funtion is the problem. It only rebuilds if any of the already referenced acl files has changed but not if new acl files have been created. I'm not sure yet what the best way is to determine whether new mailbox whose acllist is being verified has a new acl file. Cheers, Bernhard -- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: This is a digitally signed message part.
Re: [Dovecot] imap dump-capability fails Dovecot 1.1.6
Timo Sirainen a =E9crit : > On Fri, 2008-10-31 at 08:32 +0100, Thorsten Vollmer wrote: >> Hi Timo, >> >> Dovecot fails to start after upgrading from 1.1.4 to 1.1.6: >> >> Fatal: userdb didn't return a home directory, but mail location used i= t >> (%h): %h/mail:CONTROL=3D%h/control:INDEX=3D%h/index >> Error: imap dump-capability process returned 89 >> Fatal: Invalid configuration in /etc/dovecot/dovecot.conf >> >> Adding a fake home directory to args in >> master-settings.c:get_imap_capability solved the problem for me, but >> there may be a more correct fix. >=20 > Yes, that's the correct fix: > http://hg.dovecot.org/dovecot-1.1/rev/2fbd36039526 >=20 > One workaround is to use ~ instead of %h. It'll log errors, but it stil= l > works. >=20 > Wonder how many people will have this problem.. Perhaps I'll have to > release 1.1.7 just because of it. >=20 I did too... (but found the workaround at first try) --=20 ___ / Geoffroy DESVERNAY |\ /\`Service info`| Tel: (+33|0)4 91 05 45 24 /\ \/ Ecole Centrale de Marseille | Fax: (+33|0)4 91 05 45 98 \/ \ (ex-EGIM)| Mail: [EMAIL PROTECTED] / --- signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Dovecot+PostfixAdmin+PostgreSQL on FreeBSD 7
Erdenebat Gantumur a écrit : > Hi dear, Timo > > When I execute dovecot -F then it doesn't exiting. During this time when > try to telnet 110 port it shows > > Escape character is '^]'. > +OK Dovecot ready. > ^] > telnet> quit > > Also i've set log and log_info path. In dovecot_info.log it's showing: > > dovecot: 2008-10-23 01:23:39 Info: Dovecot v1.1.3 starting up > dovecot: 2008-10-23 01:23:39 Info: auth(default): pgsql: Connected to > postfix > dovecot: 2008-10-23 01:25:09 Info: pop3-login: Disconnected (no auth > attempts): rip=x.x.x.x, lip=x.x.x.x, secured > dovecot: 2008-10-23 01:25:27 Info: imap-login: Disconnected (no auth > attempts): rip=x.x.x.x, lip=x.x.x.x, secured > dovecot: 2008-10-23 01:25:51 Info: pop3-login: Disconnected (no auth > attempts): rip=x.x.x.x, lip=x.x.x.x, secured > > What does it mean? How can I run dovecot just like common way > /usr/local/etc/rc.d/dovecot start? When I execute that command it > doesn't start. Thank you. > Hi, Are you sure there is smething like 'dovecot_enable="YES"' in /etc/rc.conf ? tip: try /usr/local/etc/rc.d/dovecot rcvar Hope this helps Geoffroy signature.asc Description: OpenPGP digital signature
Re: [Dovecot] FW: nfs troubles
Hi Timo, The server and client both are Debian machines. Server: debian etch, kernel 2.6.18-5-amd64, nfs-kernel-server 1.0.10-6+etch.1 (v3) Client: debian sarge, kernel 2.6.8-2-386, nfs-common 1.0.10-6+etch.1 Regards, Bas -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Timo Sirainen Verzonden: vrijdag 31 oktober 2008 16:59 Aan: Bas van Oosterum CC: dovecot@dovecot.org Onderwerp: Re: [Dovecot] FW: nfs troubles On Fri, 2008-10-31 at 11:38 +0100, Bas van Oosterum wrote: > I upgraded to dovecot 1.1.6 to be able to use NFS. Got a little issue: > I can't move mail to another IMAP folder (so I can't delete to: moving > to .trash does not work. Error message > > > > Oct 31 11:07:45 jozua-mailserver dovecot: IMAP([EMAIL PROTECTED]): > fdatasync_path(/var/mail/kerknet.org/nicolette/Maildir/.Trash/cur) failed: > Invalid What OS on NFS client? What do you use as NFS server? There's no setting that can fix this for you, except fsync_disable=yes, but that's not a very good idea with NFS. No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.5/1757 - Release Date: 30-10-2008 14:35
Re: [Dovecot] imap dump-capability fails Dovecot 1.1.6
On Fri, 2008-10-31 at 17:32 +0100, Bernhard Herzog wrote: > On 31.10.2008, Timo Sirainen wrote: > > On Fri, 2008-10-31 at 08:32 +0100, Thorsten Vollmer wrote: > [...] > > > Adding a fake home directory to args in > > > master-settings.c:get_imap_capability solved the problem for me, but > > > there may be a more correct fix. > > > > Yes, that's the correct fix: > > http://hg.dovecot.org/dovecot-1.1/rev/2fbd36039526 > > With the corresponding fix in dovecot-1.2 dovecot doesn't start anymore for > me: > > setgid(65534) failed with euid=1001, gid=1001, egid=1001: Operation not > permitted > Error: imap dump-capability process returned 89 > > It turns out that rev 2fbd36039526 changed the indices in the args array that > some other code get_imap_capability relied on so that the uid and gid are not > overwritten properly when dovecot is not started as root. See this patch: Oh. Right. It didn't give that error with me, so I assumed it worked. Well, I fixed it just by moving home to last: http://hg.dovecot.org/dovecot-1.1/rev/cbde69815b8a > The Patch is not an attachment this time to avoid mailman breaking the > openpgp > signature. Hmm. It does that? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] imap dump-capability fails Dovecot 1.1.6
On 31.10.2008, Timo Sirainen wrote:
> On Fri, 2008-10-31 at 08:32 +0100, Thorsten Vollmer wrote:
[...]
> > Adding a fake home directory to args in
> > master-settings.c:get_imap_capability solved the problem for me, but
> > there may be a more correct fix.
>
> Yes, that's the correct fix:
> http://hg.dovecot.org/dovecot-1.1/rev/2fbd36039526
With the corresponding fix in dovecot-1.2 dovecot doesn't start anymore for
me:
setgid(65534) failed with euid=1001, gid=1001, egid=1001: Operation not
permitted
Error: imap dump-capability process returned 89
It turns out that rev 2fbd36039526 changed the indices in the args array that
some other code get_imap_capability relied on so that the uid and gid are not
overwritten properly when dovecot is not started as root. See this patch:
diff -r 281ef8e9863f src/master/master-settings.c
--- a/src/master/master-settings.c Fri Oct 31 18:03:39 2008 +0200
+++ b/src/master/master-settings.c Fri Oct 31 17:22:06 2008 +0100
@@ -636,8 +636,8 @@ static bool get_imap_capability(struct s
uid = geteuid();
if (uid != 0) {
/* use the current user */
- args[0] = t_strdup_printf("uid=%s", dec2str(uid));
- args[1] = t_strdup_printf("gid=%s", dec2str(getegid()));
+ args[1] = t_strdup_printf("uid=%s", dec2str(uid));
+ args[2] = t_strdup_printf("gid=%s", dec2str(getegid()));
}
if (pipe(fd) < 0) {
The Patch is not an attachment this time to avoid mailman breaking the openpgp
signature.
Regards,
Bernhard
--
Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
signature.asc
Description: This is a digitally signed message part.
Re: [Dovecot] dovecot expire doesn't work (?)
On Thu, 2008-10-30 at 17:50 +0100, LÉVAI Dániel wrote: > > The "/" hardcoding only means the "%" wildcard matching, meaning if > > you've a mailbox "foo/bar" then "%" would match only "foo" part, but > > if you've a mailbox "foo.bar" then "%" would match the full > > "foo.bar". In any case you'll need to use the separator you've > > configured in your namespaces. > Where have I configured that? I'm just using maildir: in the > mail_location, If you haven't configured any namespaces, Dovecot will use the default namespace with the default maildir separator (dot). > and if I create a subdirectory with my MUA, in the > server on the filesystem it will separate it from the parent with a > dot. Is this configurable? No. The filesystem separator is always a dot. But you can configure the "virtual separator" with namespaces, i.e. what the clients will see and what you'll use in configuration files to specify the mailbox names. > > > Yep, now I can understand that, but what *is* weird, that the > > > only "debug" information comes from this expire-tool when ran with > > > the --test option. If I run it without it, it won't output anything > > > anywhere. It would be nice to increase the logging for this (with > > > or without the --test option), eg. when mail_debug=yes. > > > > What should it write? I guess -v parameter could do something. > > mail_debug=yes could affect the plugin's logging. > I think, it should display that it found an "expire = something" entry > in dovecot.conf, and that it could find a matching directory under the > mail_location. While iterating over the messages that it has found, it > would be nice if it would write an info line with each message, > including the message's path/name, Printing the message's path works only with maildir. Expire plugin works also with mbox. It could print message's UID number though. > the message's expire date in the > future, that it has been expunged, or that it would have been expunged, > but the --test option was set. I'll see about adding these. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Separate quotas not displayed correctly
On Fri, 2008-10-31 at 10:45 +0100, Laurent Blume wrote: > Hello all, > > My system is set up to have quotas both on /var/mail, where emails are > received, and on /export/home, where users' homedirs are. > But the client (Thunderbird) shows the same /export/home values both for > the Inbox and for the folders in the homedir, so a user cannot know > where she stands on her /var/mail use. First of all see if the problem is with Thunderbird or Dovecot. Ask the quota values directly from Dovecot: telnet localhost 143 a login user pass b getquotaroot inbox c getquotaroot some-other-box If b/c didn't return correct values, try also: d getquota INBOX e getquota Others signature.asc Description: This is a digitally signed message part
Re: [Dovecot] imap dump-capability fails Dovecot 1.1.6
On Fri, 2008-10-31 at 08:32 +0100, Thorsten Vollmer wrote: > Hi Timo, > > Dovecot fails to start after upgrading from 1.1.4 to 1.1.6: > > Fatal: userdb didn't return a home directory, but mail location used it > (%h): %h/mail:CONTROL=%h/control:INDEX=%h/index > Error: imap dump-capability process returned 89 > Fatal: Invalid configuration in /etc/dovecot/dovecot.conf > > Adding a fake home directory to args in > master-settings.c:get_imap_capability solved the problem for me, but > there may be a more correct fix. Yes, that's the correct fix: http://hg.dovecot.org/dovecot-1.1/rev/2fbd36039526 One workaround is to use ~ instead of %h. It'll log errors, but it still works. Wonder how many people will have this problem.. Perhaps I'll have to release 1.1.7 just because of it. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] FW: nfs troubles
On Fri, 2008-10-31 at 11:38 +0100, Bas van Oosterum wrote: > I upgraded to dovecot 1.1.6 to be able to use NFS. Got a little issue: I > can't move mail to another IMAP folder (so I can't delete to: moving to > .trash does not work. Error message > > > > Oct 31 11:07:45 jozua-mailserver dovecot: IMAP([EMAIL PROTECTED]): > fdatasync_path(/var/mail/kerknet.org/nicolette/Maildir/.Trash/cur) failed: > Invalid What OS on NFS client? What do you use as NFS server? There's no setting that can fix this for you, except fsync_disable=yes, but that's not a very good idea with NFS. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] patch: list shared namespace
On Fri, 2008-10-31 at 12:52 +0100, Bernhard Herzog wrote: > On 28.10.2008, Bernhard Herzog wrote: > > - List with "%" doesn't list all intermediate mailboxes. > > > >On the one hand arthur sees this: > > > > x LIST "" "*" > > ... > > * LIST (\Noselect \HasChildren) "/" "users/ford" > > * LIST (\HasNoChildren) "/" "users/ford/INBOX/hhgttg" > > x OK List completed. > > > >OTOH, with "%" only this: > > > > x LIST "" "users/ford/%" > > x OK List completed. > > I've looked into this. The problem is that acl_mailbox_list_info_is_visible > in src/plugins/acl/acl-mailbox-list.c considers nonexistent mailboxes as not > visible. The attached patch fixes that for me. I'm not sure it really is > the right fix, though. Maybe it would cause some mailboxes to be listed even > though they shouldn't. Right, it could (would) cause mailboxes to be listed that aren't supposed to be listed. I think you'll also have a problem if e.g. "foo" exists but doesn't have 'l' right and "foo/bar" exists and has 'l' right. I think % will currently not list "foo". If it behaved correctly it should list it as non-existing mailbox. The real solution would be to find out if there are any visible child mailboxes. That's kind of annoying to implement though. You'll only need to do that if the mailbox list pattern expects that mailbox to be returned. For example with the above foo and foo/bar mailboxes: LIST % -> List "foo" as non-existing LIST foo -> List "foo" as non-existing LIST * -> List "foo/bar" only I'm not exactly sure what's the right way to implement this. That's why it's still in my TODO list instead of actually implemented. :) > There's one thing about acl_mailbox_list_info_is_visible and struct > acl_mailbox_list_iterate_context that I don't understand. What's the member > struct mailbox_info info; used for? Looks like it's a bug. Perhaps I moved some of the code to acl_mailbox_list_info_is_visible() which broke it. The idea was anyway to modify info.flags and store them to ctx->info and then return ctx->info from the function. But that's clearly not happening. Fixed: http://hg.dovecot.org/dovecot-1.2/rev/692aac54ae1c ..and I immediately noticed that's buggy too, so..: http://hg.dovecot.org/dovecot-1.2/rev/ca4e277a6615 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] patch: list shared namespace
On Tue, 2008-10-28 at 21:07 +0100, Bernhard Herzog wrote:
> One of the main problems the patch addresses is getting a list of all
> users that have mailboxes the logged in user can see. The patch uses a
> dict to cache information about which users have at least one mailbox
> that is visible to other users. The dict doesn't cache which other
> users, though. The cache entry for a given user is updated whenever the
> dovecot-acl-list file in the maildir root directory is updated. This
> ties the implementation to a specific acl backend to an extent, but that
> shouldn't be a problem at the moment.
What I'm worrying here is if all users have shared something. For
example how does this work with global ACLs? IIRC if there's a global
ACL for e.g. "Spam", Dovecot will create dovecot-acl-list with "Spam" in
it for all users. Even without global ACLs the number of users sharing
something might be a bit too large.
So the performance would be a lot better if the dict stored something
like source_user -> dest, where dest would be all the user names and
group names that are included in the user's ACLs (for any mailbox). Then
you'd look only at those users' mailboxes where you or your groups are
mentioned. Negative user/group rules perhaps shouldn't be in the dict.
> I'm not sure the new hook is really needed. The patch could perhaps
> just as well extend the acl_next_hook_mail_storage_created and
> acl_next_hook_mailbox_list_created functions to do the namespace
> creation when they're called for a shared storage or mailbox list.
Perhaps hook_mail_namespaces_created?
Some other things:
v1.2 code supports multiple users per process. That means you can't
really use getenv("USER") and you can't store per-user objects as static
variables. Rather you should hook into hook_mail_user_created and add
the per-user variables to the mail_user structure. See for example
lazy-expunge plugin (struct lazy_expunge_mail_user) or quota plugin how
that works.
i_info("no acl_shared_dict specified; shared namespaces will not be
listed") could be written only if getenv("DEBUG") != NULL.
Is acl_shared_debug stuff only a temporary developer debugging thing, or
will it be useful also for sysadmins?
> All of my tests so far involved a shared namespace of the form
>
> namespace shared {
> separator = /
> prefix = users/%%u/
> location = maildir:.../var/mail/%%u:...
> subscriptions = no
> list = yes
> hidden = no
> }
>
> Also, let's assume two users, ford and arthur with ford's "INBOX/hhgttg"
> available to arthur as "users/ford/INBOX/hhgttg". Arthur may not list
> ford's INBOX, though. In the following the current user is always
> arthur.
>
> I found the following problems:
>
> - LIST response includes namespaces the user doesn't really have access
>to. E.g. if there's another user, zaphod who's made some mailbox
>available to somebody else, but not arthur, arthur still sees
>
>* LIST (\Noselect \HasChildren) "/" "users/zaphod"
>
>Not sure it's worth fixing this, though.
It'll expose other users' names, which isn't good. It needs to be fixed
before I can make a release. Probably not too difficult though. I think
the ACL plugin's mailbox listing code could detect when a shared
namespace prefix is listed and not show it if it doesn't have visible
mailboxes under it. And that's related to the next problem:
> - List with "%" doesn't list all intermediate mailboxes.
Yes, this is actually in my TODO list already. I'll read and aswer to
your next mail about this..
> - The dovecot-acl-list is not always rebuilt, even when it should have
>been, AFAICT. In particular, if the file exists but is empty, it's
>never updated, even when ACL later change. Maybe this is a bug in
>the Kolab branch.
I haven't actually tested dovecot-acl-list all that much, so it's
possible that there are bugs in it.
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] New %%h variable for shared namespaces (was: New generic userdb lookup api)
On Tue, 2008-10-28 at 14:11 +0100, Sascha Wilde wrote: > Sascha Wilde <[EMAIL PROTECTED]> writes: > > Ok, as discussed I have made some changes (hopefully improvements) in > > the new "auth-master" API for userdb requests... > > And using this new I finally put a first alpha version of the missing > %%h variable for shared name spaces together. > > See http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/rev/e83efa40a1dc The auth connection could be kept alive longer than for one lookup if you put the auth_connection to shared_storage. That'd require creating struct shared_storage, but it should be pretty easy (see e.g. struct cydir_storage or maildir_storage). There's no need to i_new() struct auth_user_reply. It could just be allocated from stack. And I suppose memset(&reply, 0, sizeof(reply)) before using. Use t_strdup(reply->home) and you won't leak memory (it gets freed "later"). The current i_strdup() will leak memory. You could check if %h is even needed before doing the lookup. Just a while ago I added var_has_key() that makes it easy. If %h is used and the home lookup fails, fail the namespace creation. Use mail_storage_set_critical() rather than i_error() (and i_info()). Although looks like I'm also using i_error() there already, I should fix it. :) Hmm. The auth-master.h API could use a small change too: auth_master_init() shouldn't try to connect to auth socket yet (so it would never fail). auth_master_user_lookup() instead would try to connect there if the connection is missing. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Problem with Dovecot 1.1.4 and dovecot-antispam 20080829
On Thu, 30 Oct 2008 22:55:34 +0100, Tom Hendrikx <[EMAIL PROTECTED]> wrote: > HILT Guillaume wrote: >> On Thu, 30 Oct 2008 10:51:43 +0100, Guillaume Hilt >> <[EMAIL PROTECTED]> wrote: >>> Hi there, >>> >>> I'm running a server under Gentoo 64 with postfix 2.5.5, Dovecot >>> 1.1.4-r1 and Dovecot-antispam 20080829 (all are the lastest versions >>> availables under Portage). >>> I ran into a problem when I log in to my mailbox : >>> >>> Oct 30 10:39:23 ks29138 dovecot: IMAP(hiltg): Loading modules from >>> directory: /usr/lib64/dovecot/imap >>> Oct 30 10:39:23 ks29138 dovecot: IMAP(hiltg): Module is for different >>> version 1.1.1: /usr/lib64/dovecot/imap/lib90_antispam_plugin.so >>> Oct 30 10:39:23 ks29138 dovecot: Fatal: IMAP(hiltg): Couldn't load >>> required plugins >>> >>> Is there another version for Dovecot 1.1.4 out there or must I go back >>> to 1.1.1 ? >>> >>> Thanks, >>> >>> Guillaume >>> >> >> Compiling the head snapshot fixed the problem, sounds like portage needs >> a >> new ebuild for this plugin. > > > Acutally, the plugin needs to be compiled against the version of dovecot > you're running. So a reinstall of the available version in portage > *after* emerging a new dovecot version would suffice too > > Actually, I emerged the plugin after dovecot.
Re: [Dovecot] Backing Up
> [EMAIL PROTECTED] wrote: >> One option that I would prefer if I were to backup the entire store with >> one command would be generating a snapshot of the file system. >> And then rsync or cp that snapshot. That way youll always get a >> consistent backup and you wont have to worry about how long the backup >> takes to finish. > > Snapshot seems like an excellent idea to avoid files missing files > moving between /cur and /new. However, it should be pointed out that > this is extra io for the server (with LVM at least) whilst the backup is > running I only have experience wuth UFS (FreeBSD) and ZFS (Solaris). Snapshots on UFS is a horrible thing for large file systems. Snapshots on ZFS is marvellous (which I use). It does not result in any extra IO whatsoever due to some clever designing. If you have the option of using ZFS it's definitely the best way to do it. Regards, Mikkel
Re: [Dovecot] Backing Up
On Thu, 2008-10-30 at 14:42 -0400, Allen Belletti wrote: > I'd like to add my vote here as well; dbox would be *the* feature that > would make me happy. I'm the guy who asked a few weeks ago about ways to > speed access on our GFS clustered mail environment. > > Meanwhile, I've done some preliminary testing with mbox. As expected, > it's vastly faster than the Maildirs that we're using now. Of course it > pains me to go "backwards" but that may be the interim solution. I got > stopped temporarily when it seemed that I couldn't nest folders using > mbox, but hopefully that's untrue. You could use Maildir++ layout with mboxes too: mail_location = mbox:~/mail:LAYOUT=maildir++ mbox handling code is less stable than maildir code though. signature.asc Description: This is a digitally signed message part
[Dovecot] dovecot behind loadbalancers
Hi @ll, has anbody experience with dovecot behind load balancers im planning to test ha-proxy pen balance(ng) on ubuntu hardy in a HA-Cluster in front of dovecot servers -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] Backing Up
[EMAIL PROTECTED] wrote: > > Rsync seems to be loading information about each file into memory before > comparing the lists of files and doing the actual transfer. > That may be a lot of memory if you have a lot of files. > > I sometimes overcome this by rsync’ing each user or domain one at a time. > That way you will also limit issues of files no longer existing once the > transfer begins (makes rsync generate errors). > If you are using rsync2 then definitely this is good advice. Massive memory consumption to backup large mailboxes (and a long time before anything starts happening, ie snapshot useful) However, with rsync3 you should look at the options required to do use the incremental protocol. This trades a bit of efficiency on hardlinked files for lower memory and perhaps faster sync speeds. I haven't personally tried this, but reports on the web seem promising. You need rsync3 at both ends of the link and to examine your sync options a little However, one thing which is sadly missing on rsync is a fuzzy option which can spot files moving from /new to /cur... This may well cause additional load for imap backups which is potentially avoidable with a simple copy. I suspect it would be easy to patch a custom bit of code to handle this though..? > One option that I would prefer if I were to backup the entire store with > one command would be generating a snapshot of the file system. > And then rsync or cp that snapshot. That way you’ll always get a > consistent backup and you won’t have to worry about how long the backup > takes to finish. > Snapshot seems like an excellent idea to avoid files missing files moving between /cur and /new. However, it should be pointed out that this is extra io for the server (with LVM at least) whilst the backup is running I should think rsync3 incremental, plus some custom patching to look for files moving between /cur and /new would be very efficient for backing up maildir filestores (at least to the extent your filesystem allows efficient iterating over lots of files) Ed W
Re: [Dovecot] patch: list shared namespace
On 28.10.2008, Bernhard Herzog wrote: > - List with "%" doesn't list all intermediate mailboxes. > >On the one hand arthur sees this: > > x LIST "" "*" > ... > * LIST (\Noselect \HasChildren) "/" "users/ford" > * LIST (\HasNoChildren) "/" "users/ford/INBOX/hhgttg" > x OK List completed. > >OTOH, with "%" only this: > > x LIST "" "users/ford/%" > x OK List completed. I've looked into this. The problem is that acl_mailbox_list_info_is_visible in src/plugins/acl/acl-mailbox-list.c considers nonexistent mailboxes as not visible. The attached patch fixes that for me. I'm not sure it really is the right fix, though. Maybe it would cause some mailboxes to be listed even though they shouldn't. There's one thing about acl_mailbox_list_info_is_visible and struct acl_mailbox_list_iterate_context that I don't understand. What's the member struct mailbox_info info; used for? Regards, Bernhard -- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner diff -r 7c615ac48711 src/plugins/acl/acl-mailbox-list.c --- a/src/plugins/acl/acl-mailbox-list.c Thu Oct 30 17:41:02 2008 +0200 +++ b/src/plugins/acl/acl-mailbox-list.c Fri Oct 31 12:43:38 2008 +0100 @@ -187,6 +187,9 @@ acl_mailbox_list_info_is_visible(struct /* skip ACL checks. */ return 1; } + + if ((info->flags & MAILBOX_NONEXISTENT) != 0) + return 1; acl_name = acl_mailbox_list_iter_get_name(&ctx->ctx, info->name); ret = acl_mailbox_list_have_right(ctx->ctx.list, acl_name, signature.asc Description: This is a digitally signed message part.
Re: [Dovecot] Backing Up
> Dave McGuire wrote: >> On Oct 29, 2008, at 3:42 PM, Scott Silva wrote: What is the best way to do a (server-side) backup of all mail in a user's mail? >>> I usually just rsync the /home directories to another server. The >>> inital sync >>> can take a while, but it gets faster after there is a base to work >>> from. >> >> ...and it's much less painful if you're using maildir instead of mbox! >> >>-Dave >> > I have to wonder. I have a mailserver that I do a bootable complete > image copy of with all files and O/S in two hours to an Ultrium-2 tape, > 95 GB. When I switch to maildir, I will go from some 25,000 mbox files > to 2.5 to 3 million files...I can't believe that isn't going to hurt and > will force me into incrementals. > My thoughts on rsync. You may want to consider that incremental backups wont help you much if you use Maildir. Incremental or full rsync still has to generate a list of all the files. Whether itll work for you is impossible to say. I guess youll just have to make a test. But you're right that the large amount of files will be an issue. Rsync seems to be loading information about each file into memory before comparing the lists of files and doing the actual transfer. That may be a lot of memory if you have a lot of files. I sometimes overcome this by rsyncing each user or domain one at a time. That way you will also limit issues of files no longer existing once the transfer begins (makes rsync generate errors). You can estimate the time needed to list all the files. Try and use iostat to get a rough idea of how many OIPS your system handles under max stress load and how many it handles under normal operation. The difference is the amount available to you during the backup. Divide the total number of files with the number of available IOPS. Say you have 100 IOPS available then it will take roughly 8 hours (3,000,000/100/3600=8.3 hours) to generate the list of 3,000,000 files. The afterwards transfer will probably be a lot faster. I'm not sure whether reading information about one file take up one IO operation. But that way of calculating the time to generate the lists wasn't much off last time I tried. One option that I would prefer if I were to backup the entire store with one command would be generating a snapshot of the file system. And then rsync or cp that snapshot. That way youll always get a consistent backup and you wont have to worry about how long the backup takes to finish. Regards, Mikkel
[Dovecot] FW: nfs troubles
Hi all, I upgraded to dovecot 1.1.6 to be able to use NFS. Got a little issue: I can't move mail to another IMAP folder (so I can't delete to: moving to .trash does not work. Error message Oct 31 11:07:45 jozua-mailserver dovecot: IMAP([EMAIL PROTECTED]): fdatasync_path(/var/mail/kerknet.org/nicolette/Maildir/.Trash/cur) failed: Invalid Argument I tried to use ll sorts of locking: no difference Who can help? Regards, Bas
[Dovecot] Separate quotas not displayed correctly
Hello all, My system is set up to have quotas both on /var/mail, where emails are received, and on /export/home, where users' homedirs are. But the client (Thunderbird) shows the same /export/home values both for the Inbox and for the folders in the homedir, so a user cannot know where she stands on her /var/mail use. This is Dovecot 1.1.5. As per the wiki, the dovecot.conf file contains this: quota = fs:INBOX:mount=/var/mail quota2 = fs:Others:mount=/export/home A sample user: # quota -v testimap Disk quotas for testimap (uid 1143): Filesystem usage quota limittimeleft files quota limit timeleft /export/home6490 1 15000 0 0 0 /var/mail 0 2 25000 0 0 0 When Icheck the Quota tab in the Properties of the Inbox, the field contains "Others", and the value are 6490 out of 1. Any idea why this doesn't display the value of /var/mail? Laurent -- / Leader de Projet & Communauté| I'm working, but not speaking for \ G11N http://fr.opensolaris.org | Bull Services http://www.bull.com / FOSUG http://guses.org |
Re: [Dovecot] dovecot -n - provide sys info too? - WAS: Re: Dovecot read only for users
El Jueves, 30 de Octubre de 2008 a las 20:15, Timo Sirainen escribió: > On Oct 30, 2008, at 9:02 PM, John Lightsey wrote: > > A little late, but I don't see any mention of /etc/lsb-release in > > the LSB specification. You probably want the output of /usr/bin/ > > lsb_release -d > > I don't think dovecot should execute external binaries. Sounds scary. You're right (as always :). But maybe using the same output for dovecot is a good idea. And lsb_release is a script (shell in RHEL4, python in Debian), so it seems easy. -- Joseba Torre. CIDIR Bizkaia. signature.asc Description: This is a digitally signed message part.
[Dovecot] imap dump-capability fails Dovecot 1.1.6
Hi Timo, Dovecot fails to start after upgrading from 1.1.4 to 1.1.6: Fatal: userdb didn't return a home directory, but mail location used it (%h): %h/mail:CONTROL=%h/control:INDEX=%h/index Error: imap dump-capability process returned 89 Fatal: Invalid configuration in /etc/dovecot/dovecot.conf Adding a fake home directory to args in master-settings.c:get_imap_capability solved the problem for me, but there may be a more correct fix. Regards, Thorsten # 1.1.6: /etc/dovecot/dovecot.conf # OS: Linux 2.6.9-023stab048.4-enterprise i686 Gentoo Base System version 1.6.14 protocols: imaps ssl_ca_file: /etc/dovecot/ca.crt ssl_cert_file: /etc/dovecot/server.crt ssl_key_file: /etc/dovecot/server.key ssl_parameters_regenerate: 48 login_dir: /var/run/dovecot/login login_executable: /usr/libexec/dovecot/imap-login login_process_size: 32 login_processes_count: 4 login_max_processes_count: 32 max_mail_processes: 32 mail_location: maildir:%h/mail:CONTROL=%h/control:INDEX=%h/index mail_process_size: 128 mail_plugins: expire antispam auth default: mechanisms: plain login user: nobody worker_max_count: 8 process_size: 128 passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf userdb: driver: static args: uid=vmail gid=vmail home=/var/userdata/%Lu socket: type: listen client: path: /var/run/dovecot/auth-client mode: 384 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: vmail plugin: expire: SPAM 30 expire_dict: proxy:/var/run/dovecot/dict-server:expire auth_socket_path: /var/run/dovecot/auth-master antispam_dspam_binary: /usr/bin/dspam antispam_dspam_args: --user;%Lu antispam_signature: X-DSPAM-Signature antispam_spam: SPAM dict: expire: mysql:/etc/dovecot/dovecot-dict.conf signature.asc Description: This is a digitally signed message part
