Re: [Dovecot] Ignore prefix given by client?
On Wed, Oct 15, 2008 at 09:57:04PM +0300, Timo Sirainen wrote: > On Oct 15, 2008, at 9:42 PM, Tim Bishop wrote: > > >The problem is when a user specifies their own prefix in their mail > >client (if it's blank there are no problems). If they have ~/Mail none > >of the folders show up. > > > >I've had a play with namespaces in an attempt to fix that, but it > >doesn't seem to be doing what I want. > > http://wiki.dovecot.org/Namespaces configuration works, but v1.1 had a > bug that's not fixed in v1.1.4 yet: > http://hg.dovecot.org/dovecot-1.1/rev/b61424a50786 Thanks Timo, that did the trick. Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984
[Dovecot] Virtual Domains and Master Users
Can I have a master users list for each virtual domain? I'm not sure
from what I read on the page:
http://wiki.dovecot.org/Authentication/MasterUsers
auth default {
mechanisms = plain login CRAM-MD5
passdb passwd-file {
args = /var/mail/vhosts/%d/passwd.masterusers
master = yes
pass = yes
}
passdb passwd-file {
args = username_format=%n /var/mail/vhosts/%d/passwd
}
userdb passwd-file {
args = username_format=%n /var/mail/vhosts/%d/passwd
}
...
}
TIA,
Rod
--
Re: [Dovecot] Ignore prefix given by client?
On Oct 15, 2008, at 9:42 PM, Tim Bishop wrote: The problem is when a user specifies their own prefix in their mail client (if it's blank there are no problems). If they have ~/Mail none of the folders show up. I've had a play with namespaces in an attempt to fix that, but it doesn't seem to be doing what I want. http://wiki.dovecot.org/Namespaces configuration works, but v1.1 had a bug that's not fixed in v1.1.4 yet: http://hg.dovecot.org/dovecot-1.1/rev/b61424a50786 PGP.sig Description: This is a digitally signed message part
[Dovecot] Ignore prefix given by client?
Hi all, I'm new to Dovecot, but so far I've been really impressed with what I've seen. I hope someone can help with the following question. We're migrating from a setup where some of our users use mbox with UW imap. The problem is we've never enforced a folder prefix, so some have their folders in ~/, others in ~/mail and others in ~/Mail. We've also got some users using maildir with Courier imap. I decided the easiest way to get this working transparently for the users was to use the post-login scripting approach. My script manages to locate the user's mail and sets MAIL accordingly. This all works a treat. The problem is when a user specifies their own prefix in their mail client (if it's blank there are no problems). If they have ~/Mail none of the folders show up. I've had a play with namespaces in an attempt to fix that, but it doesn't seem to be doing what I want. So my question is: is it possible for Dovecot to simply ignore the folder prefix given by the client? Thanks, Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984
Re: [Dovecot] Something weird happening...
On 2008-10-08 10:44:25 +0200, Claudio Prono wrote: > I use Dovecot dovecot11-1.1.3-5.1 from OpenSuSE 11, when i send a mail > from the logs i read: > > Oct 8 10:36:31 mail postfix/pipe[17934]: A360A851: > to=<[EMAIL PROTECTED]>, relay=dovecot, delay=0.22, > delays=0.18/0/0/0.04, dsn=4.3.0, status=deferred (temporary failure. > Command output: Can't open log file /var/log/dovecot-err.log: Permission > denied ) > > But, log files seems ok: > > -rw--- 1 777 root 56 Oct 8 10:35 dovecot-err.log > -rw--- 1 777 root 302 Oct 8 10:35 dovecot-inf.log > remove the log_path from your config and let it send it to syslog? it will go to /var/log/mail in that case. -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Re: [Dovecot] imap segfaults in dovecot 1.2 on logout
Bernhard Herzog <[EMAIL PROTECTED]> writes: > On 15.10.2008, Bernhard Herzog wrote: >> I recall having a similar problem with the Annotation plugin. IIRC it had >> something to do with not unregistering commands properly when the plugin >> was unloaded. In that case the array of known commands retains dangling >> pointers to the names of the commands that point to the unloaded shared >> object file. > > I think this is indeed the case with the ACL plugin if it is patched to > implement the ACL IMAP commands, as is the case in the kolab branch. The > commands are only unregistered if acl_next_hook_mail_storage_created != NULL. > > Now that variale is set in acl_plugin_init but there's no guarantee that it > will always be != NULL afterwards. If the ACL plugin is the first plugin to > change hook_mail_storage_created, acl_next_hook_mail_storage_created will be > NULL after acl_plugin_init has been executed and registered the commands, but > the deinit function will not unregister the commands. Yes, I came to the same conclusion. I checked in a fix to the acl-branch[0] as well as to the generic kolab-branch[1] repository. cheers sascha [0] http://hg.intevation.org/kolab/dovecot-1.2_acl-branch/ [1] http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/ -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ 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 pgpneae0DB4uJ.pgp Description: PGP signature
Re: [Dovecot] imap segfaults in dovecot 1.2 on logout
On 15.10.2008, Bernhard Herzog wrote: > I recall having a similar problem with the Annotation plugin. IIRC it had > something to do with not unregistering commands properly when the plugin > was unloaded. In that case the array of known commands retains dangling > pointers to the names of the commands that point to the unloaded shared > object file. I think this is indeed the case with the ACL plugin if it is patched to implement the ACL IMAP commands, as is the case in the kolab branch. The commands are only unregistered if acl_next_hook_mail_storage_created != NULL. Now that variale is set in acl_plugin_init but there's no guarantee that it will always be != NULL afterwards. If the ACL plugin is the first plugin to change hook_mail_storage_created, acl_next_hook_mail_storage_created will be NULL after acl_plugin_init has been executed and registered the commands, but the deinit function will not unregister the commands. 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 segfaults in dovecot 1.2 on logout
Sascha Wilde <[EMAIL PROTECTED]> writes: > when logging out like > > a001 logout > > the imap child dies from signal 11. The back trace looks like this: > > Program received signal SIGSEGV, Segmentation fault. > 0xb7ed4991 in strcasecmp () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0xb7ed4991 in strcasecmp () from /lib/tls/i686/cmov/libc.so.6 > #1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at > commands.c:83 Could this be the same issue as the one in http://dovecot.org/list/dovecot/2008-October/034211.html ? If so, it appears to be a bug in the ACL plugin. I recall having a similar problem with the Annotation plugin. IIRC it had something to do with not unregistering commands properly when the plugin was unloaded. In that case the array of known commands retains dangling pointers to the names of the commands that point to the unloaded shared object file. 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 segfaults in dovecot 1.2 on logout
On Oct 15, 2008, at 5:57 PM, Sascha Wilde wrote:
#1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at
commands.c:83
83 if (strcasecmp(cmd[i].name, name) == 0) {
(gdb) p cmd[i]
$1 = {name = 0xb7e65ce7 , func =
0xb7e6432d, flags = 0}
^^^
For some reasons this does _not_ happen when I simply close the
connection (without explicitly logging out)...
Your plugin isn't probably unregistering some command it registered
and the plugin is unloaded before commands_deinit() is called.
valgrind might also show something.
PGP.sig
Description: This is a digitally signed message part
[Dovecot] imap segfaults in dovecot 1.2 on logout
Hi Timo,
when logging out like
a001 logout
the imap child dies from signal 11. The back trace looks like this:
Program received signal SIGSEGV, Segmentation fault.
0xb7ed4991 in strcasecmp () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7ed4991 in strcasecmp () from /lib/tls/i686/cmov/libc.so.6
#1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at commands.c:83
#2 0x0806ac56 in command_unregister_array (cmdarr=0x815ba8c, count=25) at
commands.c:101
#3 0x0806ae36 in commands_deinit () at commands.c:146
#4 0x08073a8f in main_deinit () at main.c:273
#5 0x08073b7b in main (argc=1, argv=0xbfacb884, envp=0xbfacb88c) at main.c:310
(gdb) up
#1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at commands.c:83
83 if (strcasecmp(cmd[i].name, name) == 0) {
(gdb) p cmd[i]
$1 = {name = 0xb7e65ce7 , func = 0xb7e6432d,
flags = 0}
^^^
For some reasons this does _not_ happen when I simply close the
connection (without explicitly logging out)...
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ 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
pgpJBSIAql0go.pgp
Description: PGP signature
[Dovecot] Multiple IMAP connections.
There is a project (catmail) to build a webmail front end using the Catalyst Framework and the question came up about multiple connections per user. Specifically the question was: "The IMAP server can support multiple connections, but do you think the backend should support multiple connections for separate folders or one IMAP connection for one session?" Since my servers are too low volume to have hit any kind of resource limits, and I believe Thunderbird mostly does the "Right Thing", I'm asking how you, that have higher volume systems, would prefer connections handled. Also I believe there was a thread, or two :-), on the way some of the other webmail programs handle connections. Not good? Thanks for all insights and suggestions. Rod --
[Dovecot] deliver does not work with new shared namespaces in dovecot 1.2
Hi Timo, checking my new userdb-checkpassword back end is stumbled across the fact, that the new shared namespace definitions possible in dovecot stop deliver from working. The log says: Oct 15 14:37:43 burlywood3 deliver([EMAIL PROTECTED])[24502]: Namespace: type=shared, prefix=users/%%u/, sep=/, inbox=no, hidden=no, list=no, subscriptions=no Oct 15 14:37:43 burlywood3 deliver([EMAIL PROTECTED])[24502]: Namespace 'users/': shared: Shared namespace prefix contains unknown variables Oct 15 14:37:43 burlywood3 deliver([EMAIL PROTECTED])[24502]: Fatal: Namespace initialization failed I guess the primary (only?) case where these shared namespaces are needed for delivery is the use of sieve. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ 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 pgp7dKCAEfeqQ.pgp Description: PGP signature
Re: [Dovecot] Bug: MODSEQ FETCH return (?)
On Tue, 2008-10-14 at 21:29 -0600, Michael M. Slusarz wrote: > Unfortunately, Dovecot 1.2 is returning as follows: > S: * 1 FETCH (UID 1 MODSEQ 3 FLAGS (\Flagged \Deleted \Recent)) > > Where, under the RFC, I believe it should be: > S: * 1 FETCH (UID 1 MODSEQ (3) FLAGS (\Flagged \Deleted \Recent)) Thanks. I also wondered about this recently when writing a mail, but I assumed I MODSEQ 3 was correct, because there's no point in having parenthesis there. Wonder why it was done.. > Here is a proposed patch (WARNING: my C skills = zero): You missed another place where it's sent. Fixed both in: http://hg.dovecot.org/dovecot-1.2/rev/242e6d47f790 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Patch: use child_wait in passdb-checkpassword
Sascha Wilde <[EMAIL PROTECTED]> writes: > Sascha Wilde <[EMAIL PROTECTED]> writes: >> Now I'll try to do the same for my userdb, so that they should work at >> the same time -- stay tuned... > > I have a first working beta. I'll put a repository with the changes > on line soon... Done. You can find all the stuff here: http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/ The addition of child_wait and changes to passdb-checkpassword are in changeset 53b57b123f74, the new userdb back end is in a4d3ea1e52bc. Next steps will be cleaning up and documentation (at least in the sample config). cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ 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 pgpYTM1H2c3ZA.pgp Description: PGP signature
Re: [Dovecot] Search results as virtual folders
On Tue, 2008-10-14 at 17:21 -0700, Daniel L. Miller wrote: > This may have been asked before - if so I apologize. > > Some mail clients - like Thunderbird - can provide a virtual folder or > "saved search" to provide a list of mails that match certain criteria. > Obviously, unless special client-side caching is implemented - which > Thunderbird (my own client of choice) - does not, generation of these > folders take time. Does Dovecot have any provision for generating such > virtual folders? Possibly as the result of a sieve script? v1.2 tree supports http://wiki.dovecot.org/Plugins/Virtual (I fixed a few bugs after v1.2.alpha2 release). signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Patch: use child_wait in passdb-checkpassword
Sascha Wilde <[EMAIL PROTECTED]> writes:
> Thanks! Seems indeed helpful. I have changed passdb-checkpassword to
> use the child-wait stuff, see attached patch. (I have put
> child-wait.[ch] into src/lib/)
Doh! Forgot to attach the patch (which isn't to bad as it was faulty
anyway...).
This time I really attached it!
> Now I'll try to do the same for my userdb, so that they should work at
> the same time -- stay tuned...
I have a first working beta. I'll put a repository with the changes
on line soon...
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ 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 cd9fb9098f07 src/auth/auth.c
--- a/src/auth/auth.c Wed Oct 15 12:53:05 2008 +0200
+++ b/src/auth/auth.c Wed Oct 15 13:24:49 2008 +0200
@@ -1,6 +1,7 @@
/* Copyright (c) 2005-2008 Dovecot authors, see the included COPYING file */
#include "common.h"
+#include "child-wait.h"
#include "network.h"
#include "buffer.h"
#include "str.h"
@@ -32,6 +33,8 @@
auth->verbose_debug = getenv("VERBOSE_DEBUG") != NULL ||
auth->verbose_debug_passwords;
auth->verbose = getenv("VERBOSE") != NULL || auth->verbose_debug;
+
+ child_wait_init();
passdb_p = &auth->passdbs;
masterdb_p = &auth->masterdbs;
@@ -297,5 +300,6 @@
auth_request_handler_deinit();
passdb_cache_deinit();
+ child_wait_deinit();
pool_unref(&auth->pool);
}
diff -r cd9fb9098f07 src/auth/passdb-checkpassword.c
--- a/src/auth/passdb-checkpassword.c Wed Oct 15 12:53:05 2008 +0200
+++ b/src/auth/passdb-checkpassword.c Wed Oct 15 13:24:49 2008 +0200
@@ -12,6 +12,7 @@
#include "hash.h"
#include "env-util.h"
#include "safe-memset.h"
+#include "child-wait.h"
#include
#include
@@ -39,6 +40,9 @@
int exit_status;
unsigned int exited:1;
};
+
+struct child_wait *checkpassword_passdb_children;
+
static void checkpassword_request_close(struct chkpw_auth_request *request)
{
@@ -142,58 +146,41 @@
}
}
-static void sigchld_handler(int signo ATTR_UNUSED, void *context)
+static void sigchld_handler(struct child_wait_status *child_wait_status, void *context)
{
+ int status = child_wait_status->status;
+ pid_t pid = child_wait_status->pid;
struct checkpassword_passdb_module *module = context;
- struct chkpw_auth_request *request;
- int status;
- pid_t pid;
+ struct chkpw_auth_request *request =
+ hash_lookup(module->clients, POINTER_CAST(pid));
- /* FIXME: if we ever do some other kind of forking, this needs fixing */
- while ((pid = waitpid(-1, &status, WNOHANG)) != 0) {
- if (pid == -1) {
- if (errno != ECHILD && errno != EINTR)
-i_error("waitpid() failed: %m");
- return;
- }
+ if (request == NULL) {
+ i_error("checkpassword: sighandler called for unknown child %d", pid);
+ return;
+ }
- request = hash_lookup(module->clients, POINTER_CAST(pid));
- if (request == NULL) {
- /* unknown child finished */
- if (WIFSIGNALED(status)) {
-i_error("checkpassword: Unknown child %s died "
- "with signal %d", dec2str(pid),
- WTERMSIG(status));
- }
- continue;
- }
+ if (WIFSIGNALED(status)) {
+ i_error("checkpassword: Child %s died with signal %d",
+ dec2str(pid), WTERMSIG(status));
+ } else if (WIFEXITED(status)) {
+ request->exited = TRUE;
+ request->exit_status = WEXITSTATUS(status);
- if (WIFSIGNALED(status)) {
- i_error("checkpassword: Child %s died with signal %d",
-dec2str(pid), WTERMSIG(status));
- } else if (WIFEXITED(status)) {
- request->exited = TRUE;
- request->exit_status = WEXITSTATUS(status);
+ auth_request_log_debug(request->request,
+ "checkpassword", "exit_status=%d",
+ request->exit_status);
- auth_request_log_debug(request->request,
-"checkpassword", "exit_status=%d",
-request->exit_status);
-
- checkpassword_request_half_finish(request);
- request = NULL;
- } else {
- /* shouldn't happen */
- auth_request_log_debug(request->request,
-"checkpassword", "Child exited with status=%d",
-status);
- }
-
- if (request != NULL) {
- checkpassword_request_finish(request,
-PASSDB_RESULT_INTERNAL_FAILURE);
- }
+ checkpassword_request_half_finish(request);
+ request = NULL;
+ } else {
+ /* shouldn't happen */
+ auth_request_log_debug(request->request,
+ "checkpassword", "Child exited with status=%d",
+ status);
+ checkpassword_request_finish(request, PASSDB_RESULT_INTERNAL_FAILURE);
}
}
+
static void env_put_extra_fields(const char *extra_fields)
{
@@ -424,6 +411,13 @@
chkpw_auth_request);
hash_insert(module->clients, POINTER_CAST(pid), chkpw_auth_request);
+
+ if (checkpassword_passdb_children) {
+ child_wait_add_pid(checkpassword_passdb_children, pid);
+ } else {
+ checkpassword_passdb_children =
+ child_wait_new_with_pid(pid, sigchld_h
