- dovecot - dovecot.org

[Dovecot] use of deliver from procmail advisable?
by martin f krafft 15 Aug '07

15 Aug '07

Hi list, I understand that dovecot's deliver does a little more than deliver: it also updates the dovecot metadata stored with each Maildir. Thus, if I use deliver as opposed to procmail's internal Maildir delivery, it seems that the IMAP server later has less work to do since the metadata is can use are up to date. Doing this, however, incurs an extra process for each mail delivered. I thus wonder whether the two balance each other out, or whether there is a strong difference. What do you think will be less resource-heavy: calling deliver for every mail received *in addition to* procmail, or letting the IMAP server update the metadata on access? -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER spamtraps: madduck.bogus(a)madduck.net

4 8

[Dovecot] namespaces and creation of folders that contain folders...
by bhayden＠umn.edu 14 Aug '07

14 Aug '07

Hi Timo and all. imap/cmd-create.c contains the following bit of code: len = strlen(full_mailbox); if (len == 0 || full_mailbox[len-1] != ns->sep) directory = FALSE; else { /* name ends with hierarchy separator - client is just informing us that it wants to create children under this mailbox. */ directory = TRUE; mailbox = t_strndup(mailbox, len-1); full_mailbox = t_strndup(full_mailbox, strlen(full_mailbox)-1); i_info("Z CREATE NAME: YYY%sYYY", mailbox); } We've been having trouble with people not being able to create a mail folder that will contain other folders. Tried it both with users using mbox (where this would be a filesystem directory) and maildir. Failed everytime because of a test which rejects folder names that end with MAILDIR_FS_SEP. Looks like the above bit of code is supposed to catch these, make a note of the fact that the client wants a directory, and strip off that trailing separator. In fact, it does this in the case of 'full_mailbox'. However, for 'mailbox' (it seems to me) the code is incorrect as its using the len-1 which is the length of 'full_mailbox', not 'mailbox'. This means that when 'mailbox' and 'full_mailbox' are the same length--that is, for the default namespace (no prefix), it happens to work. However, in any other namespace, it won't, as 'full_mailbox' will always be longer then 'mailbox' if there is a ns prefix, and hence that trailing separator won't be trimmed. (As a matter of fact, in the unlikely instance that the prefix is a single character this will trim the null character from 'mailbox', which probably isn't a good thing.) So. Am I missing something, or crazy, or is this really a bug? Thanks, -Brian

2 2

[Dovecot] about index cache
by Joe Wong 14 Aug '07

14 Aug '07

Hi Timo, Is the dovecot index cache stored only standard header fields (from, to, cc, subject, content-type... )? What happen if there is non standard header, will it be cached? - Joe May the force be with you..

3 9

[Dovecot] Failed to compile dovecot 1.1 nightly build
by wenjie zheng 14 Aug '07

14 Aug '07

I downloaded the 1.1 night build from here: http://hg.dovecot.org/dovecot/archive/tip.tar.gz autogen.sh ./configure (with a long list of options) make I got this error information: ... rpcgen -c /usr/include/rpcsvc/rquota.x | \ -e 's/IXDR_PUT/(void)IXDR_PUT/g' \ -e 's/int32_t \*buf/int32_t *buf __attr_unused__/' > rquota_xdr.c /bin/sh: line 1: -e: command not found make[4]: *** [rquota_xdr.c] Error 127 make[4]: Leaving directory `/var/home/wzheng/code/vendor/src/plugins/quota' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/home/wzheng/code/vendor/src/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/home/wzheng/code/vendor/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/home/wzheng/code/vendor' make: *** [all] Error 2 Am I using the correct nightly build? Thanks, Wenjie

2 1

Re: [Dovecot] dovecot Digest, Vol 52, Issue 52
by Jerry Yeager 14 Aug '07

14 Aug '07

From the digest: On Aug 14, 2007, at 1:04 PM, dovecot-request(a)dovecot.org wrote: other messages cut out… > > > Message: 9 > Date: Tue, 14 Aug 2007 19:03:58 +0200 > From: martin f krafft <madduck(a)madduck.net> > Subject: Re: [Dovecot] use of deliver from procmail advisable? > To: dovecot(a)dovecot.org > Message-ID: <20070814170358.GA17390(a)piper.oerlikon.madduck.net> > Content-Type: text/plain; charset="us-ascii" > > also sprach Kyle Wheeler <kyle-dovecot(a)memoryhole.net> > [2007.08.14.1833 +0200]: >>> I understand that dovecot's deliver does a little more than >>> deliver: >> >> It also understands the 'seive' filter language (an alternative to >> procmail). > > I don't consider it an alternative to procmail because you cannot > pass mail to external programmes, like spamassassin or vacation. > Sure, sieve has its own vacation module, but I find that to be > rather limited. See this thread: > > http://dovecot.org/list/dovecot/2007-August/024686.html > >>> What do you think will be less resource-heavy: calling deliver >>> for every mail received *in addition to* procmail, or letting the >>> IMAP server update the metadata on access? >> >> Unless you're cutting it close to the limit on what your server >> can handle, that's probably the wrong question to ask. A better >> question is: which gives my users better performance? > > Good point. The users, however, as far as I know, all use tools like > offlineimap to synchronise in the background, so it hardly matters. > >> your users aren't paying attention. Dovecot will *seem* snappier >> if you do the indexing work on delivery rather than on access, >> even though it may spend more CPU cycles overall to do so. > > Does anyone have hard facts on how much the server process loses if > it encounters a folder with an index inconsistency? > > -- > martin; (greetings from the heart of the sun.) > \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck > > mulutlitithtrhreeaadededd s siigngnatatuurere > > spamtraps: madduck.bogus(a)madduck.net >

1 0

[Dovecot] status of APPENDUID: returning a UID in response to APPEND
by martin f krafft 14 Aug '07

14 Aug '07

# dovecot-related content below, this one for debian bug tracking # system: retitle 435959 Please support RFC4315 UIDPLUS extension in APPEND reply severity 435959 wishlist thanks [please keep 435959(a)bugs.debian.org on Cc.] Hi there, I am working on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435959, which is a performance problem that offlineimap has on large mailboxes. We think that a simple patch to dovecot could cure this problem. I am willing to write the patch but would really like to get your opinion first. In order to keep track of which IMAP message is stored in which local file, offlineimap uses the message UID, which is guaranteed to be unique in the directory, but constant across sessions. When uploading a new message to the IMAP server with APPEND, offlineimap then has to run a SEARCH to obtain said UID for the message it just uploaded. This takes ages on larger mailboxes, as the way offlineimap identifies the message is via a header that's not indexed by dovecot. The solution I found in RFC4315 ("UIDPLUS"; http://www1.tools.ietf.org/html/rfc4315) and then I saw http://www.dovecot.org/list/dovecot/2004-July/003993.html, and now I am wondering: is anyone else interested in APPENDUID? What's the status of an implementation, if any? Newer Courier IMAP server implementation support UIDPLUS and offlineimap will likely obtain this functionality soon. Cheers, [please keep 435959(a)bugs.debian.org on Cc.] -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck "by accepting this brick through your window, you accept it as is and agree to my disclaimer of all warranties, express or implied, as well as disclaimers of all liability, direct, indirect, consequential or incidental, that may arise from the installation of this brick into your building." -- seen on irc spamtraps: madduck.bogus(a)madduck.net

4 3

[Dovecot] dovecot-1.1 + dovecot-sieve-1.1 deliver backtraces
by Sergey 14 Aug '07

14 Aug '07

Hi, I am trying dovecot-1.1 with dovecot-sieve-1.1. First, dovecot -n do not report about deliver settings. They are: --- protocol lda { postmaster_address = postmaster(a)parkheights.dyndns.org hostname = parkheights.dyndns.org mail_plugins = cmusieve mail_plugin_dir = /usr/lib64/dovecot11/modules/lda sendmail_path = /usr/lib/sendmail auth_socket_path = /var/run/dovecot11/auth-master } --- Then, $ sudo /usr/sbin/dovecot11 -n # 1.1.alpha1: /etc/dovecot11/dovecot11.conf base_dir: /var/run/dovecot11/ log_path: /tmp/dovecot11.log info_log_path: /tmp/dovecot11.debug protocols: imap imaps pop3 pop3s listen(default): *:143 listen(imap): *:143 listen(pop3): *:110 ssl_listen(default): *:993 ssl_listen(imap): *:993 ssl_listen(pop3): *:995 ssl_cert_file: /etc/ssl/parkheights.cert ssl_key_file: /etc/ssl/parkheights.key login_dir: /var/run/dovecot11/login login_executable(default): /usr/lib64/dovecot11/imap-login login_executable(imap): /usr/lib64/dovecot11/imap-login login_executable(pop3): /usr/lib64/dovecot11/pop3-login mail_extra_groups: mail mail_location: maildir:/var/spool/imap/%n/.imap mail_debug: yes mail_executable(default): /usr/lib64/dovecot11/imap mail_executable(imap): /usr/lib64/dovecot11/imap mail_executable(pop3): /usr/lib64/dovecot11/pop3 mail_plugin_dir(default): /usr/lib64/dovecot11/modules/imap mail_plugin_dir(imap): /usr/lib64/dovecot11/modules/imap mail_plugin_dir(pop3): /usr/lib64/dovecot11/modules/pop3 auth default: debug: yes debug_passwords: yes passdb: driver: passwd-file args: /etc/dovecot/dovecot.passwd userdb: driver: static args: uid=1927 gid=1927 home=/var/spool/imap/%n userdb: driver: passwd-file args: /etc/dovecot/dovecot.passwd socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot11/auth-master mode: 384 user: vmail group: vmail --- Couple of backtraces from /tmp/dovecot11.log are here. I will try to attach them as a textfile to this message, so that lines will not be wrapped, but I'm not sure that attachements are not stripped. So, please excuse me for duplication in this case. --- dovecot: Jul 25 01:05:19 Error: IMAP(seriv): Corrupted index cache file /var/spool/imap/seriv/.imap/.community-lists-altlinux-org/dovecot.index.cache: Corrupted cach ed message_part data (physical_pos less than expected) deliver(seriv): Jul 25 04:17:26 Panic: seq = 1587, rec->uid = 0, first_new_seq = 1587, records = 1586 deliver(seriv): Jul 25 04:17:26 Error: Raw backtrace: /usr/lib64/dovecot11/deliver [0x46e045] -> /usr/lib64/dovecot11/deliver [0x46dd2c] -> /usr/lib64/dovecot11/deli ver [0x44de1e] -> /usr/lib64/dovecot11/deliver [0x44e687] -> /usr/lib64/dovecot11/deliver(index_transaction_finish_commit+0x28) [0x444488] -> /usr/lib64/dovecot11/de liver [0x41f53f] -> /usr/lib64/dovecot11/deliver(index_transaction_commit+0x38) [0x4442f8] -> /usr/lib64/dovecot11/deliver(mailbox_transaction_commit+0x11) [0x45f221 ] -> /usr/lib64/dovecot11/deliver(deliver_save+0x107) [0x414267] -> /usr/lib64/dovecot11/modules/lda/lib90_cmusieve_plugin.so [0x2aaaab20987b] -> /usr/lib64/dovecot1 1/modules/lda/lib90_cmusieve_plugin.so(sieve_execute_bytecode+0x6b8) [0x2aaaab219dc8] -> /usr/lib64/dovecot11/modules/lda/lib90_cmusieve_plugin.so(cmu_sieve_run+0x30 b) [0x2aaaab20a35b] -> /usr/lib64/dovecot11/modules/lda/lib90_cmusieve_plugin.so [0x2aaaab208806] -> /usr/lib64/dovecot11/deliver(main+0xc4e) [0x41505e] -> /lib64/li bc.so.6(__libc_start_main+0xf4) [0x2aaaaaee5c14] -> /usr/lib64/dovecot11/deliver [0x413739] deliver(seriv): Jul 25 04:17:26 Panic: seq = 1587, rec->uid = 0, first_new_seq = 1587, records = 1586 deliver(seriv): Jul 25 04:17:26 Error: Raw backtrace: /usr/lib64/dovecot11/deliver [0x46e045] -> /usr/lib64/dovecot11/deliver [0x46dd2c] -> /usr/lib64/dovecot11/deli ver [0x44de1e] -> /usr/lib64/dovecot11/deliver [0x44e687] -> /usr/lib64/dovecot11/deliver(index_transaction_finish_commit+0x28) [0x444488] -> /usr/lib64/dovecot11/de liver [0x41f53f] -> /usr/lib64/dovecot11/deliver(index_transaction_commit+0x38) [0x4442f8] -> /usr/lib64/dovecot11/deliver(mailbox_transaction_commit+0x11) [0x45f221 ] -> /usr/lib64/dovecot11/deliver(deliver_save+0x107) [0x414267] -> /usr/lib64/dovecot11/modules/lda/lib90_cmusieve_plugin.so [0x2aaaab20987b] -> /usr/lib64/dovecot1 1/modules/lda/lib90_cmusieve_plugin.so(sieve_execute_bytecode+0x6b8) [0x2aaaab219dc8] -> /usr/lib64/dovecot11/modules/lda/lib90_cmusieve_plugin.so(cmu_sieve_run+0x30 b) [0x2aaaab20a35b] -> /usr/lib64/dovecot11/modules/lda/lib90_cmusieve_plugin.so [0x2aaaab208806] -> /usr/lib64/dovecot11/deliver(main+0xc4e) [0x41505e] -> /lib64/li bc.so.6(__libc_start_main+0xf4) [0x2aaaaaee5c14] -> /usr/lib64/dovecot11/deliver [0x413739] dovecot: Jul 25 06:52:21 Error: IMAP(seriv): Corrupted index cache file /var/spool/imap/seriv/.imap/.sisyphus-lists-altlinux-org/dovecot.index.cache: Corrupted cache d message_part data (physical_pos less than expected) --- -- With best regards, Sergey. dovecot: Jul 25 01:05:19 Error: IMAP(seriv): Corrupted index cache file /var/spool/imap/seriv/.imap/.community-lists-altlinux-org/dovecot.index.cache: Corrupted cach ed message_part data (physical_pos less than expected) deliver(seriv): Jul 25 04:17:26 Panic: seq = 1587, rec->uid = 0, first_new_seq = 1587, records = 1586 deliver(seriv): Jul 25 04:17:26 Error: Raw backtrace: /usr/lib64/dovecot11/deliver [0x46e045] -> /usr/lib64/dovecot11/deliver [0x46dd2c] -> /usr/lib64/dovecot11/deli ver [0x44de1e] -> /usr/lib64/dovecot11/deliver [0x44e687] -> /usr/lib64/dovecot11/deliver(index_transaction_finish_commit+0x28) [0x444488] -> /usr/lib64/dovecot11/de liver [0x41f53f] -> /usr/lib64/dovecot11/deliver(index_transaction_commit+0x38) [0x4442f8] -> /usr/lib64/dovecot11/deliver(mailbox_transaction_commit+0x11) [0x45f221 ] -> /usr/lib64/dovecot11/deliver(deliver_save+0x107) [0x414267] -> /usr/lib64/dovecot11/modules/lda/lib90_cmusieve_plugin.so [0x2aaaab20987b] -> /usr/lib64/dovecot1 1/modules/lda/lib90_cmusieve_plugin.so(sieve_execute_bytecode+0x6b8) [0x2aaaab219dc8] -> /usr/lib64/dovecot11/modules/lda/lib90_cmusieve_plugin.so(cmu_sieve_run+0x30 b) [0x2aaaab20a35b] -> /usr/lib64/dovecot11/modules/lda/lib90_cmusieve_plugin.so [0x2aaaab208806] -> /usr/lib64/dovecot11/deliver(main+0xc4e) [0x41505e] -> /lib64/li bc.so.6(__libc_start_main+0xf4) [0x2aaaaaee5c14] -> /usr/lib64/dovecot11/deliver [0x413739] deliver(seriv): Jul 25 04:17:26 Panic: seq = 1587, rec->uid = 0, first_new_seq = 1587, records = 1586 deliver(seriv): Jul 25 04:17:26 Error: Raw backtrace: /usr/lib64/dovecot11/deliver [0x46e045] -> /usr/lib64/dovecot11/deliver [0x46dd2c] -> /usr/lib64/dovecot11/deli ver [0x44de1e] -> /usr/lib64/dovecot11/deliver [0x44e687] -> /usr/lib64/dovecot11/deliver(index_transaction_finish_commit+0x28) [0x444488] -> /usr/lib64/dovecot11/de liver [0x41f53f] -> /usr/lib64/dovecot11/deliver(index_transaction_commit+0x38) [0x4442f8] -> /usr/lib64/dovecot11/deliver(mailbox_transaction_commit+0x11) [0x45f221 ] -> /usr/lib64/dovecot11/deliver(deliver_save+0x107) [0x414267] -> /usr/lib64/dovecot11/modules/lda/lib90_cmusieve_plugin.so [0x2aaaab20987b] -> /usr/lib64/dovecot1 1/modules/lda/lib90_cmusieve_plugin.so(sieve_execute_bytecode+0x6b8) [0x2aaaab219dc8] -> /usr/lib64/dovecot11/modules/lda/lib90_cmusieve_plugin.so(cmu_sieve_run+0x30 b) [0x2aaaab20a35b] -> /usr/lib64/dovecot11/modules/lda/lib90_cmusieve_plugin.so [0x2aaaab208806] -> /usr/lib64/dovecot11/deliver(main+0xc4e) [0x41505e] -> /lib64/li bc.so.6(__libc_start_main+0xf4) [0x2aaaaaee5c14] -> /usr/lib64/dovecot11/deliver [0x413739] dovecot: Jul 25 06:52:21 Error: IMAP(seriv): Corrupted index cache file /var/spool/imap/seriv/.imap/.sisyphus-lists-altlinux-org/dovecot.index.cache: Corrupted cache d message_part data (physical_pos less than expected)

2 5

[Dovecot] v1.1.alpha3 released
by Timo Sirainen 13 Aug '07

13 Aug '07

http://dovecot.org/releases/1.1/alpha/dovecot-1.1.alpha3.tar.gz http://dovecot.org/releases/1.1/alpha/dovecot-1.1.alpha3.tar.gz.sig All kinds of fixes and API changes. Previous alphas had some problems with index handling, now I didn't get any errors after almost 24h of stress testing. As a new feature userdb passwd now supports overriding some fields with templates. http://wiki.dovecot.org/AuthDatabase/Passwd

3 4

[Dovecot] logging dovecot-sieve vacation responses
by pod 13 Aug '07

13 Aug '07

I attach a patch that adds some informational logging for the vacation outcome in a similar style as the 'notify', 'redirect' and 'reject' cases. I considered adding logging for the not-willing-to-respond case since I think that would greatly assist testing/debugging vacation responses, but couldn't see where to put it that wasn't in the CMU code.

1 0

[Dovecot] plain authentication
by Roger D. Vargas 13 Aug '07

13 Aug '07

After upgrading my server I have found that Im not able to use plain auth for clients conecting from outside server. localhost clients (pine, webmail) works fine, but if I use Thunderbird I got an error saying that server requires TLS or SSL. But if I enable TLS or SSL I got more errors. I have tried sevral combinations, but havent found a working one. Here is my config, can somebody see what Im doing wrong? # /etc/dovecot/dovecot.conf protocols: imap pop3 ssl_disable: yes ssl_cert_file: /etc/ssl/dovecot/server.pem ssl_key_file: /etc/ssl/dovecot/server.key login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(pop3): no mail_extra_groups: mail mail_location: mbox:~/mail/:INBOX=/var/spool/mail/%u mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(pop3): /usr/lib/dovecot/pop3 auth default: passdb: driver: shadow userdb: driver: passwd -- Roger D. Vargas http://dsgp.blogspot.com

1 0