- dovecot - dovecot.org

[Dovecot] imaps now works!
by Farkas Levente 18 Jun '03

18 Jun '03

thanks! -- Levente "Si vis pacem para bellum!"

1 0

[Dovecot] SASL Support
by Ken Crain 16 Jun '03

16 Jun '03

I need to support Outlook/Outlook Express users of Sendmail with SMTP Authorization. From what I can see, the LOGIN method available in Outlook/Outlook Express is the only applicable way to go at this time. It appears it is not supported in Dovecot right now. Is this correct and, if so, how would I go about adding this support?

2 1

[Dovecot] crash on LIST command
by Wouter Van Hemel 16 Jun '03

16 Jun '03

Hello, I'm experiencing a reproducable crash in the imap daemon of dovecot 0.99.9.1 when running the next commands (sniffed from a sylpheed session): [cocaine:~] telnet ice 143 Trying 192.168.196.1... Connected to ice. Escape character is '^]'. * OK dovecot ready. 1 NOOP 1 OK NOOP completed. 2 LOGIN wouter password 2 OK Logged in. 3 NAMESPACE 3 BAD Error in IMAP command: Unknown command 'NAMESPACE' 4 LIST "" "" * LIST (\Noselect) "/" "" 4 OK List completed. 5 LIST "" "%" Connection closed by foreign host. [cocaine:~] _ The log shows this: Jun 16 02:48:09 ice imap-login: Login: wouter [192.168.196.5] Jun 16 02:48:19 ice dovecot: child 1870 (imap) killed with signal 11 Looks like a segfault. [...] Core was generated by `imap'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libc.so.4...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x8058469 in mbox_list_inbox (ctx=0x8098080) at mbox-list.c:333 333 if (ctx->dir->virtual_path != NULL) (gdb) bt #0 0x8058469 in mbox_list_inbox (ctx=0x8098080) at mbox-list.c:333 #1 0x805809e in mbox_list_mailbox_next (ctx=0x8098080) at mbox-list.c:193 #2 0x804b75a in list_unsorted (client=0x8096080, ctx=0x8098080, reply=0x807ed06 "LIST", sep=0xbfbffac4 "/", listext=0) at cmd-list.c:234 #3 0x804b9fa in _cmd_list_full (client=0x8096080, lsub=0) at cmd-list.c:341 #4 0x804ba8b in cmd_list (client=0x8096080) at cmd-list.c:365 #5 0x804d39e in client_handle_input (client=0x8096080) at client.c:306 #6 0x804d43d in _client_input (context=0x8096080) at client.c:342 #7 0x8078c87 in io_loop_handler_run (ioloop=0x808d060) at ioloop-poll.c:210 #8 0x8078745 in io_loop_run (ioloop=0x808d060) at ioloop.c:295 #9 0x80524a9 in main (argc=1, argv=0xbfbffc2c, envp=0xbfbffc34) at main.c:166 #10 0x8049eb5 in _start () (gdb) _ This crash happens when adding an imap account to the sylpheed mailer. I also noticed other problematic log entries, which might or might not be related: Jun 16 00:28:36 ice imap-login: Login: wouter [192.168.196.5] Jun 16 00:28:36 ice imap(wouter): open() failed with file /usr/home/wouter/.mail/.imap/INBOX/.customflags: No such file or directory Jun 16 00:28:36 ice imap(wouter): Can't create temp index /usr/home/wouter/.mail/.imap/INBOX/.temp.hostname.domainname.tld.1728: No such file or directory ... this happens when an imap user connects and opens his/her INBOX for the first time, and the /usr/home/username/.mail/ directory doesn't exist yet. My DEFAULT_MAIL_ENV settings: #default_mail_env = mbox:~/.mail:INBOX=/var/mail/%u default_mail_env = mbox:/usr/home/%u/.mail:INBOX=/var/mail/%u (tried both) Manually adding the ~/.mail directory with mkdir takes care of the problem, but shouldn't this directory be created automatically when it doesn't exist? I can't expect every user to log in and first make this mail directory before they can use their mail account. Dovecot also refuses to show any folders at all, such as the INBOX, when it can't find it's mail(folders) directory. Is this intentional? Dovecot is running on a pretty standard (i386) FreeBSD 4.4 test machine with postfix and normal mbox-formatted inbox files. Thanks for any suggestions, wouter

3 6

[Dovecot] Dovecot will not run on secure kernel.
by Ola Garstad 16 Jun '03

16 Jun '03

I am trying to run Dovecot on RH 7.3 with Linux kernel 2.4.20 + GrSecurity patch. I downloaded the RPM yesterday and installed it. When I start Dovecot the kernel reports: kernel: grsec: From 192.168.1.22: attempt to overstep process limit by (dovecot:14491) UID(0) EUID(0), parent (dovecot:23872) UID(0) EUID(0) I have never seen this problem in the 3 years I have used GrSecurity together with a lot of programs. GrSecurity explains: "Enforce RLIMIT_NPROC on execs. Users with a resource limit on processes will have the value checked during execve() calls. The current system only checks the system limit during fork() calls." Any ideas why Dovecot causes this problem? -- Ola

2 1

[Dovecot] more newline related errors
by Mike Brown 16 Jun '03

16 Jun '03

Should I be concerned about these errors? imap(msun): Jun 13 13:21:38 Error: Error indexing mbox file /home/msun/mail/Deleted Messages: LF not found where expected imap(msun): Jun 13 13:39:08 Error: Corrupted binary tree for index /home/msun/mail/.imap/INBOX/.imap.index: lookup returned index outside range (1 >= 0) imap(msun): Jun 13 13:44:07 Error: IndexID mismatch for binary tree file /home/msun/mail/.imap/INBOX/.imap.index.tree imap(msun): Jun 13 13:44:07 Error: IndexID mismatch for binary tree file /home/msun/mail/.imap/INBOX/.imap.index.tree imap(msun): Jun 13 13:44:07 Error: IndexID mismatch for modify log file /home/msun/mail/.imap/INBOX/.imap.index.log imap(msun): Jun 14 12:07:42 Error: Error indexing mbox file /home/msun/Mailbox: LF not found where expected imap(msun): Jun 14 12:08:27 Error: Corrupted index file /home/msun/mail/.imap/INBOX/.imap.index: Sequence 1 not found from binary tree (1 msgs says header) imap(msun): Jun 14 12:08:27 Error: Corrupted index file /home/msun/mail/.imap/INBOX/.imap.index: Sequence 1 not found from binary tree (1 msgs says header) imap(msun): Jun 14 12:08:27 Error: Corrupted index file /home/msun/mail/.imap/INBOX/.imap.index: Sequence 1 not found from binary tree (1 msgs says header) imap(msun): Jun 14 12:14:23 Error: IndexID mismatch for binary tree file /home/msun/mail/.imap/INBOX/.imap.index.tree imap(msun): Jun 14 12:14:23 Error: IndexID mismatch for binary tree file /home/msun/mail/.imap/INBOX/.imap.index.tree imap(msun): Jun 14 12:14:23 Error: IndexID mismatch for modify log file /home/msun/mail/.imap/INBOX/.imap.index.log imap(msun): Jun 15 11:34:58 Error: Error indexing mbox file /home/msun/Mailbox: LF not found where expected There was a patch required for the POP3 server to read mbox files that did not precede "From " lines with a blank line. Perhaps this is related? Thanks

3 2

[Dovecot] bug in search? (fwd)
by Mark E. Mallett 14 Jun '03

14 Jun '03

I received this report and am passing it along.. mm > If all messages are marked for deletion, the following command returns > an empty list: > SEARCH DELETED > If all messages BUT one are marked for deletion the same command returns > a list of every message but one. > > If parens are used it works fine. > SEARCH (DELETED)

2 1

[Dovecot] Deleting NFS-mounted Maildir subfolders fails
by Christian Ehrhardt 14 Jun '03

14 Jun '03

Hi, [ please CC me on replies, I'm not subscribed to the list ] I'm using dovecot-99.9.1 with a little hack to get authentication to work the way we want it. The server is running on a Solaris 9 host and user homes are mounted via NFS from a Solaris 8 server (Version doesn't seem to matter). Almost everything's fine but I can't delete maildir subfolders if these reside on a non local NFS-directory. The reason given is that the directory isn't empty and hence can't be deleted. Most likely the following happens: dovecot has the index file and other stuff in the maildir subfolder opened via NFS. When the delete request comes in dovecot deletes these files but doesn't close them. On normal unix file systems this is no Problem but with Solaris NFS these file's aren't actually deleted until they are (explicitly or implicitly) closed. Instead they are renamed to .nfs.<some digits>. These files will automatically vanish once they are closed. However, as long as they exist it is impossible to delete the directory where these files reside and rmdir fails. This is not a big deal and one may argue that dovecot is fine and the NFS implementation is in error. However, it would be cool if dovecot could atttempt to close all administrative files before it deletes them (or at least before it tries to delete the directory where these files reside). regards Christian Ehrhardt -- THAT'S ALL FOLKS!

2 1

[Dovecot] Folder creation errors
by Mark E. Mallett 14 Jun '03

14 Jun '03

Hi- In a mbox environment: 1 login username password 1 OK Logged in. 2 create "slar" 2 NO Internal error [2003-06-11 15:44:56] 3 create "/slar" 3 NO Invalid mailbox name: /slar 4 create "Mail/slar" 4 OK Create completed. 5 create "./slar" 5 OK Create completed. 6 create "blar" 6 NO Internal error [2003-06-11 15:46:54] 7 logout * BYE Logging out 7 OK Logout completed. i.e. I get "internal error" if there is no path component in the folder name. Is this a problem? I would guess that "internal error" is always a problem :-) mm

2 3

[Dovecot] Speed and memory probs writing large Maildir
by Robin Whittle 14 Jun '03

14 Jun '03

I have Dovecot 0.99.9.1 compiled from the source, without SSL, running on a Red Hat 9.0 system - EXT3 file system, Pentium Pro 233 MHz, Intel motherboard, 128M RAM, IBM 40Gig 7200 RPM HD. I find reading and searching to be nice and fast, and comparing it with Courier IMAP on a Celeron 824 MHz, I think Dovecot is generally not much slower, which means it may well be faster than Courier in some or many ways if it was running on the same machine. My only problem is when writing mailboxes with large numbers of messages. I use Mailir - the same arrangement as Courier IMAP. (I also find that Netscape 4.77 can't use mailboxes which are subfolders of others, but that is probably a Netscape config problem.) I am using Netscape 4.77 (Windows 2000 1.3 GHz Celeron, via 100Mbps switched Ethernet to the Linux machines) to do these tests since I find Netscape 7.02 to be much slower. Netscape 7.02 seems to want to resynch its notion of the mailbox repeatedly as it is writing to it. Without looking at the IMAP traffic (I don't know how) I would say that Netscape 4.77 is not doing this at all. Indeed, after the write, looking at the mailbox causes Netscape 4.77 to read the headers from the IMAP server - so I feel sure that its way of writing the messages is purely "write". Writing a mailbox with a small number of large messages, such as 20 x 100k messages is fine. There is no obvious speed problem or excessive memory use. When writing 2000 x 1k messages, it is totally different. Here are some times for writing from a Netscape 4.77 local mailbox to Dovecot and to Courier IMAP. Message Total Time CPU max Memory RSS size number size Seconds Approx Megs - max Dovecot 100k 100 10M 23 15% ~2 100k 20 2M ~5 ? 1.2 10k 200 2M 20 15% 4 ! 1k 2000 2M 230 60 32 !!!! Courier IMAP 100k 100 10M 14 5% ~1 100k 20 2M ~2 ? ? 10k 200 2M 9 5% ~0.6 1k 2000 2M 88 2% ~0.6 This 2000 message test is small compared to some of the mailboxes I have. I used a real-live mailbox, 6878 messages - 44 Megabytes in a single Mbox for a more demanding test. Using Netscape 4.77 to copy this to a Dovecot Maildir took a very long time - over 30 minutes. The process was fast at first and got slower and slower. As the number of messages in the destination Maildir increased, the memory usage went up and the speed reduced. It seems that RSS memory usage (as reported by "top -d 0.3" hit some kind of limit at about 49 Megs after 4000 messages and then went down a little to about 48 or less. CPU usage was 30 to 82%, fluctuating according to the moment top looked. At the end, I think it was only writing 1.5 messages a second. RSS is the "total amount of physical memory used by the task". The "SIZE" was even bigger - "code plus data plus stack". This got up to 114 Megs by the end of the writing process! After the write had finished, I made Netscape 4.77 view the destination mailbox. This caused Dovecot to send it all the headers, and again Dovecot had these huge memory usage figures. It seemed to read the mailbox at a decent speed - 20 seconds or so. But if I made Dovecot look at another mailbox, and then again at this big target mailbox (say with another client - Netscape 7), it would read the big mailbox at Dovecot's usual high speed - without the high memory usage and I think without high CPU usage as well. Without knowing anything about how Dovecot works, I imagine that there is some kind of caching algorithm for writes, and that this is retained until Dovecot (or at least the instance serving this client) is asked to look at another Maildir. It seems that reading is not slowed by this process much or at all - but writing gets progressively slower as the cache gets bigger. The memory usage - even 49 Megs for RSS - seems excessive. It reached that about halfway through writing the mailbox, so the entire message contents at that state would have been about 22 Megs. But the "SIZE" memory usage is even larger - perhaps limited by the available RAM. This slow speed for writing Maildirs with large numbers of messages is currently a barrier to me using Dovecot. I am about to go back and try again to get Courier IMAP to do what I want . . . The Courier IMAP documentation and what I regard as the difficult "configure -> build -> install -> wonder why it doesn't run" process has cost me so much time that I would be very happy to use something simpler and easier (for me, at least) to install. Thanks for developing this new IMAP server! - Robin

4 8

[Dovecot] DRAC support?
by Charlie Allom 14 Jun '03

14 Jun '03

Hi, I was hoping someone had a quick and dirty (is there any other kind) of patch for DRAC support for dovecot. This daemon is very slick, and I wish to replace my complex courier-imap setup. Regards, C. -- charlie(a)rubberduck.com - Melbourne, Australia http://rubberduck.com/~yeled/ PGP: 0x14AA7941 || finger yeled(a)lazy.spodder.com > http://groups.google.com/groups?selm=3266D499.342E%40student.uq.edu.au <

5 44