In general, my answer to questions like this is that freshmeat is your friend. A search for IMAP gives quite a number of results. Freshmeat has a nice filter-by-category function, though. Hitting the filter link next to "Environment :: No Input/Output (Daemon)" gives you 16 projects, #5 of which is called DBMAIL, and seems to be exactly what you're looking for.

As far as the path sepperator thing goes...

1. It shouldn't be a difficult change to make at all. I suspect you wouldn't even have to know C if your source-diving skills are in good shape.
2. What client are your users using? Would it figure it out itself?

Also, many mail folder formats have one file per message... it may not be neccessary to go with a non-standard IMAP server.

Very big ++theorbtwo , I guess neglecting freshmeat was my 1st mistake. I get v.v.disillusioned with sourceforge, in particular the number of projects that look like onetime posters, or are just dead in the water - unmaintained.

Users are in the majority case using Outlook Express IMAP, some are using Outlook which is M$ Small Biz not enterprise so it don't have IMAP (pricks), but it supports Exchange (painful wart on the network). I don't have too many qualms with ppls using things like netscape mail , since they're so few and interestingly enough, rarely need assistance. OSX is a rather different beast, it's Mail client is featured if you're prepared to devise an LDAP database of everything...you'll notice LDAP and ActiveDirectory feature briefly on my homenode. Thankyou again.


I can't believe it's not psellchecked

The problem you're facing is as much political as it is technical, and you're positioning yourself to be the bad guy. You can get out from under by shifting part of the burden onto your users, and enlisting their help. Make the case now that service is going to deteriorate as the organization scales unless people can limit the amount of email they keep on the server, and ask your users what they think a reasonable retention policy might be. You won't get answers from everyone, and some folks will complain, but if you get a couple of good answers, you can always say "we asked, and the answer was X" if people complain later.

You'll still have technical problems to deal with, but setting reasonable limits now might give you some more breathing room.

I keep a lot of old emails just in case I need to refer to them later. I use pine, and I've noticed that it gets slower as my inbox gets bigger. It would be unusable if I kept everything in my inbox. To speed things up I create a new imap folder once a month and move my inbox to it, thus cleaning out my inbox.

Maybe you should encourage your users to do something like that. Even if you go to a different imap implementation, having smaller folders might help keep things quick. You could automate the process with scripts that move the folders at scheduled dates, or with scripts that run periodically and warn you about users with exceptionally large folders.

We certainly encourage users to organise their mail, most do it in folders by 'project of relevance' but I am sympathetic in many regards... my IMAP folder for squid mailing list is monstrous, sometimes the 'all-in-one-place' method has to be traded for clunky performance. I'm mid way through build-configure dance with dbmail1.0 released in december 2002 and if it does what it says , I will be thrilled... moreover, if their proposed features become reality I might even be able to junk an Exchange Server (oh baby!). I am setting aside some time tomorrow to do some logging on the IMAP server regarding how much CPU time is spent by which users, which should give me a shortlist to 'educate-and-enlighten' :) I like the idea of warning about exceptionally large folders, maybe the mail should go to the offending user.


I can't believe it's not psellchecked

What server are you using?
The Cyrus IMAP server stores everything in a Berkeley-DB-Structure, is up to now fast and seems to be, claims to be, scalable and it normaly doesn't make a difference if I search/navigate in a small folder, like a project related one (10-100)*x, or the big one containing automated mail 1000*x.

There is a (commercial) Plugin available for Outlook that improves the IMAP support to a noticable degree, /msg me if you're interested, and I ask our Windows-Client guy what it is.

Concerning notes: If you can circumvent this, do it. It is satisfactory, if it works...yeah, well,... if, and generaly a PITA to work with as an admin (IMVHO).

regards,
tomte

What server? legacy stuff I am afraid, freeware imapd v11.241 on a poor old SGI indy, 180Mhz MIPS R5000, which to its credit has survived remarkably well but my fear that it is nearing the end of its natural life, is shared by the whole team (3 of us!). I asked why it wasn't retired years ago, the answer I got struck warning bells, because when paraphrased it was, 'Security through Obscurity' , more people know how to crack a linux than a irix box. I personally believe this is rubbish, IRIX has not got a fantastic trackrecord in this area, and getting patches and ports in without a licensed cc is ... well don't ask.

Will check out Cyrus, also I've found an exchange server replacment claimant that looks interesting.

You don't know how many people have used PITA in the same sentence as Lotus, I laffed when I read that ++

toaster.
I can't believe it's not psellchecked

I'm going to go even farther afield, and suggest the IMAP server we use at work. It's Windows-based, but it can run on Win2k Pro. Actually it can run on NT, or even 9x, but I wouldn't recommend that. www.mdaemon.com - their 6.70 release just came out the other day. They've licensed Bynari's client plugin, so that Outlook users can use IMAP behind-the-scenes (even if your version of Outlook doesn't support IMAP natively) The product is inexpensive: They have POP or IMAP in the Pro version, they have an IMAP-based web-mail product that supports SSL, and has it's own calendar that will be integrated with Outlook in the next rev, they have a server-based IM system (looking to integrate with Trillian I think.) Inexpensive add-ons: AV product plugin based on Kaspersky, but you can use something else, the Bynari client (Groupware) will be an additional cost when it's release (you can start playing with the betas now if you'd like) The only PITA for me right now - they don't support IMAP SEARCH BODY, which I believe was one of your requirements. I've made a point to get that wish-listed. MDaemon keep messages as RFC-822 text files in server-side directories, one per IMAP folder. So, a server-side search-engine would be a worthwhile project; Perl seems like it would fit the bill. Email me (mfinnigan@telaid.com) if you think you would like to hear more from me on the topic.

'Security through Obscurity' , more people know how to crack a linux than a irix box.

As it stands today, the entire security industry is obscurity. From passwords to cryptography it is all reliant on obscurity. You just need the proper amount of obscurity to minimize the risks for the job at hand.

Not the greatest example, but do a search for department of defense webstar and see what pops up.