- dovecot - dovecot.org

[Dovecot] UW-IMAP style mbox snarfing from /var/mail/ to ~/mbox
by Timo Sirainen 09 Aug '07

09 Aug '07

http://dovecot.org/patches/mbox-snarf-plugin.c Also committed to CVS HEAD. Usage: mail_location = mbox:~/mail:INBOX=/var/mail/%u protocol imap { mail_plugins = mbox_snarf } protocol pop3 { mail_plugins = mbox_snarf } plugin { mbox_snarf = ~/mbox } If ~/mbox doesn't exist, nothing special is done. If ~/mbox exists, it's treated as INBOX and mails are moved from /var/mail/%u whenever the mailbox is synchronized. If all the messages couldn't be copied, for example because of out of quota, then none of the messages are copied. I suppose that could be a problem. It might be possible to fix that by changing: if (mailbox_copy(dest_trans, mail, 0, NULL, NULL) < 0) { if (!mail->expunged) { ret = -1; break; } } to just: if (mailbox_copy(dest_trans, mail, 0, NULL, NULL) < 0) { if (!mail->expunged) break; } But I'm not sure about that. Try and tell me. :)

2 18

Re: [Dovecot] assertion failed with KMail 3.5.6 and dovecot 1.0.0
by Timo Sirainen 09 Aug '07

09 Aug '07

On Mon, 2007-07-30 at 15:07 +0200, Sylvain Joyeux wrote: > > > IMAP(doudou): file ostream-crlf.c: line 339 (_send_istream): assertion > > > failed: ((size_t)ret <= iov.iov_len) > > Hmm. Can you get Dovecot to dump a core file? > > Probably easiest way to get this fixed would be then if you sent me > > the core file and also the imap binary and I'll debug it further. Or > > I could also send you several gdb commands you could run. > > Here are the imap executable and core dump files (compressed). They are > generated on a powerpc machine, so I'm not sure it will be useful to you. > Moreover, Debian strips its executables, so no line numbers ... Debugging information would have been really useful, but I did fix one bug and added some more asserts: http://hg.dovecot.org/dovecot-1.0/rev/bd113e9fe67b If it still wasn't fixed, maybe with this change it gives another assert.

1 0

[Dovecot] Outlook 2000/2003 frequent disconnect issue
by Jeff Ramsey 09 Aug '07

09 Aug '07

I have been using Dovecot for an IMAP server for a few years now, with no hitch. Even using Outlook 2K/2K3 as a client. Yesterday, I had a user experience the 'Negative UIDs' issue spoken of here: http://wiki.dovecot.org/Clients/NegativeUIDs I performed all of the steps mentioned in this article, and it seemed like it would work properly the first time the user checked their email, and then after that, they would get this error again. I checked to see what the latest stable version of Dovecot was, and decided to upgrade. I was at 0.99.11-8 and the latest stable rpm for my distro was 1.0.2-2. The upgrade went fine. Or so I thought. I am now getting the following message on all Outlook Clients: "Your IMAP Server closed the connection....this can occur if the connection is idle for too long" I have scoured the Internet for this error and have come up with many suggestions, none of which have worked. I have increased Outlook's timeout period to the full 10 minutes, and I have disabled SELinux. None of this seems to have worked. Is there anyone out there who has actually had this issue and resolved it? Can you please help? Thanks, Jeff Ramsey MIS Administrator TMI Forest Products, Inc. jefframsey(a)tubafor.com 360.477.0738 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

4 12

[Dovecot] Database server failure causes endless loop
by Andy Shellam 09 Aug '07

09 Aug '07

Hi, I've just started setting up Dovecot 1.0.1, and made an error in my configuration, which I think has found a potential problem in Dovecot. I'm using PostgreSQL authentication, and set the database host to "localhost", which PostgreSQL doesn't listen on, so libpq is throwing the standard "is the server running?" message. The problem, however, is Dovecot isn't seeming to understand this, and is endlessly looping, trying to query it every 5 seconds. My client (telnet during testing) is simply sitting there waiting for a response, which it's never going to get. After about 5 minutes, Dovecot killed the connection, saying "* BYE Disconnected for inactivity." If this was from an IMAP client, I'm guessing the client would time-out after so long when it doesn't get a response back. Wouldn't it be more sensible for Dovecot to try PostgreSQL, say, 3 times. If unsuccessful, send the client an "internal server error" or something similar? Otherwise if the database server failed, and the client tries to connect, it'd be waiting for at least a minute (or whatever the standard time-out interval is) before failing, whereas it'd be better to see almost instantly if the server's down. Regards, Andy. Log output: dovecot: Jul 01 11:31:03 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:31:03 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:31:03 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:31:08 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:31:08 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:31:08 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:31:13 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:31:13 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:31:13 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:31:18 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:31:18 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:31:18 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:31:23 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:31:23 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:31:23 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:31:28 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:31:28 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:31:28 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:31:33 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:31:33 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:31:33 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:31:38 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:31:38 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:31:38 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:31:43 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:31:43 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:31:43 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:31:48 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:31:48 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:31:48 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:31:53 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:31:53 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:31:53 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:31:58 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:31:58 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:31:58 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:32:03 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:32:03 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:32:03 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:32:08 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:32:08 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:32:08 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:32:13 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:32:13 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:32:13 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:32:18 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:32:18 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:32:18 Error: auth(default): TCP/IP connections on port 5432? dovecot: Jul 01 11:32:23 Error: auth(default): pgsql: Connect failed to <database>: could not connect to server: Connection refused dovecot: Jul 01 11:32:23 Error: auth(default): Is the server running on host "localhost" and accepting dovecot: Jul 01 11:32:23 Error: auth(default): TCP/IP connections on port 5432?

2 1

[Dovecot] Moving mboxes around
by tomas＠tuxteam.de 09 Aug '07

09 Aug '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dovecot gurus, I have a couple of questions for which I haven't found answers in the docs (which may be well more a limitation of my capabilities than anything else). Here they go: - Is it OK to move mailboxes around from under Dovecot? Case in point: I'm using procmail to pass incoming mail through bogofilter (the standard recipe mentioned in their manpage, which more or less funnels spam into a "spam" mailbox, unsure into an "unsure" and non-spam into "inbox"). From time to time I'd like to clear the spam and unsure mailboxes, using logrotate. Dovecot seems to cope with it. Am I tempting my luck? - Is there a way to tell an external application when mail has been moved by a client? Again: dovecot+bogofilter: from time to time a client checks incoming, unsure and sometimes spam and decides to move --say-- a mail from unsure to spam (deciding it's spam, after all) or similar. This is of course important for the training of bogofilter, so I'd like to trigger a backend action. I see basically two possibilities: - create two more mailboxes, say "spam-indeed" and "ham-indeed". User is told to move mail into these. Ham-indeed gets re-funneled to inbox (or something like that). Manual and error prone. - Use the mail_log plugin (seems more attractive). I still have (distro-provided) dovecot 0.99.14, but this would be a good reason to upgrade. (I still don't see where I get the source mailbox in the mail_log messages from, but that's details now). You get the idea, I think. Anyway, I am interested in any ways to combine dovecot and bogofilter in the backend in a way that I can route user feedback to the filter without putting too much burden on the user. Ideas? Thanks - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGtuS4Bcgs9XrR2kYRAkiXAJoDJYZC8DYIxFqCw+HEIn0CCNssQwCfaZjh z533XFMH36c4Lemv/+gSn9A= =s87z -----END PGP SIGNATURE-----

2 2

[Dovecot] dotlock file was deleted error
by Joe Wong 09 Aug '07

09 Aug '07

Hello, under what situation the error: dovecot-uidlist.lock was deleted (kept it 0 seconds ) will happen? I saw quite some of these in dovecot log. Thanks, - Joe

4 6

[Dovecot] passdb/userdb restart
by Thomas Hummel 09 Aug '07

09 Aug '07

Hello Timo, I've noticed that when slapd which I'm using as the passdb and the prefetched userdb is restarted I have to restart dovecot. As a matter of fact, if I don't, I get the following error : -- Jul 2 16:38:39 xxxx dovecot: imap-login: Internal login failure: user=<xxxx>, method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx, TLS Jul 2 16:38:46 xxxx dovecot: auth(default): prefetch(xxx,xxx.xxx.xxx.xxx): passdb didn't return userdb entries Jul 2 16:38:46 xxxx dovecot: auth(default): userdb(xxx,xxx.xxx.xxx.xxx): user not found from userdb -- I'm using dovecot-1.0.1 on FreeBSD 6.2-STABLE with openldap-server-2.3.35_1 (bdb backend). Would some cache-related parameters allow to fix that or will restarting dovecot be always mandatory after an ldap restart ? Thanks. -- Thomas Hummel | Institut Pasteur <hummel(a)pasteur.fr> | Pôle informatique - systèmes et réseau

2 1

[Dovecot] 1.1.alpha2 error in logs
by Mike Cisar 09 Aug '07

09 Aug '07

Did a quick-n-dirty install of 1.1.alpha2 on a Fedora Core 6 server... am getting the following message in the maillog, though there seems to be no problem accessing mail. Error seems to be consistent for all users. Running 1.0.3 on the system previously. Aug 8 22:49:26 stage2 dovecot: IMAP(testuser): mkdir(/var/spool/vmail/192.168.0.199/.imap/testuser) failed: Permission denied This is what I'm using for my env in dovecot.conf... default_mail_env = mbox:/vhome/%l/home/%n/mail:INBOX=/var/spool/vmail/%l/%n And here's what we have in the user's mail directory (from before)... /vhome/192.168.0.199/home/testuser/mail/.imap/Deleted Items /vhome/192.168.0.199/home/testuser/mail/.imap/Deleted Items/dovecot.index /vhome/192.168.0.199/home/testuser/mail/.imap/Deleted Items/dovecot.index.cache /vhome/192.168.0.199/home/testuser/mail/.imap/Deleted Items/dovecot.index.log /vhome/192.168.0.199/home/testuser/mail/.imap/INBOX /vhome/192.168.0.199/home/testuser/mail/.imap/INBOX/dovecot.index /vhome/192.168.0.199/home/testuser/mail/.imap/INBOX/dovecot.index.cache /vhome/192.168.0.199/home/testuser/mail/.imap/INBOX/dovecot.index.log /vhome/192.168.0.199/home/testuser/mail/.imap/INBOX/dovecot.index.log.2 /vhome/192.168.0.199/home/testuser/mail/.imap/sent-mail /vhome/192.168.0.199/home/testuser/mail/.imap/sent-mail/dovecot.index /vhome/192.168.0.199/home/testuser/mail/.imap/sent-mail/dovecot.index.cache /vhome/192.168.0.199/home/testuser/mail/.imap/sent-mail/dovecot.index.log I'm assuming that it's trying to create a folder for the user's INBOX index, but it's trying to create it in the mail spool directory rather than in /vhome/192.168.0.199/home/testuser/mail/.imap/INBOX as previously? Thoughts, comments, something I need to modify in my config? Cheers, >>>>> Mike <<<<<

2 2

[Dovecot] lda: vacation auto-reply for a virtual address
by martin f krafft 09 Aug '07

09 Aug '07

Hi, I am using Dovecot to manage a complex virtual mailbox setup. It's all working splendidly, thanks to the Dovecot LDA. This morning, however, I needed to create a vacation-style autoreply for one of the virtual addresses. I made use of cmusieve, authored a little sieve script, and had it working in no time... until I discovered how limited sieve's vacation module is. Most importantly: it's hardcoded to use the Return-Path of a message, but in this very case, I need to actually use the address in the from header. So I had to give up on sieve and am now looking for another solution, but without much success. Given that mail is delivered by the Dovecot LDA, is there any way to make deliver pass it off to e.g. procmail in such a way that $HOME is set to /srv/vmail/domain.org/localpart, so that procmail can find the .procmailrc? Cheers, -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck "we are trapped in the belly of this horrible machine, and the machine is bleeding to death." -- godspeed you black emperor! spamtraps: madduck.bogus(a)madduck.net

3 7

[Dovecot] LDAP and (py|cmu)sieve
by Thibault VINCENT 09 Aug '07

09 Aug '07

Hello, Before asking help, i would like thank Timo for this awesome server, it's lite, fast, and has good features. I've read the Wiki, tutorials, and tried various configurations to get the result I expect. My company is running a dovecot 1.0.0 server set up with an LDAP directory, mails are delivered to /var/spool/imap and users do not have a real unix home directory on this system. During my internship, I've installed a sieve server (pysieved) that is working with dovecot. But I encountered a problem with the LDAP setup. Pysieved is using dovecot's auth and client sockets to authenticate the user and get it's home directory where it will store sieve scripts, this home directory is also actually used by cmusieve. With our setup, users do not have /home directories on the mail server but the homeDirectory LDAP attribute is used by other services and cannot be modified for dovecot. I know we have the option to create a new attribute, set it to something like /var/spool/imap/<user> for every mail users, and use this new attribute name in dovecot-ldap.conf with the user_db statement. This is actually working on a test environnement, but we wish we could do it without any modification on the LDAP directory. The very precise question is : How can I tell dovecot to compute the « home » path from the login name when using LDAP userdb ? By example, if a user has login name "jdoe", dovecot will authenticate him against the LDAP directory but won't get the home path from it. Instead, it will use the same mail_location path (if possible) or something similar, like /var/spool/imap/%1u/%u . Can I do this without any modification of the source code of both dovecot and pysieved ? Thank you, -- Thibault VINCENT tibal(a)reloaded.fr thibault.vincent(a)reloaded.fr PGP Key : 0x4BA8A39B

2 1