October 2003 - dovecot

[Dovecot] gzipped files in Mail directory
by Olivier Tharan 09 Oct '03

09 Oct '03

Hi, I have been testing dovecot on my own machine before a bigger deployment. Basically I have all my mbox mailboxes in ~/Mail, delivered by procmail. Some mbox's are gzipped because they are archives which I can grep into, but do not want to look at often. When I first launched an IMAP client, dovecot created the indexes (I think) and gave several errors when finding a gzipped file, such as: ,---- | Oct 1 19:53:21 mafate imap(olive): File isn't in mbox format: /home/olive/Mail//Archives/daily.d/mafate.2003.gz `---- After 19 gzipped mbox's, I had the following crash: ,---- | Oct 1 19:53:21 mafate dovecot: child 4923 (imap) killed with signal 10 `---- Does dovecot not like gzipped mbox's? For the moment, all gzipped files are in ~/Mail/.Archives and I can live with it. -- olive

1 0

[Dovecot] Line length limitation in dovecot leads to out-of-control process?
by Amelia A. Lewis 09 Oct '03

09 Oct '03

Heylas! I've been copying mailboxes from one dovecot server (on an alpha running debian testing, 0.99.10-9) to another (on an i686 running debian unstable, 0.99.10-9). I encountered a weird problem, which I seem to have resolved by moving a message with a To: line from hell out of the mailbox. Both machines are running maildir. They're not exactly identical, but they're fairly similar, apart from differences in distribution and architecture; they're running the same version of dovecot, supposedly. Specifically, when I copied this folder over to the new location, dovecot went into CPU-feeding frenzy (up to 99.7% of CPU), and stayed there. If I killed the client and tried to look at the same mailbox using a different client (mutt instead of sylpheed), without killing the imap processor on the server, the indexes would be locked, mutt would fall back to reading headers instead, and then would send its imap process into CPU-feeding frenzy when it got to one particular message. After some experimentation, I found the message. Once I moved it out of cur, I could access the mailbox without problems. The odd thing is that I can look at the message on the original machine, but on the machine it was copied to, its mere existence makes the mailbox inaccessible. After a little more exploration (grep ^To name-of-message | wc, on both machines) I seem to have found the issue: the original message has a To: line that is 16504 characters long. In the copy, it's 8192 characters long, and ends in the middle of a <email@address> (line in copy ends: user name <emai, chopped right there). I suspect that it is the *latter* that's causing dovecot to die a messy death. Or, actually, to turn into a very *rude* process that *doesn't* die. It's a really stupid trick to stuff that much into a header line (it's from helixcode in 2000, btw, notifying people that the promised CD is late), and perfectly reasonable to truncate (even to truncate to 1000 characters, per 282[12]). However, I kinda thing dovecot shouldn't choke on the results of truncation, which is what I think is the problem. Amy! -- Amelia A. Lewis amyzing {at} talsever.com I have spent nights with matches and knives, leaning over ledges, only two flights up. Cutting my heart, burning my soul. Nothing left to hold. Nothing left, but blood and fire. -- Indigo Girls

2 2

[Dovecot] Darwin Build (cvs)
by Jesse Peterson 09 Oct '03

09 Oct '03

Oops, I apologize for my short, breif message that didn't even include what I said it should inlcude =). Here's the deal: OpenDarwin 6.6 (closest relative being Mac OS X 10.2.6) won't build from CVS. Specifically libtoolize doesn't seem to exist (does it even come with libtool?) and the other parts of the "autogen.sh" fail miserably. This time (really) attached is a gzip of the log of autogen.sh: "./autogen.sh >& autogen.log". Thanks for any help! - Jesse

2 1

[Dovecot]
by Jesse Peterson 08 Oct '03

08 Oct '03

% uname -a Darwin xxx 6.6 Darwin Kernel Version 6.6: Sun Jul 6 05:12:51 PDT 2003; root:tmp/xnu-6.6.2-4-root.obj/RELEASE_PPC Power Macintosh powerpc Attached is a gzipped "sh autogen.sh >& autogen.log" for the above machine. What do you think? Jesse Peterson <jesse(a)mactechs.com> Office 206.441.7443 / Fax 206.441.8078 MacTechs / Macintosh System and Network Support 2121 First Avenue, Suite 103 / Seattle, Washington 98121 http://www.mactechs.com/

1 0

[Dovecot] those assertions
by dovecot＠spam.turbolink.net 06 Oct '03

06 Oct '03

Timo, Just FYI while you're working on the mbox code, I discovered a bug that occasionally causes dovecot to insert a single blank line at the beginning of the mbox, I'm not sure when/how/why. A single blank line seems to really confuse dovecot, and causes the server to crash when somebody connects to an afflicted mbox. ("Error indexing mbox" in the log, and disconects the user right away). I fixed it with lots of ugly code at our site (basically just remember that we skipped an intial blank line when doing other operations, instead of skipping it then forgetting later). I suspect there's a more elegant way to do it. - Mike

1 0

[Dovecot] SSL Client Certificate Support
by Bert Koelewijn 06 Oct '03

06 Oct '03

Dear Timo, most modern enterprises make use of a Public Key Infrastructure. It would be nice to have dovecot check a client certificate instead of a password. This makes life much easier and more secure. Mail clients like Mozilla and MS Outlook do support this. What do you think of the following feature request: - Client authenticates with a certificate via SSL. (Like stunnel can) - Dovecot looks the username up in a table with (public key, username) - The mailclient gives a name and password, but dovecot ignores them - Dovecot gives the client access by the username found in the table This way existing mail clients can use this system and you can save your username with an empty password. Best Regards, Bert Koelewijn

5 10

[Dovecot] those assertions
by Bernard Blackham 05 Oct '03

05 Oct '03

Hi, I did a bit of digging into the assertions from mbox-rewrite.c (hdr_parsed_size.physical_size == hdr_size). Every time it happens, hdr_size is 0, while hdr_parsed_size.physical_size is non-zero (presumably the correct value). Does this help track it down? I can't manage to get hold of an mbox that causes this though. Another infrequent assertion that's popped up: file message-address.c: line 262 (message_address_write): assertion failed: (addr->domain != NULL) And one that's only ever been spotted once in the last few weeks: file imap-bodystructure.c: line 278 (part_parse_headers): assertion failed: (part->physical_pos >= input->v_offset - start_offset) I'm waiting for them to happen again to provide some more info... Regards, Bernard. -- Bernard Blackham bernard at blackham dot com dot au

2 1

[Dovecot] another Dovecot problem
by Tim Miller 05 Oct '03

05 Oct '03

Hi All-- First, thanks to Timo for solving my last issue. I got dovecot up and running on one of my machines, and it does exactly what I want. Now I'm trying to install dovecot on an older box (glibc 2.0.7 Linux kernel 2.0.36), and encountering some problems: -- firstly autoconf/automake does not seem to correctly deal with the madvise function on this system. It detects that we don't have madvise, yet it's prototyped in /usr/include/sys/mman.h. This causes the compilation to fail when dovecot tries to redefine this function. -- I attempted to solve this problem by renaming the function dovecot prototypes to dc_madvise and then changed all the calls in the code (and the implementation) from madvise to dc_madvise. This allows the code to compile correctly. -- However, once the server is installed, it does not appear to work correctly. I can login, but when I try to list my folders or select any folder (one that exists or one that doesn't exist) the connection times out and the following entry is written to the log file: dovecot: Oct 03 05:38:56 Error: login: received another "not listening" notification (if you can't login at all, see src/lib/fdpass.c) I tracked this message down in the source, but didn't see any obvious way to trace back the problem. Does anyone have experience building on this older configuration (the glibc is a Red Hat version, if it makes any difference)? Any ideas on what might be causing this issue? Best, Tim Miller

2 5

mbox/maildir/directories [was: Re: [Dovecot] still getting weird .{inbox} folder creations with latest -test7]
by Miquel van Smoorenburg 05 Oct '03

05 Oct '03

This is a bit of a late reply, but still: On Thu, 2003-09-04 at 15:06, Timo Sirainen wrote: > CVS has been optimized to assume all files beginning with a dot (except > .subscriptions currently) are mailboxes. This is faster since it doesn't > have to stat() each file to figure out if it's a directory or not. > Perhaps that should be optional. New Linux systems (maybe others too) > wouldn't actually even need the stat().. > > I'll probably some day also add support for dotless directory-structured > mailbox locations, but it's not really high priority. Well, on our systems the mailbox is in /var/mail in maildir format, and in ~/Mail users have split up their folders in subdirs, in mixed maildir and mbox formats. So if dovecot could support both dotless directory-structured mailbox locations and maildir/mbox mix-n-match in the same tree, that would be excellent for us. Mbox is a better format for archiving. Now if Dovecot could also access (read-only ofcourse) compressed mbox archives ... Food for thought. Just put it on the wishlist ;) Mike.

2 1

[Dovecot] Patches
by Jaldhar H. Vyas 05 Oct '03

05 Oct '03

As the freeze for Debian sarge slowly approaches I want to make sure the Dovecot packages are in as good condition as possible. I see there have been a number of patches since 0.99.10. I have added the following patches: * segfault when user home directory is empty * Proper PAM service name * Make suid work on 2.6 kernels Any other patches thatI ought to add. Or better yet, will there be a 0.99.11 soon? -- Jaldhar H. Vyas <jaldhar(a)debian.org> La Salle Debain - http://www.braincells.com/debian/

5 4