November 2007 - dovecot

[Dovecot] can't rename folder whiten with non ASCI charters
by Nikolay Shopik 17 Nov '07

17 Nov '07

Running dovecot 1.0.5 on Debian testing. I've just tried to create folder using Russian charters after that I'm tried to renamed it without luck. Folder removed and no new created and I still subscribed to old folder even its not exist anymore.

2 2

[Dovecot] using # special charter in config
by Nikolay Shopik 17 Nov '07

17 Nov '07

Before dovecot I'm using # charter to mark public folders. So if I want set prefix = # its of course won't work, I tried using \# combination without luck. Is this possible anyway?

2 1

[Dovecot] Path to public folder subscription file not created in 1.1b7?
by Adam McDougall 17 Nov '07

17 Nov '07

I use CONTROL=%h/Maildir/dovecot/public/control/[namespace] for each of my public namespaces. A few nights ago, I noticed having a new user subscribe to public folders for the first time will silently fail, becuase the path up to the subscriptions file will not be created. I am pretty sure dovecot used to create it for me, but maybe that changed in a recent version, or maybe I did something to break it? Work around is to mkdir -p /home/[user]/Maildir/dovecot/public/control/[namespace] but I'd like to avoid having to do that. Once I create the directory and make sure it is writable, the client can subscribe to public folders in that namespace. If they do not have permission, it still silently fails. namespace: type: public separator: / prefix: #shared/decs/ location: maildir:/egr/mail/shared/decs:CONTROL=%h/Maildir/dovecot/public/control/decs:INDEX=%h/Maildir/dovecot/%q/public/indexes/decs list: yes subscriptions: yes

2 1

[Dovecot] RHEL 5.1 Can't compile with --with-linux-quota
by Laurent PELLISSIER 16 Nov '07

16 Nov '07

Hi, On a freshly installed RedHat RHEL 5.1 x86 with quota-3.13-1.2.3.2.el5.rpm I can't compile neither dovecot 1.0.7 nor 1.1beta8 : $ ./configure --with-linux-quota && make [...] gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../src/lib -I../../../src/lib-dict -I../../../src/lib-index -I../../../src/lib-mail -I../../../src/lib-storage -I../../../src/lib-storage/index -I../../../src/lib-storage/index/maildir -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -I/usr/kerberos/include -MT quota-fs.lo -MD -MP -MF .deps/quota-fs.Tpo -c quota-fs.c -fPIC -DPIC -o .libs/quota-fs.o quota-fs.c: In function 'fs_quota_get_linux': quota-fs.c:442: error: 'yes' undeclared (first use in this function) quota-fs.c:442: error: (Each undeclared identifier is reported only once quota-fs.c:442: error: for each function it appears in.) make[4]: *** [quota-fs.lo] Error 1 make[4]: leaving directory « /home/kermit/dovecot-1.1.beta8/src/plugins/quota » $ make distclean && ./configure --without-linux-quota && make -> same error $ make distclean && ./configure --disable-linux-quota && make -> compile fine Best regards, -- Laurent PELLISSIER @ Ecole des Mines d'Alès

2 2

[Dovecot] Mail.app IDLE support
by Martin R. Ehmsen 16 Nov '07

16 Nov '07

Hi, I'm trying to use the new IDLE support in Mail.app on Mac OS 10.5, and it works sort of, but it seems to miss some notifications. My guess is the IDLE support in Mail.app is implemented such that it sets up a connection for IDLE notifications and then checks the mail via another connection, and because of that the "IDLE-connection" gets disconnected for inactivity after 30 min. The reason for my guess is that I get the following in my logs: dovecot: Nov 14 17:00:29 Info: imap-login: Login: user=<amanda>, method=PLAIN, rip=::ffff:xxx.xxx.xxx.xxx, lip=::ffff:192.168.1.2, TLS dovecot: Nov 14 17:00:29 Info: imap-login: Login: user=<ehmsen>, method=PLAIN, rip=::ffff:xxx.xxx.xxx.xxx, lip=::ffff:192.168.1.2, TLS dovecot: Nov 14 17:00:30 Info: imap-login: Login: user=<amanda>, method=PLAIN, rip=::ffff:xxx.xxx.xxx.xxx, lip=::ffff:192.168.1.2, TLS dovecot: Nov 14 17:00:50 Info: imap-login: Login: user=<ehmsen>, method=PLAIN, rip=::ffff:xxx.xxx.xxx.xxx, lip=::ffff:192.168.1.2, TLS dovecot: Nov 14 17:00:51 Info: imap-login: Login: user=<ehmsen>, method=PLAIN, rip=::ffff:xxx.xxx.xxx.xxx, lip=::ffff:192.168.1.2, TLS dovecot: Nov 14 17:04:58 Info: imap-login: Login: user=<ehmsen>, method=PLAIN, rip=::ffff:xxx.xxx.xxx.xxx, lip=::ffff:192.168.1.2, TLS dovecot: Nov 14 17:30:40 Info: IMAP(amanda): Disconnected for inactivity dovecot: Nov 14 17:43:29 Info: IMAP(amanda): Disconnected for inactivity Is there something I can do about this problem? Is the IDLE implementation in the 1.1 branch different from the implementation in the 1.0 branch of dovecot? Or can I debug this issue further? I guess these things are standardized, but it seems hard for Apple to follow a standard :-) Thanks in advance, Martin R. Ehmsen

5 10

Re: [Dovecot] umask not applied
by Nikolay Shopik 15 Nov '07

15 Nov '07

- original message - Subject: Re: [Dovecot] umask not applied From: Thomas <lists(a)abelonline.de> Date: 15/11/2007 00:46 Quoting Troy Engel <tengel(a)fluid.com>: > I'll be the first to mention that 1.0rc15 is ancient by dovecot > standards, upgrade to 1.0x first and see if it's still broken. I am running a debian etch server. Unfortunately 1.0rc15 is the lastest version available in the stable tree. I would really like to remain in stable if somehow possible since I think combining stable and unstable will lead to chaos. I'll check the changes in later version and if they mention something about umask. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. If you are stick with debian stable just use backports so you don't mess up anything and still will be running stable and almost latest packages.

3 5

[Dovecot] Is there any way to query a secure imap server for certificate details
by Stewart Dean 15 Nov '07

15 Nov '07

? -- ==== Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 sdean(a)bard.edu voice: 845-758-7475, fax: 845-758-7035

3 2

[Dovecot] SSL/TLS with Outlook client
by Jonathan Bond-Caron 15 Nov '07

15 Nov '07

Anyone have any solution to this? I also getting a "The target principal name is incorrect." in Outlook 2007 Is this a problem with dovecot?

10 20

[Dovecot] dovecot.index mtime
by Matt 15 Nov '07

15 Nov '07

Is there anyway I can get Dovecot to update mtime on dovecot.index everytime a user successfully checks there email? Or perhaps there is a better way to do what I want here. I am working on a script that I want to check when the last time a user checked there email account. If a user has not checked it in say 6 months I want to automatically suspend the account through the MTA. If they start checking it again I also want to automatically reinstate it. What I thought was a good way was to look at the mtime on dovecot.index but a user can be checking there email daily but if they do not receive a new message in say 6 months the mtime will date back to 6 months still. Ran into this with an email address used by a fax machine. So is there a better way with dovecot to determine this? I am using dovecot-1.0.rc29 right now. Matt

5 17

[Dovecot] New full text search indexer
by Timo Sirainen 14 Nov '07

14 Nov '07

As described earlier (http://dovecot.org/list/dovecot/2006-December/018055.html) Dovecot nowadays has full text search indexing support in CVS HEAD. Currently there are two backends: Lucene and Squat. Lucene's problem is that standard IMAP SEARCH command can't be used with it without breaking IMAP RFC. So Lucene can be used only with non-standard X-BODY-FAST and X-TEXT-FAST search commands. Squat's code then is quite complex and it's pretty slow. It works with 4 character blocks, so it can answer: - Search string < 4 characters: Can't answer anything - Search string = 4 characters: Definite yes/no - Search string > 4 characters: Probable yes / definite no Since search strings are usually more than 4 characters, Dovecot uses the index only to filter out messages which definitely won't match and then does regular searching for the non-filtered messages. It works ok, but it could work better. The Squat indexes take maybe 30-50% of the mailbox's size. Most of the space goes to UID lists (list of messages matching each 4 character block). For example one UID list could be "2,4-10,20-30". This is already stored in a compressed format by storing the UID numbers relative to previous UID, which allows storing them usually with a single byte per UID, even if the UIDs are large. So, this morning I had an idea how this could maybe be improved with two changes: 1. Don't use 4 character blocks. Instead allow variable sized paths, and keep track of the UIDs for each node in the path. So for example adding "abc" to UID 1 will place the UID 1 to node "a", "ab" and "abc". 2. Use UIDs relative to parent's UIDs. For example if node "a" has UIDs 1,3,5 and "ab" is added for UID 5, the UID is changed to 2 (3th in 1,3,5 list - 1). This can help the compression a lot. The best case scenario for the above example is if "ab" contains also 1,3,5 UIDs. Then it can be written with a single 0-2 range. With these changes, the indexer can be configured to perform in different ways. Text can be indexed in two ways: full words, and substrings within those words (as required by IMAP). I think a useful combination of these would be to index all 4 character substrings and all full words up to 10 characters or so. This kind of an index can answer: - Search string <= 4 characters: Definite yes/no - For X-BODY-FAST / X-TEXT-FAST: - Search string 5-10 characters: Definite yes/no - Search string 11+ characters: Probable yes / definite no - For standard IMAP SEARCH: - Search string 5-10 characters: Definite yes if message contains the key as non-substring, otherwise same as below. This helps only if user does a search that matches a lot of messages. - Search string 11+ characters: Probable yes / definite no UTF-8 text is indexed as bytes, but the path depth can be counted as characters instead of as bytes. I've a test program finished, and unless there are some bugs left I think it shows that this can work pretty well: Squat-like 4 byte substrings (but can answer 1-3 char queries also): Message count: 7495 Index time: 4.19 CPU seconds (7.39MB/CPUs) Node memory: 3014072 bytes (2943 kB) in 90550 nodes UID memory: 8277212 bytes (8083 kB) in 352778 lists Total: 11291284 / 32474899 bytes = 34.77% Indexing the same mailbox file with squat-test gives: - Index time: 9.55 CPU seconds, 9.63 real seconds (3.24MB/CPUs) - 4145192 bytes in 102208 nodes (12.76%) - 7286058 bytes in 305501 uid_lists (22.44%) - 11431250 bytes total of 32474899 (35.20%) So the new indexer is over twice as fast and uses slightly less space. Indexing 4 char substrings and words up to 10 chars: Index time: 5.13 CPU seconds (6.04MB/CPUs) Node memory: 6002804 bytes (5862 kB) in 615501 nodes UID memory: 9044610 bytes (8832 kB) in 519488 lists Total: 15047414 / 32474899 bytes = 46.34% So it takes somewhat more space, but definitely less than having both Squat + Lucene. No substring indexing, words up to 10 chars (Lucene replacement): Index time: 1.39 CPU seconds (22.28MB/CPUs) Node memory: 3297663 bytes (3220 kB) in 548540 nodes UID memory: 1803735 bytes (1761 kB) in 213554 lists Total: 5101398 / 32474899 bytes = 15.71% Is there a need for Lucene anymore with this kind of a speed and disk space usage? :) The above tests are run with everything being indexed except space and control chars (ie. practically space + tab). If only alphanumeric characters are indexed, the total lines are (in same order as above): Total: 7048664 / 32474899 bytes = 21.70% (-13.07%) Total: 9610543 / 32474899 bytes = 29.59% (-16.75%) Total: 3963335 / 32474899 bytes = 12.20% (-3.51%) There are probably still a few optimizations that can be done to get the disk space usage even lower. I did spent quite a lot of time making it use less CPU though. Even tried a bit different coding style variations in the critical functions to get gcc to create faster code.. One interesting thing I noticed was that binary searching a character from a char array was slower than just sequentially going through the characters. I tried adding checks to do it only if the array was big, but it was always slower. Maybe something to do with CPU cache. If you want to try yourself, the test program is in http://dovecot.org/tmp/new-indexer.c

7 10