January 2003 - dovecot

[dovecot] Weird problem on Alpha
by Amelia A.Lewis 06 Jan '03

06 Jan '03

Heyas ... Hope you aren't tired of me already .... I have a very strange problem, I think. Having become happy-happy with dovecot, I decided to install it on another machine that runs on an internal network and provides mailboxes for system monitoring. The setup is, or should be, quite straightforward. TLS is disabled, plaintext is not (I'll change this later, probably; this way is in theory easier to debug). Maildir; the MAIL environment variable is correctly set. Authentication via pam, for real users on the system, auth_user root. Pretty much as-distributed, except for disabling TLS. On attempted login, the client hangs. The following two messages appear in syslog: Jan 5 21:42:43 talifane imap-master: login: received another "not listening" notification Jan 5 21:43:43 talifane imap-login: Disconnected: Inactivity [127.0.0.1] Watching on lo via tcpdump, interesting things happen. If I login with the wrong password, the disconnect is quick (the message in syslog is different, just "Disconnected [127.0.0.1]" from imap-login). The server responds to the a0001 LOGIN command with a0001 NO Authentication failed. That's as expected. If I give the correct password, though, the server never responds. Note that the 'not listening' message appears sixty seconds before the disconnection for inactivity message. In tcpdump, it's clear that the client never gets anything that would give it reason to try another command. So ... have I managed to pull a total bimbo and misconfigure? Or is this a problem with the Alpha platform? I wanted to check before reporting a bug, but this is kinda strange, since it's about the simplest configuration that I can think of. Suggestions (for testing, or for fixing) would be welcome. Is there a way to start the daemon in a particularly verbose mode? In case it's useful, here's what the debian reportbug system generates for dependencies and stuff (0.99.5-1): -- System Information: Debian Release: testing/unstable Architecture: alpha Kernel: Linux talifane 2.4.19 #1 Sat Aug 3 10:33:38 EDT 2002 alpha Locale: LANG=en_US, LC_CTYPE=en_US Versions of packages dovecot depends on: ii libc6.1 2.3.1-9 GNU C Library: Shared libraries an ii libgcrypt1 1.1.10-2 LGPL Crypto library - runtime libr ii libgnutls5 0.6.0-2 GNU TLS library - runtime library ii libpam0g 0.76-9 Pluggable Authentication Modules l ii libtasn1-0 0.1.2-1 Manage ASN.1 structures (runtime) ii openssl 0.9.6g-10 Secure Socket Layer (SSL) binary a ii zlib1g 1:1.1.4-8 compression library - runtime It's specifically a PC164LX/533, 512MB RAM. Thanks for reading. Amy! -- Amelia A. Lewis amyzing {at} talsever.com You like the taste of danger, it shines like sugar on your lips, and you like to stand in the line of fire just to show you can shoot straight from your hip. There must be a 1000 things you would die for; I can hardly think of two. -- Emily Saliers

2 1

[dovecot] wierdness with mailboxes
by David E. Storey 06 Jan '03

06 Jan '03

Mail has always been the bane of my sys-admin life. I've been looking long and hard for a small, C-based, simple IMAP server that worked well with maildirs *and* mboxes and nothing else. wu-imap is so bloated and rife with decrepit, cross-platform, insecure code that I avoid it for any new servers. Courier-imap only supports maildirs but has some wierdnesses that I've come to live with. dovecot promises to be exactly what I'm looking for with just the right footprint and feature-set. =) I was surprised when I tried creating subfolders of mbox's. woohoo! The only problem is that dovecot manages to rename the parent, appending a '.'. So when we have: folder we now have: folder. folder.subfolder Evolution freaks out and thinks it can't store folders in 'folder.' and ends up with two subfolders: null and subfolder, which can contain messages. If I rename the parent folder without the trailing '.', everything works as expected. I'm trying to test some other imap clients now. d!

2 1

[dovecot] Some experiences
by Amelia A.Lewis 06 Jan '03

06 Jan '03

Heyas ... I'm trying to use dovecot to set up a 'closed server' (actually, mixed) sort of environment, for a box to be deployed co-located. I wanted to talk about some of that, and see if some of my experience qualifies as 'bug'. Note that I'm notoriously verbose, so if that bothers you, read no further .... Since it's a more-or-less closed server, I didn't want to use pam (well, I wouldn't mind, for users with shell accounts, but I can't see a way to mix pam and passwd-file ... is there a way to do that?). It turns out that digest-md5 support for clients is, well, not very widespread. I expect this box to be used by various windoze clients, eventually, and while I'm willing to lay down the law a little, I can't find enough digest-md5 support to lay down that law. So, regretfully, I abandoned that plan. This kinda bothers me, since I think TLS/STARTTLS is absolutely the *wrong* solution for mailbox access (or for anything that deals with a store-and-forward transport). I therefore tried md5 passwords in a passwd-file, with STARTTLS enabled. Didn't work. I turned off SSL, and reenabled plain-text, and watched the login go by. Very sniffable, of course. But correct username and password ... failed. There are instructions for creating digest-md5 style secrets in auth.txt, but none for md5 passwords; I used openssl passwd -1 [password] (and cut and paste). It seems odd to me that this didn't work; does that command use a different algorithm than dovecot? Falling back ... since it *shouldn't* matter if the passwords are weak, as long as they're inside TLS (along with the entire rest of the transaction, ugh), I used mkpasswd to generate a standard unix passwd (and cut and paste). This worked. It worked with TLS, and it worked without (as long as I remembered to allow sniffable logins). One more oddity: I originally had a realm in the passwd-file, which also established the mail location and 'home' directory (most of the users can't actually log in and don't have accounts in /etc/passwd, so it's not a real home directory). There was an odd message in syslog, approximately like so (where 'user' represents the username, and 'domain.realm' represents both my domain name and the realm in the passwd-file): imap(user:@omain.realm): Failed to create storage with data: domain.realm Note the missing first letter after user:@ And I don't know what it was trying to do; the maildirs already exist. /etc/dovecot.conf sets the default mail location to /home/users/%n/Maildir (non-shell users are all inside /home/users; shell users have mail there, with symlinks to ~/Maildir); the passwd-file establishes the location of the INBOX pretty definitively, I would think. The solution was to remove the realm (which isn't useful except for digest md5, anway, right?). Hey, it's working! Wahoo! *laugh* Anyway, if someone can offer suggestions on what's up with the pieces that *aren't* working, I'd be interested to know. It might give me a greater range of options. Amy! -- Amelia A. Lewis amyzing {at} talsever.com The less I seek my source for some definitive, the closer I am to fine. -- Indigo Girls

6 12

[dovecot] Util for pop3 to dovecot?
by Brad Figg 04 Jan '03

04 Jan '03

What I want to do is pop my email off of a Pop3 server and give it to dovecot for imap serving. Does anyone know of a utility that will allow me to do this? I looked at fetchmail but it seems to want to talk to an SMTP server. Thanks, Brad -- Brad Figg - brad(a)tpi.com 503.601.0235 ext. 105 TriplePoint, Inc. - http://www.tpi.com

3 2

[dovecot] maildirmake, shared folders
by Amelia A.Lewis 03 Jan '03

03 Jan '03

Does dovecot support shared folders, maildir style? I've set it up, using the maildirmake from debian maildrop to create folders. I have a number of as-yet unresolved issues, so I haven't been able to test with many clients. It's interesting that dovecot manages to present folders as siblings (rather than children) of INBOX. But mutt, at least, doesn't seem to see the shared maildir (created per instructions in the maildirmake man page). I find in the debian archives that courier is unable to see messages delivered to new in a shared maildir. This doesn't seem to be the same set of symptoms, though. It appears, instead, that dovecot isn't recognizing (and then advertising) the shared-maildirs file (a text file that describes the name and the location). Is that the case? I don't think it's a high priority, mind, just wondering. Another question: can the dovecot distribution include a maildirmake utility? The documentation is pretty blunt about the significant advantages of maildirs, but one has to go to the courier distribution to find a utility to pre-create these (which dovecot seems to want, since it's recognizing the mail type by looking for the dir). This is most significant when setting up new users, of course. Possibly this is inappropriate, and I should instead ask the debian package maintainer to 'recommend' or 'suggest' the maildrop package in order to get the required utility. Nice stuff, though. I really like the ease of administration; dovecot looks to me like a sort of equivalent to postfix, for IMAP instead of SMTP. A request for the website: perhaps developers could supply information on clients used with the server, and what oddities are encountered? I know that IMAP client support is spotty, at best (for instance, I can't find a client that can do digest-md5; mutt is supposedly capable, but my installation doesn't even admit that that's a valid authenticator). This is partly significant because setting up a system that uses options for which there is little or no client support is, perhaps, an exercise in futility. Amy! -- Amelia A. Lewis amyzing {at} talsever.com Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise. -- The Duchess [Lewis Carroll]

3 2

[dovecot] 0.99.5 released
by Timo Sirainen 02 Jan '03

02 Jan '03

v0.99.5 2003-01-02 Timo Sirainen <tss(a)iki.fi> * This release includes a lot of code cleanups, especially related to security. Direct buffer modifying was replaced in several places with a new buffer API, which provides a safe way to do it. Code that looks unsafe contains @UNSAFE tag to make auditing easier. + Support for SORT extension. Originally I thought about not implementing any extensions before 1.0, but too many people want webmails which want SORT. THREAD is another extension which they want, but we don't support it yet. + imap_listen and imaps_listen settings now accept "*" and "::" to specify if we want to listen in IPv4 or IPv6 addresses. "::" may also listen in all IPv4 addresses depending on the OS (Linux does, BSD doesn't) + New setting: default_mail_env can be used to specify where to find users mailbox. Default is still to use autodetection. + New setting: imap_log_path to log logins etc. informational messages to different file. + We support now separate mbox file for INBOX folder, no need for symlink kludging anymore. + Support for keeping index files in different location than actual mailboxes. ? Disabled mailbox_check_interval setting by default, it breaks Evolution. - SEARCH was still somewhat buggy, especially with laggy networks. Also body/header searches might have crashed or at least used memory too much - Deleting messages in the middle of mbox caused dovecot to reindex the following messages as new messages (ie. change UIDs and set \Recent flag). - Digest-MD5 auth: Initial server challenge packet was missing a comma, which might have made it incompatible with some implementations. - Some more fixes to unnecessarily high memory usage - SELECT and EXAMINE often printed UNSEEN reply or maybe complained about corrupted indexes. Happened usually only with mbox. - FETCH BODYSTRUCTURE gave incorrect reply, breaking pine - LIST was pretty buggy with mbox subfolders - CHECK command returned just "missing parameters" error - DELETE didn't work with mbox folders - CREATE mailbox<hierarchy separator> failed always. - CREATE and RENAME didn't create required hierarchies with mbox - RFC822 date parser didn't handle single digit days correctly. - login_process_per_connection = yes didn't work with imaps port connections which is exactly where it was mostly wanted. - ssl_disabled = yes didn't disable listening in imaps port - process limiting code didn't compile everywhere (eg. FreeBSD). - Linux sendfile() was never detected - We didn't work at all with gcc/PowerPC

1 0