- dovecot - dovecot.org

Re: [Dovecot] [xmail] XMail + Dovecot
by Sabahattin Gucukoglu 17 Mar '10

17 Mar '10

What, exactly, is the problem? How do you want Dovecot and XMail to work together? I am setting up Dovecot to read from standard Maildirs in user home directories, because I am using a separate delivery agent (TMDA but would work for maildrop, Dovecot's deliver program and others) to deliver mails using mailproc.tab. So, even while XMail runs as root, Dovecot need not and there is no problem getting it to work just like with other MTAs. XMail can't help with delivery to Maildir because it runs as root, and unless you mess about with packet filters to non-root it you'll still end up using for instance XACLs to allow Dovecot to read the mails. For authentication of XMail to Dovecot you would have to write external authentication helpers that use Dovecot's protocol. Or, you can use checkpassword or PAM-POP3 or something else to try getting Dovecot to authenticate against the active XMail list of users. Or you can just do what I do, maintain two databases and keep them in sync. Cheers, Sabahattin

1 0

[Dovecot] Design: Asynchronous I/O for single/multi-dbox
by Timo Sirainen 17 Mar '10

17 Mar '10

The long term plan is to get all of Dovecot disk I/O asynchronous. The first step to that direction would be to make dbox/mdbox I/O asynchronous. This might also allow mbox/maildir to become partially asynchronous. http://www.dovecot.org/list/dovecot/2009-December/045481.html already started describing how the lib-storage API could be changed to support high-latency storages. Adding support for all of the paralellism would be nice, but probably not necessary as the first step. Then again, the API changes are necessary, so the parallelism optimizations probably aren't a huge task on top of that. Besides the API changes described in the above link, another change that's necessary is to add mail_get_nonblocking_stream(). The returned stream can return EAGAIN whenever it would need to block. Whenever sending message data to client, this stream would have to be used. It would also be used internally by all of message parsing/searching code. Luckily all of that already supports nonblocking input or can be easily modified to support it. Below are some thoughts how to go forward with this. I originally thought about writing a more specific plan, but I think this is good enough now to start coding. The target Dovecot version is v2.1, not v2.0. Filesystem API ============== The idea is to first abstract out all POSIX filesystem accessing in dbox/mdbox code. Non-blocking I/O works pretty nicely for socket I/O, so I thought I'd use a similar API for disk I/O as well: handle = open(path, mode) - this function can't fail. it's executed asynchronously. - mode=read-only: no writing to file - mode=append: appending to file is allowed handle = create(path, mode, permissions) - this function can't fail. it's executed asynchronously. - mode=fail-if-exists: commit() fails if file already exists - mode=replace-if-exists: commit() replaces file if it already exists - permissions: i'm not entirely sure how this works yet. but it should contain mode and gid in some format set_input_callback(handle, callback, context) set_output_callback(handle, callback, context) - call the callback when more data can be read/written ret = pread(handle, buf, size, offset) - just like pread(), but can fail with EAGAIN if there are no bytes already buffered. so the idea is that the backend implementation would buffer/readahead data, which would be returned by this call. this would require memcpy()ing all data, but it might get too complex/fragile if it was asynchronously written to given buffer. ret = write(handle, buf, size) - append data to given file and return how many bytes were actually added to write buffer. works in a similar way than writing to socket. data can only be appended to files, there is no support for overwriting data. - no writes will be visible to reads until commit() is called ret = commit(handle, [filename]) - commit all previous writes to disk. either returns success/EAGAIN. - if filename is given and a new file is being created, the filename is changed to the given one instead of using the original path's filename. this is needed because e.g. mdbox saving can write many temp files in a single transaction and only at commit stage it locks the index files and knows what the filenames will be. rollback(handle) - rollback all previous writes. close(handle) - if file was created and not committed, the temp file will be deleted - does implicit rollback ret = try_lock(handle) - this isn't an asynchronous operation! it assumes that locking state is kept in memory, so that the operation will be fast. if backend doesn't support locking or it's slow, single-dbox should be used (instead of multi-dbox), because it doesn't need locking. - returns success or "already locked" - only exclusive locking is possible Async IO streams ================ Async input streams are created with FS API handle, so it's possible to start reading from them before the file has even been open()ed. The callers must be aware of this and realize that read() can fail with ENOENT, etc. Async input streams' read() would work exactly as file_istream works for non-blocking sockets: It would return data that is already buffered in memory. If there's nothing, it returns EAGAIN. The FS API's set_input_callback() can be used to set a callback function that is called whenever there's more data available in the buffer. Async output streams also work the same as non-blocking file_ostreams: write() returns the number of bytes added to buffer. When buffer becomes full, it starts returning EAGAIN. The ostream handles flushing internally the same way as file_ostreams does, although instead of using io_add(IO_WRITE) it uses FS API's set_output_callback(). If callers need to know when more data can be written or when all of the data has been written, it can override the ostream's flush_callback, just like with file_ostreams. Async IO for FS API backend =========================== So now that all of the APIs have been designed, all that's needed to do is to write a simple FS API implementation using kernel's async IO API, right? Wrong. There is no usable async IO API in Linux, and probably nowhere else either: * POSIX AIO isn't supported by Linux kernel. And even if it was, it only supports async reads/writes, not async open(). * Linux kernel has its own native AIO implementation! ..But it only works with direct IO, which makes it pretty much useless for almost everyone. There have been many different attempts to get buffered AIO support to Linux, but all of them have failed. So for now the only practical way is to implement it with threads. There are several libraries that could make this easier.. But all of them enable (and require) full thread safety for libc calls. I don't really like that. Dovecot isn't using threads, I shouldn't pay the penalty of using extra locking when it's really not necessary. So I was thinking about doing the async IO in two ways: 1) For Linux/x86/x86-64 (and maybe others) implement a version that creates threads with clone() and uses lockless queues for communicating between the async io worker threads. The threads won't use malloc() or any other unsafe calls, so this should be pretty nice. 2) Fallback version that uses pthreads with mutexes. Is 2) going to be noticeably slower than 1)? Probably not.. In both cases there is also the problem of how many worker threads to create. I've really no idea, kernel would be so much better in deciding that.. I guess that also depends on how many processes Dovecot is configured to run on (and how busy they are at the moment). Maybe it could be just a globally configurable number of threads/process, defaulting to something like 10. dbox changes ============ Most of the dbox code shouldn't be too difficult to change to using the FS API. The one exception is writing messages. Currently the format looks like: <dbox header magic (2 bytes)> <dbox message header, which contains message size><lf> <message> <dbox metadata magic (2 bytes)><lf> <dbox metadata> <lf> The problem is that the message size isn't always known before the message is written. So currently the code just pwrite()s the size afterwards, but this is no longer possible with the new FS API. One possibility would be to buffer the message in memory, but that could waste a lot of memory since messages can be large. So the only good solution is to change the dbox file format to contain the message size after the message. At the same time the dbox format could be cleaned up from old broken ideas as well. The reading code could support the old version format as well, because reading isn't a problem. The new dbox format could look like: <dbox header magic (2 bytes)> <dbox unique separator (random 16 bytes or so)><lf> <message> <dbox metadata magic (2 bytes)> <dbox unique separator, same as above><message size><lf> <dbox metadata, last item being metadata size> <lf> The unique separator exists there primarily for fixing corrupted dbox storage, so it can (quite) reliably recognize where a message ends. Multi-dbox's indexes contain already the message offset + size of (message+metadata), i.e. offset+size = offset of next message. The size is primarily used to figure out if more data can be appended to the file (so it won't grow too large). This size could just be changed to become message's size and the check just changed to assume metadata size would be e.g. 512 bytes. It won't really matter in practise. So then the reading code could get the message's size from the index. Single-dbox doesn't have such index. There are two ways to solve the problem there (both actually would work for multi-dbox too): 1) Metadata block can be found by reading backwards from end of file. For example read the last 512 bytes of the file and find the metadata magic block. Get the message's size from there. 2) Create an istream that simply reads until it reaches dbox metadata magic and unique separator. And to be absolutely sure it reached the correct end of message, it can also check that the rest of the data in the stream contains only a valid metadata block.

8 28

[Dovecot] how configure quotas with dovecot and mysql databases
by Wilberth Pérez 17 Mar '10

17 Mar '10

some one knows, how to configure quotas with dovecot and mysql databases ? my dovecot was compiled with: CPPFLAGS=-I/opt/mysql/include/mysql LDFLAGS=-L/opt/mysql/lib/mysql ./ configure --with-sql --with-mysql and my dovecot.conf and dovecot-sql.conf have the following configurations: =========== dovecot.conf =========== protocol imap { listen = *:143 mail_plugins = quota imap_quota } protocol pop3 { listen = *:110 mail_plugins = quota } plugin { quota = maildir:storage=30M quota_rule = *:storage=30M quota_warning = storage=95%% /usr/local/bin/quota-warning.sh 95 quota_warning2 = storage=80%% /usr/local/bin/quota-warning.sh 80 } ============ dovecot-sql.conf ============ driver = mysql connect = host=localhost dbname=mail user=mail password=mail user_query = SELECT 1 AS gid, concat('maildir:storage= ', quota_kb) AS quota FROM users WHERE user = 'testuser'; I test my configuration and don't show errors , however, dovecot never show me my quota configuration. I will be omitting something ? Cheers. -- -------------------------------------------------------- LCC Wilberth de Jesús Pérez Segura CCSA- Administración de Servicios y Seguridad de las TI Correo: wilberth.perez(a)uady.mx Universidad Autónoma de Yucatán Secretaría General Coordinación Administrativa de Tecnologías de Información RIUADY C-59 x Av. Itzáes (999)923-74-28 Ext. 1117 Mérida, Yucatán, México 2010 --------------------------------------------------------

1 0

[Dovecot] Dovecot 2.0beta3: Crash with mail_log plugin enabled
by Thomas Leuxner 17 Mar '10

17 Mar '10

Latest from Mercurial. Dovecot crashes with 'mail_log' and 'notify' plugins enabled when deleting a message: [08:22] root spectre:~# gdb /usr/lib/dovecot/imap /tmp/core GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib/dovecot/libdovecot-storage.so.0...Reading symbols from /usr/lib/debug/usr/lib/dovecot/libdovecot-storage.so.0.0.0...done. done. Loaded symbols for /usr/lib/dovecot/libdovecot-storage.so.0 Reading symbols from /usr/lib/dovecot/libdovecot.so.0...Reading symbols from /usr/lib/debug/usr/lib/dovecot/libdovecot.so.0.0.0...done. done. Loaded symbols for /usr/lib/dovecot/libdovecot.so.0 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /usr/lib/dovecot/modules/lib01_acl_plugin.so...Reading symbols from /usr/lib/debug/usr/lib/dovecot/modules/lib01_acl_plugin.so...done. done. Loaded symbols for /usr/lib/dovecot/modules/lib01_acl_plugin.so Reading symbols from /usr/lib/dovecot/modules/lib02_imap_acl_plugin.so...Reading symbols from /usr/lib/debug/usr/lib/dovecot/modules/lib02_imap_acl_plugin.so...done. done. Loaded symbols for /usr/lib/dovecot/modules/lib02_imap_acl_plugin.so Reading symbols from /usr/lib/dovecot/modules/lib10_quota_plugin.so...Reading symbols from /usr/lib/debug/usr/lib/dovecot/modules/lib10_quota_plugin.so...done. done. Loaded symbols for /usr/lib/dovecot/modules/lib10_quota_plugin.so Reading symbols from /usr/lib/dovecot/modules/lib11_imap_quota_plugin.so...Reading symbols from /usr/lib/debug/usr/lib/dovecot/modules/lib11_imap_quota_plugin.so...done. done. Loaded symbols for /usr/lib/dovecot/modules/lib11_imap_quota_plugin.so Reading symbols from /usr/lib/dovecot/modules/lib15_notify_plugin.so...Reading symbols from /usr/lib/debug/usr/lib/dovecot/modules/lib15_notify_plugin.so...done. done. Loaded symbols for /usr/lib/dovecot/modules/lib15_notify_plugin.so Reading symbols from /usr/lib/dovecot/modules/lib20_mail_log_plugin.so...Reading symbols from /usr/lib/debug/usr/lib/dovecot/modules/lib20_mail_log_plugin.so...done. done. Loaded symbols for /usr/lib/dovecot/modules/lib20_mail_log_plugin.so Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Core was generated by `dovecot/imap'. Program terminated with signal 6, Aborted. [New process 2151] #0 0x00007f5c79480ed5 in raise () from /lib/libc.so.6 #0 0x00007f5c79480ed5 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x00007f5c794823f3 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x00007f5c79be62c5 in default_fatal_finish (type=<value optimized out>, status=0) at failures.c:164 backtrace = 0x61f660 "/usr/lib/dovecot/libdovecot.so.0 [0x7f5c79be62b2] -> /usr/lib/dovecot/libdovecot.so.0 [0x7f5c79be631a] -> /usr/lib/dovecot/libdovecot.so.0(i_error+0) [0x7f5c79be66c3] -> /usr/lib/dovecot/libdovecot-st"... #3 0x00007f5c79be631a in i_internal_fatal_handler (type=LOG_TYPE_PANIC, status=0, fmt=<value optimized out>, args=<value optimized out>) at failures.c:592 No locals. #4 0x00007f5c79be66c3 in i_panic (format=<value optimized out>) at failures.c:230 args = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fffffffd370, reg_save_area = 0x7fffffffd2b0}} #5 0x00007f5c79e72748 in view_lookup_uid (view=0x6614c0, seq=0, uid_r=0x7fffffffd39c) at mail-index-view.c:210 __PRETTY_FUNCTION__ = "view_lookup_uid" #6 0x00007f5c79e589c6 in mail_cache_decision_state_update (view=0x661800, seq=2151, field=12) at mail-cache-decisions.c:82 cache = (struct mail_cache *) 0x65e790 hdr = <value optimized out> uid = <value optimized out> __PRETTY_FUNCTION__ = "mail_cache_decision_state_update" #7 0x00007f5c79e5a4b0 in mail_cache_lookup_headers (view=0x661800, dest=0x67be28, seq=0, field_idxs=0x7fffffffd56c, fields_count=1) at mail-cache-lookup.c:484 _data_stack_cur_id = 5 ret = <value optimized out> #8 0x00007f5c79e88d22 in index_mail_get_raw_headers (mail=0x67b618, field=0x7f5c78608dc7 "Message-ID", value_r=0x7fffffffd5c8) at index-mail-headers.c:614 headers = {0x67b618 "\230?e", 0x7f5c79bfda98 "H\201??"} value = <value optimized out> headers_ctx = <value optimized out> data = <value optimized out> field_idx = 12 dest = (string_t *) 0x67be28 i = <value optimized out> len = <value optimized out> ret = <value optimized out> header_values = {arr = {buffer = 0x661ec8, element_size = 6692576}, v = 0x661ec8, v_modifiable = 0x661ec8} __PRETTY_FUNCTION__ = "index_mail_get_raw_headers" #9 0x00007f5c79e892bf in index_mail_get_first_header (_mail=0x67b618, field=0x7f5c78608dc7 "Message-ID", decode_to_utf8=false, value_r=0x7fffffffd620) at index-mail-headers.c:771 list = (const char * const *) 0x80 ret = 8 i = 0 #10 0x00007f5c786085cc in mail_log_append_mail_header (str=0x61f4d8, mail=0x867, name=0x7f5c78608dd2 "msgid", header=0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>) at mail-log-plugin.c:174 value = 0x8 <Address 0x8 out of bounds> #11 0x00007f5c786087be in mail_log_append_mail_message (ctx=0x661ec8, mail=0x67b618, event=MAIL_LOG_EVENT_SAVE, desc=0x61f4b0 "copy from INBOX") at mail-log-plugin.c:219 _data_stack_cur_id = 4 #12 0x00007f5c7880ba57 in notify_contexts_mail_copy (src=0x6636f8, dst=0x67b618) at notify-plugin.c:69 ctx = (struct notify_context *) 0x642310 mail_txn = (struct notify_mail_txn *) 0x0 #13 0x00007f5c7880c1e3 in notify_copy (ctx=0x667ed0, mail=0x6636f8) at notify-storage.c:113 ret = <value optimized out> #14 0x00007f5c79e4e29a in mailbox_copy (_ctx=0x7fffffffd7a0, mail=0x6636f8) at mail-storage.c:1330 ctx = (struct mail_save_context *) 0x667ed0 box = (struct mailbox *) 0x65cc98 keywords = (struct mail_keywords *) 0x67b300 ret = <value optimized out> #15 0x0000000000409631 in cmd_copy (cmd=0x650f38) at cmd-copy.c:66 client = (struct client *) 0x6507d8 dest_ns = <value optimized out> dest_storage = <value optimized out> destbox = (struct mailbox *) 0x65cc98 t = (struct mailbox_transaction_context *) 0x661080 search_args = (struct mail_search_args *) 0x65bc88 messageset = 0x652888 "4891" mailbox = 0x652890 "Trash" src_uidset = <value optimized out> sync_flags = <value optimized out> imap_flags = <value optimized out> changes = {pool = 0x0, uid_validity = 9, saved_uids = {arr = {buffer = 0x7f5c795563a0, element_size = 0}, v = 0x7f5c795563a0, v_modifiable = 0x7f5c795563a0}, ignored_uid_changes = 6418664, ignored_modseq_changes = 0} copy_count = 1 msg = <value optimized out> ret = 1 __PRETTY_FUNCTION__ = "cmd_copy" #16 0x000000000040f9dc in client_command_input (cmd=0x650f38) at imap-client.c:647 client = (struct client *) 0x6507d8 command = <value optimized out> __PRETTY_FUNCTION__ = "client_command_input" #17 0x000000000040fa8d in client_command_input (cmd=0x650f38) at imap-client.c:697 client = (struct client *) 0x6507d8 command = (struct command *) 0x6 __PRETTY_FUNCTION__ = "client_command_input" #18 0x000000000040fc05 in client_handle_input (client=0x6507d8) at imap-client.c:738 _data_stack_cur_id = 3 ret = 25 remove_io = <value optimized out> handled_commands = false __PRETTY_FUNCTION__ = "client_handle_input" #19 0x0000000000410642 in client_input (client=0x6507d8) at imap-client.c:789 cmd = <value optimized out> output = (struct ostream *) 0x650db8 bytes = <value optimized out> __PRETTY_FUNCTION__ = "client_input" #20 0x00007f5c79bf0feb in io_loop_handler_run (ioloop=<value optimized out>) at ioloop-epoll.c:208 ctx = (struct ioloop_handler_context *) 0x6277d0 event = (const struct epoll_event *) 0x627840 list = (struct io_list *) 0x650e90 io = (struct io_file *) 0x65b820 tv = {tv_sec = 1799, tv_usec = 999883} t_id = 2 msecs = <value optimized out> ret = 1 call = <value optimized out> #21 0x00007f5c79bf0168 in io_loop_run (ioloop=0x6275c0) at ioloop.c:350 No locals. #22 0x00007f5c79be0143 in master_service_run (service=0x627490, callback=0x867) at master-service.c:478 No locals. #23 0x0000000000418681 in main (argc=1, argv=0x627370) at main.c:313 service_flags = <value optimized out> storage_service_flags = <value optimized out> postlogin_socket_path = 0x0 set_roots = {0x41b980, 0x0}

3 10

[Dovecot] Dovecot 2.0beta3: Auth master process is now running as default_internal_user
by Thomas Leuxner 16 Mar '10

16 Mar '10

Hi, with 'changeset 10910' the Auth master process is running as 'default_internal_user' now (dovecot). This requires permissions tuning for 'passwd-files' at least, while other plugins would run in a different user context, 'vmail' in my setup. I see that this may be safer, just wondering how to streamline the config: [20:27] root spectre:/var/vmail/conf.d# l drwxr-x--- 4 dovecot vmail 4096 2010-03-14 17:40 leuxner.net [20:27] root spectre:/var/vmail/conf.d# l leuxner.net/ drwx------ 2 vmail vmail 4096 2010-03-14 13:09 acls -r-------- 1 dovecot vmail 125 2010-02-07 13:08 passwd drwx------ 2 vmail vmail 4096 2010-03-14 12:13 sieve [20:27] root spectre:/var/vmail/conf.d# cat leuxner.net/passwd tlx@leuxner.net:{SSHA}xxxx:5000:5000::/var/vmail/leuxner.net/tlx::userdb_quota_rule=*:storage=5G […] Regards Thomas

2 3

[Dovecot] ACL problem
by SZÉKELYI Szabolcs 16 Mar '10

16 Mar '10

Hey, I seem to have a problem with ACLs. I'm trying to use them on shared folders those work fine without it. But as soon as I enable the plugin and create the dovecot-acl files, they disappear. I used strace to see if there's a problem with file permissions, but it looks like Dovecot doesn't even attempt to access the dovecot-acl file in the maildir, only the dovecot-acl-list files. However, it does look for dovecot-acl files in users' home directories. Maybe the ACL plugin is enabled only for the private mailboxes, not for the public ones, but I want right the opposite. How can I achieve it? Please find my dovecot config below. Thanks, -- cc # 1.2.4: /etc/dovecot/dovecot.conf # OS: Linux 2.6.26-2-686 i686 Debian 5.0.4 log_timestamp: %Y-%m-%d %H:%M:%S protocols: imaps ssl: required ssl_cert_file: /etc/ssl/certs/imapd.pem ssl_key_file: /etc/ssl/private/imapd.key.pem login_dir: /var/run/dovecot/login login_executable: /usr/lib/dovecot/imap-login mail_privileged_group: mail mbox_write_locks: fcntl dotlock mail_plugins: acl namespace: type: private location: mbox:%h:INBOX=/var/mail/%u inbox: yes list: yes subscriptions: yes namespace: type: public separator: / prefix: Logs/ location: maildir:/data/mail/logs:LAYOUT=fs:INDEX=~/.imap- public/Logs:CONTROL=~/.imap-public/Logs list: yes auth default: passdb: driver: pam userdb: driver: passwd plugin: acl: vfile

2 3

[Dovecot] Dovecot 2.0beta3 LMTP hanging when delivering into a non-existing mailbox
by Bernhard Schmidt 16 Mar '10

16 Mar '10

Hi, another LMTP problem. When a sieve userscript tries to fileinto a nonexisting mailbox the LMTP process hangs. Mar 12 12:55:28 mail dovecot: lmtp(1328, berni(a)vmail.mail.mucip.net) kPpuOKArmkswBQAA/GZUZg: sieve: msgid=<201003111751.o2BHpTbX069309(a)squid-cache.org>: failed to store into mailbox 'squidbugs': Mailbox doesn't exist: squidbugs after that I cannot get a LMTP connection anymore (TCP connect works, but I don't see a server banner) until I send SIGKILL to the running lmtp process. SIGTERM is not enough. strace looks like this: gettimeofday({1268394998, 961094}, NULL) = 0 stat("/var/cache/dovecot/b/berni/.squidbugs", 0x7fff202e5040) = -1 ENOENT (No such file or directory) stat("/var/mail/vmail/b/berni/.squidbugs", 0x7fff202e5000) = -1 ENOENT (No such file or directory) stat("/var/mail/vmail/b/berni", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 stat("/var/mail/vmail/b/berni/.squidbugs", 0x7fff202e5000) = -1 ENOENT (No such file or directory) stat("/var/mail/vmail/b/berni", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 stat("/var/mail/vmail/b/berni/.squidbugs/tmp", 0x7fff202e5070) = -1 ENOENT (No such file or directory) stat("/var/mail/vmail/b/berni/.squidbugs", 0x7fff202e5120) = -1 ENOENT (No such file or directory) write(2, "\1\0041337 llrFJeUrmks5BQAA/GZUZg: s"..., 166) = 166 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({86400, 0}, I'm on 10869:bf978f2de0fd. Bernhard

2 2

[Dovecot] segfault with vpopmail 5.5.0
by Giuseppe Iuculano 16 Mar '10

16 Mar '10

Hi, version: 1.2.10 OS: Debian unstable/x86_64 [118905.528497] dovecot-auth[3856]: segfault at 0 ip (null) sp 00007fff6666ad98 error 14 in dovecot-auth[400000+61000] 2010-02-26 22:17:45 dovecot: Error: child 3856 (auth) killed with signal 11 (core dumped) (gdb) bt full #0 0x0000000000000000 in ?? () No symbol table info available. #1 0x0000000000423b0e in vpopmail_lookup_vqp (request=0x726f68, vpop_user=0x7fff6666ae20 "postmaster", vpop_domain=0x7fff6666adc0 "test.bogus") at userdb-vpopmail.c:43 vpw = <value optimized out> #2 0x0000000000421376 in vpopmail_password_lookup (auth_request=0x7fff6666ae20, cleartext=false, result_r=0x7fff6666aebc) at passdb-vpopmail.c:65 vpop_user = "postmaster", '\000' <repeats 70 times> vpop_domain = "test.bogus", '\000' <repeats 70 times> vpw = <value optimized out> password = <value optimized out> #3 0x00000000004215ad in vpopmail_verify_plain (request=0x7fff6666ae20, password=0x704360 "test", callback=0x415500 <auth_request_verify_plain_callback>) at passdb-vpopmail.c:119 result = <value optimized out> scheme = <value optimized out> tmp_pass = <value optimized out> crypted_pass = <value optimized out> ret = <value optimized out> #4 0x0000000000415391 in auth_request_verify_plain (request=0x726f68, password=0x704360 "test", callback=0x41eb90 <plain_verify_callback>) at auth-request.c:509 passdb = 0x70ca40 result = <value optimized out> cache_key = <value optimized out> __PRETTY_FUNCTION__ = "auth_request_verify_plain" #5 0x000000000041a6f7 in mech_plain_auth_continue (request=0x726f68, data=<value optimized out>, data_size=<value optimized out>) at mech-plain.c:58 authid = 0x704340 "" authenid = 0x704341 "postmaster(a)test.bogus" error = <value optimized out> pass = 0x704360 "test" count = 2 #6 0x0000000000415d41 in auth_request_handler_auth_begin (handler=0x7192f8, args=<value optimized out>) at auth-request-handler.c:388 mech = <value optimized out> request = 0x726f68 list = 0x24 name = 0x704308 "@Cp" arg = 0x704195 "AHBvc3RtYXN0ZXJAdGVzdC5ib2d1cwB0ZXN0" initial_resp = 0x704195 "AHBvc3RtYXN0ZXJAdGVzdC5ib2d1cwB0ZXN0" initial_resp_len = 2 id = <value optimized out> buf = 0x704308 #7 0x0000000000411549 in auth_client_handle_line (conn=0x717f70) at auth-client-connection.c:174 No locals. #8 auth_client_input (conn=0x717f70) at auth-client-connection.c:250 _data_stack_cur_id = 3 line = 0x7182b6 "AUTH\t1\tPLAIN\tservice=pop3\tlip=XXX.XXX.XXX.XXXcensored\trip=XXX.XXX.XXX.XXXcensored\tlport=110\trport=41899\tresp=AHBvc3RtYXN0ZXJAdGVzdC5ib2d1cwB0ZXN0" ret = <value optimized out> #9 0x000000000043643d in io_loop_handler_run (ioloop=<value optimized out>) at ioloop-epoll.c:208 ctx = 0x70f3e0 event = 0x70f450 list = 0x718280 io = 0x718240 ---Type <return> to continue, or q <return> to quit--- tv = {tv_sec = 4, tv_usec = 999573} t_id = 2 msecs = <value optimized out> ret = 1 i = 0 call = <value optimized out> #10 0x00000000004358b8 in io_loop_run (ioloop=0x70c380) at ioloop.c:335 No locals. #11 0x0000000000419efe in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:347 foreground = false Cheers, Giuseppe

2 4

[Dovecot] Authentication userdb file / configuration help - newbie question...
by Zilon X 16 Mar '10

16 Mar '10

Hi All, I need to configure Dovecot with a XMail server ( www.xmailserver.org ) - this server uses a userdb file with the following format: "domain"[TAB]"account"[TAB]"encrypted-passwd"[TAB]"account-id"[TAB]"account-dir"[TAB]"account-type"[NEWLINE] How can authenticate Dovecot against this userdb file? Was anyone doing that? Maybe, can I authenticate Dovecot using SMTP Auth? Thank you for any help!

2 1

[Dovecot] Dovecot 2.0b3: mdbox with incorrect ACL file permissions crashes
by Thomas Leuxner 16 Mar '10

16 Mar '10

Hi, played around with 'mdbox' format some more. Converted my personal mailbox with latest Dovecot and dsync from HG: dsync convert -u login(a)yourdomain.com mdbox:~/mdbox One thing I noticed is, that dsync does not take care of existing 'dovecot-acl' files, which it should migrate/copy from my point of view, but simply skips them. Anyway I copied over the ACLs manually and forgot to set the rights accordingly. So the files were owned by 'root:vmail' instead of 'vmail:vmail' in my setup. Voilà Dovecot crashed, where it should really throw a warning or ignore the owner and work with the group permissions: Mar 2 19:27:52 spectre dovecot: imap(tlx(a)leuxner.net): acl vfile: file /var/vmail/conf.d/leuxner.net/acls/Support/Serverloft not found Mar 2 19:27:52 spectre dovecot: imap(tlx(a)leuxner.net): acl vfile: no access to file /var/vmail/leuxner.net/tlx/mdbox/mailboxes/Support/Serverloft/dbox-Mails/dovecot-acl Mar 2 19:27:52 spectre dovecot: imap(tlx(a)leuxner.net): Panic: file acl-cache.c: line 295 (acl_cache_update_rights): assertion failed: (obj_cache->my_current_rights != &negative_cache_entry) Mar 2 19:27:52 spectre dovecot: imap(tlx(a)leuxner.net): Raw backtrace: /usr/lib/dovecot/libdovecot.so.0 [0x7f4d8595ffb2] -> /usr/lib/dovecot/libdovecot.so.0 [0x7f4d8596001a] -> /usr/lib/dovecot/libdovecot.so.0 (i_error+0) [0x7f4d859603c3] -> /usr/lib/dovecot/modules/lib01_acl_plugin.so [0x7f4d84da690b] -> /usr/lib/dovecot/modules/lib01_acl_plugin.so [0x7f4d84da4249] -> /usr/lib/dovecot/modules/lib01_acl_plugin.so [0 x7f4d84da4572] -> /usr/lib/dovecot/modules/lib01_acl_plugin.so [0x7f4d84da472e] -> /usr/lib/dovecot/modules/lib01_acl_plugin.so [0x7f4d84da2aba] -> /usr/lib/dovecot/modules/lib01_acl_plugin.so(acl_object_get_m y_rights+0x65) [0x7f4d84da2b85] -> /usr/lib/dovecot/modules/lib01_acl_plugin.so [0x7f4d84da8fd9] -> dovecot/imap [tlx(a)leuxner.net 84.58.106.99 STATUS](client_find_namespace+0x17f) [0x41149f] -> dovecot/imap [t lx(a)leuxner.net 84.58.106.99 STATUS](cmd_status+0xfc) [0x40dc2c] -> dovecot/imap [tlx(a)leuxner.net 84.58.106.99 STATUS] [0x40f9bc] -> dovecot/imap [tlx(a)leuxner.net 84.58.106.99 STATUS] [0x40fa6d] -> dovecot/imap [tlx(a)leuxner.net 84.58.106.99 STATUS](client_handle_input+0x45) [0x40fbe5] -> dovecot/imap [tlx(a)leuxner.net 84.58.106.99 STATUS](client_input+0x62) [0x410622] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handl er_run+0xcb) [0x7f4d8596abab] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x18) [0x7f4d85969d28] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f4d85959eb3] -> dovecot/imap [tlx(a)leuxner.n et 84.58.106.99 STATUS](main+0x191) [0x418661] -> /lib/libc.so.6(__libc_start_main+0xe6) [0x7f4d851e71a6] -> dovecot/imap [tlx(a)leuxner.net 84.58.106.99 STATUS] [0x4084e9] Mar 2 19:27:52 spectre dovecot: master: service(imap): child 30281 killed with signal 6 (core dumps disabled) Regards Thomas

2 1