February 2007 - dovecot

[Dovecot] pop3 via tls
by jepoy 13 Feb '07

13 Feb '07

hi guys, i want to try pop3 using tls, just like smtp. is it possible ? i want to first create a secure tunnel before donwloading the mails. tnx -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 1

[Dovecot] Problems with HUP'ing dovecot
by Javier Henderson 13 Feb '07

13 Feb '07

Hi, I'm running dovecot 1.0.rc7 on FreeBSD 6.1, so far with great success. Earlier today I tried to HUP the main process, the following was logged: dovecot: Feb 12 15:10:19 Warning: SIGHUP received - reloading configuration dovecot: Feb 12 15:10:19 Panic: file ioloop-poll.c: line 105 (io_loop_handle_remove): assertion failed: (index >= 0 && (unsigned int) index < ctx->fds_count) Of possible interest: just prior to issuing the HUP I had edited the / etc/resolv.conf file to take out the first entry since that particular DNS server went off line. I noticed that login attempts to the POP and IMAP services were timing out and that's when I sent the HUP to dovecot. Any ideas? Thanks, -jav

2 1

[Dovecot] mail_location and storage type
by Jürgen Herz 13 Feb '07

13 Feb '07

Hi, I was setting up a new system for testing Dovecot 1.0. My old one is using 0.99 and was set up quite a time ago, so I had to consult the documentation. I needed several attempts until it worked and that was because the designated maildir directory /server/mail/jrg/Maildir was completely empty. Upon login the server exited and wrote the following to the log: POP3(jrg): Ambiguous mail location setting, don't know what to do with it: /server/mail/jrg/Maildir (try prefixing it with mbox: or maildir:) POP3(jrg): Failed to create storage with data: /server/mail/jrg/Maildir That thing was the main cause of my confusion since the config wasn't ambiguous at all at already contained a prefix: mail_location = maildir:/server/mail/%u/Maildir The wiki article MailLocation doesn't contain any hint maildirs have to contain at least a cur subdirectory. That information I eventually got from mail-storages.txt - that file must be one for which the wiki isn't an alternative. So what is this mail about? 1. The log message is wrong or at least missleading. Would be fine if it could get improved. 2. Is there any reason at all to have a storage prefix but still require some special format for the directory in order to recognize it? 3. At least if the behaviour will stay, shouldn't the text from mail-storages.txt converted to a wiki article or incorporated into MailLocation? Regards, Juergen

2 3

[Dovecot] Compiler warnings
by Stephen Lee 12 Feb '07

12 Feb '07

Hi, I'm trying to install Dovecot 1.0RC22 on an old Trustix 1.5 box and am getting the compiler warnings: quota-storage.c:275: warning: pointer of type `void *' used in arithmetic convert-storage.c:50: warning: pointer of type `void *' used in arithmetic acl-backend-vfile.c:212: warning: pointer of type `void *' used in arithmetic There are many more of these pointer warnings in the various modules when compiling. Is this a problem? Thanks, Stephen

2 1

[Dovecot] Differences between IDLE when Maildir vs. wel the "mail" folder is used
by Philip Van Hoof 12 Feb '07

12 Feb '07

Are there any differences with how both IDLE and "UID FETCH n:n+x (FLAGS UID...)" are handled when Dovecot is using a "mail" vs. a "Maildir" user? I have recently implemented support for IDLE (Push E-mail) in a client infrastructure that I'm building. I haven't in depth checked out what the problem might be, but when Dovecot was using the "mail" dir in $HOME something about the implementation wasn't working. When I switched to "Maildir" everything worked. I only tested to the point of seeing the "* EXISTS n" response during the idle. I saw this response. It's for example possible that the n is wrong or that a bit later the "UID FETCH ..." ain't returning the right information. It's also possible that my implementation is wrong (of course) and I haven't yet had the time to really figure out what goes wrong. I did so far, however, test with Cyrus, Exchange, Courier and Isode's M-Box. All these tests where successful. SO if it indeed is a discrepancy in my implementation .. it's going to be something very specialised or specific I fear :-) I also setup testing infrastructure http://tinymail.org/trac/tinymail/wiki/TestImapServers Also take a careful look at this manual test. "tnytest" is a user on imap2.tinymail.org that uses Maildir. The "tnytest2" user doesn't have a Maildir configured. By that I mean that "Dovecot" has created the folder for E-mail using whatever it uses by default. Dovecot's IDLE (the EXISTS) responses also take a lot longer on tnytest2 than on tnytest. Another question. Why not simply "always" use the Maildir solution if that one works better? ;-) (really, honest question. Hehe). Take a look at the "UID FETCH" response: It's incorrect on tnytest2. The first attempt I asked for 1:1 and I got none. The second I asked for 1:4 and I got 3 of them, while IDLE clearly stated that there where 4 messages available. In reality 4 where indeed available (or copied in total). Well, I'm not saying something is or isn't wrong, just wondering and testing a little bit and seeing some strange results... Feel free to use imap2.tinymail.org for testing. And if you need root on that virtual machine, so that you can install a new version, go ahead. On http://imap2.tinymail.org you van find things like version information (it's a CVS snapshot). pvanhoof@lort:~$ telnet imap2.tinymail.org Trying 86.39.154.77... telnet: Unable to connect to remote host: Connection refused pvanhoof@lort:~$ telnet imap2.tinymail.org 143 Trying 86.39.154.77... Connected to imap2.tinymail.org. Escape character is '^]'. * OK Dovecot ready. ao1 login tnytest tnytest ao1 OK Logged in. a01 select INBOX * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 1 EXISTS * 0 RECENT * OK [UIDVALIDITY 1171049606] UIDs valid * OK [UIDNEXT 2] Predicted next UID a01 OK [READ-WRITE] Select completed. a04 IDLE + idling * 2 EXISTS DONE a04 OK Idle completed. UID FETCH 1:2 (FLAGS UID) * 1 FETCH (FLAGS (\Seen) UID 1) * 2 FETCH (FLAGS (\Seen) UID 2) UID OK Fetch completed. ^] telnet> quit Connection closed. pvanhoof@lort:~$ telnet imap2.tinymail.org 143 Trying 86.39.154.77... Connected to imap2.tinymail.org. Escape character is '^]'. * OK Dovecot ready. a01 login tnytest2 tnytest a01 OK Logged in. a01 select INBOX * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 0 EXISTS * 0 RECENT * OK [UIDVALIDITY 1171107413] UIDs valid * OK [UIDNEXT 1] Predicted next UID a01 OK [READ-WRITE] Select completed. a04 IDLE + idling * 1 EXISTS DONE a04 OK Idle completed. a05 UID FETCH 1:1 (FLAGS UID) a05 OK Fetch completed. a04 IDLE + idling * 4 EXISTS DONE a04 OK Idle completed. a06 UID FETCH 1:4 (FLAGS UID) * 1 FETCH (FLAGS (\Seen) UID 2) * 2 FETCH (FLAGS (\Seen) UID 3) * 3 FETCH (FLAGS (\Seen) UID 4) a06 OK Fetch completed. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog

2 1

[Dovecot] PLAIN-MD5 password scheme with salt?
by Steffen Weber 12 Feb '07

12 Feb '07

Hello! I'm storing passwords as MD5 hashes in a MySQL database and have specified "default_pass_scheme = PLAIN-MD5" in dovecot-sql.conf. Can Dovecot append or prepend a salt to a password before hashing them? Because without salt the plaintext passwords can be restored from the MD5 hashes using rainbow tables. Greetings Steffen Weber

2 3

[Dovecot] mbox and dual-use folders?
by John Robinson 12 Feb '07

12 Feb '07

Feature request: please can we have support for messages stored in mbox files, but folders containing both messages and folders. I think this could be done for a folder called e.g. dovecot-list by having an mbox file called dovecot-list and a directory called dovecot-list.folder (or whatever, says he handwaving away name clashes which can be worked around like they are in maildirs). This may be a subset or variant of http://wiki.dovecot.org/FeatMboxMaildir Cheers, John.

2 1

[Dovecot] IMAP/POP3 server with proxy feature
by Jasper Bryant-Greene 12 Feb '07

12 Feb '07

We are currently evaluating the migration from a proprietary, legacy mail server onto Dovecot for 20,000+ virtual domains. This is a big job and we intend to do it by initially proxying connections through to the legacy server, and moving customers over in batches by turning off the proxy feature for them. In the manual it states "This model is still a bit unfinished in current code" [1]. What is needed to get this production-quality? I'm happy to help out with any work required. [1] http://wiki.dovecot.org/ImapProxy -- Jasper Bryant-Greene Director Album Limited jasper(a)albumltd.co.nz +64 21 708 334 / 0800 425 286 http://www.albumltd.co.nz/

5 4

Re: [Dovecot] Reproducible duplicate messages bug with Mail.app+Dovecot / may imap bug from mail apple
by Andrew Moran 12 Feb '07

12 Feb '07

On Feb 10, 2007, at 4:30 PM, Robert Schetterer wrote: > > Hi Andrew, > > i investigated the imap bugs from apple mail app with google > trough the years, and i saw there was no version without a bug with > imap, so i speculate its not dovecot what does something wrong here > Oh I have no doubt that Apple's Mail.app is very buggy, but I submit a bug to them which only happens with dovecot IMAP server, I'm sure they are going to be quick to blame dovecot rather than investigate it fully. This is why I was hoping that someone on this list who has Mail.app and Dovecot can (a) verify that it is happening for them (it's 100% reproducible to me) and (b) figure out exactly what's going on, at least to the point of knowing it's Mail.app's fault and not something Dovecot is doing, or a combination of both (such as dovecot doing something other IMAP servers don't and Mail.app misinterpreting it). --Andy

3 2

[Dovecot] Shared folders plans for the future
by Timo Sirainen 11 Feb '07

11 Feb '07

So while driving for several hours in my car recently and having nothing else to do, I started thinking how they could be done. I think the "public folders" configuration will stay as it is now. Does it really even need anything else? The problematic case is how the users can share their mailboxes to other users. There are two problems related to it: 1) How to get (quickly) a list of another user's mailboxes that I have access to? 2) How to get quickly a list of all users who have mailboxes that I have access to? The 1) problem is easier to solve. Create a directory listing all the mailboxes that are shared to at least someone (have ACLs set). It could be configured like: namespace shared { # IMAP namespace prefix, %u expands to shared user prefix = user/%u/ # Directory containing symlinks to user's all shared mailboxes share_dir = ~/Maildir/shared # Where to store indexes for other users' accessed mailboxes index_dir = ~/Maildir/others-indexes } The ~/Maildir/shared directory could then contain symlinks to all the shared mailboxes. The directory list could probably be in Maildir++ layout even though the symlinks would point to mboxes. This requires adding code that can handle mixed maildir/mbox directories, but it'll come anyway.. The 2) problem is more difficult. There are 3 choices: a) Use a shared database file. lib-dict could be used for this, so the database could be in SQL or in a berkeley db file. The downside to this is that the file needs to be readable and writable to everyone, so if users have shell access the users could break the file. They dictionary would contain data in format "<destination_user>/<sharing_user>" = 1 and "<destination_group>/<sharing_user>" = 1, ie. the value would be ignored and only the existence of the keys would be important. Then iterating through "<my_username>/*" and "<all_my_groups>/*" would list the users who probably have mailboxes where I have access to. b) Use a directories with sticky bit set. Well, basically the same idea as in a), except filesystem would be used. Actually perhaps this could be made another lib-dict backend.. c) Brute force: Just assume everyone potentially have shared mailboxes. Get the list of users by readdir()ing through /home (configurable). I guess each of these could be made an option.. So something like: namespace shared { .. # a) shared_dict = db:/var/lib/dovecot/shared-mailboxes.db # b) shared_dict = dir:/var/lib/dovecot/shared-mailboxes # c) shared_dict = bruteforce:/home } I'm currently also implementing a "mailbox list index", which contains a list of all the user's mailboxes and some useful metadata for them, such as number of messages and so on. So that STATUS command wouldn't need to open the mailbox index files if they haven't changed. The mailbox list index updating is normally done when directory's mtime has changed. For list of shared users that would also work in 2b) and 2c) cases, but for 2a) I'd either have to always sync everything or alternatively add some sequence/<dest_user/group>=# value which is grown for each update, and the syncing is done only when the sequence is updated.

6 17