- dovecot - dovecot.org

[Dovecot] Unwanted INBOX. prefix issues
by Kevin Bowling 26 Mar '07

26 Mar '07

I have a strange problem. I installed Dovecot and had my trash folder and such in the root of my maildir, and everything was working great. I then installed SquirrelMail which created folders in with the INBOX. prefix. I manually removed these from the maildir, but the INBOX.Trash is still shown in the folder listing of Thunderbird. This leads to some strange behavior, such as the delete button not working. Is there a way I can reset the folder list, and take the INBOX.* items out? Any help would be appreciated. Regards, Kevin

2 4

[Dovecot] Rpm builders: Dovecot spec file
by Egbert Jan 26 Mar '07

26 Mar '07

Maybe best asked to Axel... I'm re-building my server from scratch (the old one was MDK 10.1 -> Mandriva 2006.0 with Postfix/Courier) and I want to install the latest versions postfix/mysql/postfixadmin/dovecot/squirrelmail. I've been building Dovecot (and postfix) from tarballs/srpm in the past so I know more or less how it all fits together. But I wonder if 'old' patches still need to be included/applied in the building of the latest rc's. I still see references to those patches in the spec file. Unfortunately the latest 'official' rpm for Mandriva (I'm running 2007.0) is rc7 and I never succeeded getting in contact with the Mandriva maintainer to ask the same question. In the Axel's AT rpm I still see some patches included but others than in the Mandriva rc7 spec file. Are those patches not already applied to the latest sources by Timo? Tnx Egbert Jan NL

2 2

[Dovecot] assertion failure with nopassword
by Johannes Berg 26 Mar '07

26 Mar '07

Hm, so my mailing list archive is up, but when I add nopassword to the list of settings in my passdb passwd-file I get: file auth-request.c: line 924 (auth_request_set_field): assertion failed: (request->passdb_password == NULL) Raw backtrace: dovecot-auth [0x806be11] -> dovecot-auth [0x806bd8c] -> dovecot-auth(auth_request_set_field+0x277) [0x80547d7] -> dovecot-auth [0x8060418] -> dovecot-auth [0x8060509] -> dovecot-auth(auth_request_verify_plain+0xb3) [0x80559b3] -> dovecot-auth [0x8055ac2] -> dovecot-auth(auth_request_verify_plain_callback+0x30) [0x8055b50] -> dovecot-auth [0x8060dbe] -> dovecot-auth(io_loop_handler_run+0x152) [0x806f1c2] -> dovecot-auth(io_loop_run+0x28) [0x806e508] -> dovecot-auth(main+0x2fb) [0x805aaab] -> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xc8) [0xb7a3fea8] -> dovecot-auth [0x8050ff1] This is with rc27. I don't seem to be able to get the passdb_password to NULL with passwd-file. johannes

2 2

[Dovecot] Bug tracking system
by Timo Sirainen 26 Mar '07

26 Mar '07

There are three reasons why I haven't really bothered setting up a bug tracking system for Dovecot: 1) They're all kind of annoying to use. 2) They all require a lot of stuff like PHP, SQL server, etc. which I don't really want to put into dovecot.org. 3) Probably most importantly: If people start reporing bugs in there, I'm pretty much the only person who will ever read them and reply to them. Currently when people report bugs in here, it's quite useful to have other people read them too. They may already know the bug and say they've reported it, they may have an idea what's causing it, they may know a workaround, etc. All in all, moving things to BTS would most likely cause my life to be harder and it might be more difficult to get some bugs fixed. A couple of days ago I started thinking about this and then I figured out a way to solve all of this nicely with a new and great Dovecot based bug tracking system. :) Just so I won't forget it, here's the plan: Dovecot BTS ----------- The preferred way to report bugs is to send them to dovecot-bugs(a)dovecot.org. The only thing it does is prefix the subject line with [BUG #nnn] and forward it to dovecot(a)dovecot.org. Now everyone can reply to it just as it was a normal mailing list mail. As long the subject contains the "[BUG #nnn]" prefix, it's part of the bug. Existing mailing list threads can also be turned into bugs by replying to the thread's root message with To: dovecot-bugs(a)dovecot.org. This again causes the new reply to contain [BUG #nnn] prefix. Then comes the web part. There's no SQL database or anything, everything is stored in a mailbox in the IMAP server. The mailbox contains the whole dovecot(a)dovecot.org archive. Bug metadata such as priority, status, etc. is stored using IMAP ANNOTATE extension, which allows setting key=value pairs to messages. Unfortunately Dovecot doesn't yet support that extension. Bugs' root messages contain the annotations for the whole bug thread. So to get a list of all bugs, the BTS issues an IMAP SEARCH ANNOTATE command to list all messages with some specific "bug=yes" type of annotation. For those messages then it can fetch the subject and whatever else metadata it wants. Newly created bugs don't have annotations though. To fix that, the BTS also uses ANNOTATEMORE (or is it METADATA nowadays?) extension to keep "last seen message in BTS" state in the mailbox's annotations. It then issues a SEARCH SUBJECT "[bug #" command for the new messages and does THREAD command for them to see if they're the bug root, or if they were replies to another message which should be treated as the bug root. When viewing a bug, the bug metadata comes from the annotations. Annotation history could also be kept, possibly as messages in another history mailbox. The messages for a bug can be viewed by issuing a THREAD (REFERENCES) command and showing all the mails that exist under the bug root. So, any volunteers to implement the web part, if I implement the ANNOTATE extension? :) It would actually even be possible to implement multiple frontends. All I need to do is give you access (read-only, or read-write for some) to the bug tracking mailbox, and you can use whatever frontend you wish, even a non-web one!

17 39

[Dovecot] Dovecot LDA issues
by Steven F Siirila 26 Mar '07

26 Mar '07

We've seen two issues come up with Dovecot LDA, both of which have caused us problems: 1) If the user's home directory does not exist, or is not owned by them, deliver fails and causes the mail message to bounce back to the originator. In our environment this happens when our user is moved to another server (where we move their files, but for up to 24 hours afterwards, continue to re-mail their /var/mail INBOX). This no longer works because the user has no home directory, causing deliver to fail with "Permission denied" when attempting to create their home directory for the purposes of creating INBOX index files. 2) If the user is over quota (in their home directory), deliver fails with a temporary error, causing requeues until the user is back under quota (which in our environment could be a long time, days). Since we've never had quotas on the user's INBOX (in /var/mail), this is a problem for us. I'd propose for both of these cases that deliver issue WARNING messages to its logs, and simply not create index files for the INBOX. If the INBOX index files already exist, and the user is over quota in /home, neither deliver nor any other Dovecot process should attempt to update them, and instead issue WARNING messages. This allows the e-mail to be delivered instead of requeued, or worse yet, rejected. Index files are supposed to make things perform better, not worse, in ALL cases. :) -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs(a)umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593

2 3

[Dovecot] deliver: -m, sieve and -n
by Jim Horner 26 Mar '07

26 Mar '07

Hi, I took a stab at editing the wiki ... the changes disappeared? I guess I was overruled. The wiki (http://wiki.dovecot.org/LDA) states -m <mailbox>: Destination mailbox (default is INBOX). If the mailbox doesn't exist, it's created (unless -n is used). If message couldn't be saved to the mailbox for any reason, it's delivered to INBOX instead. I tried to add a little note that the sieve plugin takes precedence. For example if at the end of the a .dovecot.sieve there is a line like: fileinto "CompanyFolders.general"; then the -m <mailbox> is ignored. I am not sure about the use of 'stop'. -n: If the destination mailbox doesn't exist, don't create it. This affects both -m parameter and fileinfo action in Sieve scripts. The fallback is to deliver mail to INBOX. (typo: fileinto not fileinfo) My testing shows that if the mailbox does not exist then the mail is rejected like so: === Your message was automatically rejected by Dovecot Mail Delivery Agent. The following reason was given: Mailbox doesn't exist: mail-lists.debian === I like the wiki's solution better. Jim

2 3

[Dovecot] dovecot authentication & exim in rc27
by Richard P. Welty 26 Mar '07

26 Mar '07

[introduction: new to the list, used dovecot w/exim as MTA in simple ways for 2 years, blah blah blah] i'm trying to get exim to use dovecot auth with a copy of rc27 and am missing something that's probably quite simple. specifically, how does one configure the authenticators in dovecot.conf for rc27? the auth section of the default config file installed in rc27 doesn't entirely look like what i'm seeing in other documentation; instead of auth default { } i'm seeing auth = default followed by lots of standard flags prefixed by auth_, but i don't see how to set up the socket. i have the following; dovecot starts and doesn't complain but it doesn't create the socket either: auth_socket listen { client { path = /var/run/dovecot/auth-client mode = 0660 user = exim group = exim } } any suggestions? thanks, richard

2 1

[Dovecot] anonymous mailing list archive configuration?
by Johannes Berg 25 Mar '07

25 Mar '07

Hi, I'd like to run a mailing list archive via IMAP like for this list but my mails are in maildir and not mbox. It's easy to add a new user that has access to the maildir that mails get stored in, and I can simply link that up to that user's inbox. It's also easy to prevent putting mail into that folder. However, one thing I'm not clear on is how to prevent that user from creating new folders. I don't think I can do that with permissions to the ~/Maildir since that user needs to be able to create files there for indizes etc. Is that possible? Should/can I write a plugin that prevents things? johannes

2 3

[Dovecot] Design docs in wiki
by Timo Sirainen 25 Mar '07

25 Mar '07

If you've ever wondered how Dovecot works internally, I've now written something about it to the wiki. It's probably a bit confusing and there are a lot of things missing, but it's better than nothing. :) http://wiki.dovecot.org/Design

2 1

[Dovecot] 1.0.rc28 / v1.0 plans
by Timo Sirainen 24 Mar '07

24 Mar '07

I'll probably release 1.0.rc28 in a few days. Would be nice to get some testing for it first. http://dovecot.org/nightly/dovecot-latest.tar.gz contains pretty much what it's supposed to be. I've now replied to all the mails I was planning on replying, excluding the few patches that are v1.1 material. If you think I forgot to reply to some mail, please resend it. I think the documentation in Wiki is finally beginning to look pretty good. All the important things are done. The only things in my "would be nice TODO" list are: - Add a new page about index files and their configuration. I'll probably do this before rc28. - PasswordSchemes and Authentication/Mechanisms are pretty heavy reading. Could be made easier to understand. Possibly also create some mechanism-specific pages describing how to configure them in Dovecot and in clients. - Design documents would also be nice, but not very useful for non-programmers and pretty big job to write them I'm planning on adding the Wiki pages to doc/wiki/ in the tarball and changing: - http://wiki.dovecot.org/* links to doc/wiki/*.txt in dovecot-example.conf - doc/variables.txt could be removed and links to it updated to doc/wiki/Variables.txt - doc/auth-protocol.txt is also already in wiki. Maybe create doc/design/ and put the AuthProtocol.txt there and other design wiki pages there as well. As for v1.0, it looks like there aren't many bug reports anymore about rc27. If there are as few for rc28, I'll release v1.0 in about a month. So unless something special happens, I'll fix only the simplest bugs after rc28 and leave the rest to v1.1/v1.0.1. Hmm. Looks like 13.4. is Friday. Perhaps that's a good day for a release. :) Looks like I ended up adding a few more new features to rc28: * deliver + userdb static: Verify the user's existence from passdb, unless allow_all_users=yes * dovecot --exec-mail: Log to configured log files instead of stderr + When copying/syncing a lot of mails, send "* OK Hang in there" replies to client every 15 seconds so it doesn't just timeout the connection. + Added idxview and logview utilities to examine Dovecot's index files + passdb passwd and shadow support blocking=yes setting now also + mbox: If mbox file changes unexpectedly while we're writing to it, log an error. + deliver: Ignore -m "" parameter to make calling it easier. + deliver: Added new -n parameter to disable autocreating mailboxes. It affects both -m parameter and Sieve plugin's fileinto action - auth cache: If unknown user was found from cache, we didn't properly return "unknown user" status, which could have caused problems in deliver. - Index view syncing fixes - rc27 didn't compile with some non-GCC compilers - vpopmail support didn't compile in rc27 - NFS check with chrooting broke home direcotry for the first login - deliver: If user lookup returned "unknown user", it logged "BUG: Unexpected input" - convert plugin didn't convert INBOX

5 11