Forum OpenACS Q&A: The webmail problem

Hi Talli,

a) We run IMP 3.1 with ACS 3.5 for over a year know, tightly integrated into a portlet.
b) Yes, not good enough for running an Intranet Webmail System for more than 10K users.
c) No, and never was. Integration is the way to go, especially as there are excellent systems out there. You might want to bother about having not the same look and feel, but seriously, users don't bother.
d) dunno
e) I'd request nothing that can be handled better by third party applications. This means, leave IMAP, Sendmail and POP server out of the Scope. Take a look at IMP or Squirrelmail. Look at fastmail.fm for enhanced features. <sarcasm>Take a lot of work and even more time to reprogramm theses things in OpenACS and start wondering afterwards, why you did it.</sarcasm>

Sorry to be sarcastic here, but the problem has come up a multiple times and so far nothing has come up, for a very good reason. Creating a good webmail system is complex and takes a lot of effort. Effort, this community should not try to put it's resources into at the moment. Interfacing the basics of a webmail system is easy, relatively speaking. People don't bother switching to a different system. They don't even bother to have to signone twice (though we try to get around this). As long as it works, is untuitive to use and looks sleek, they are happy. At least our experience so far.

That said, setting up IMP, Cyrus, CyrusSASL, Postfix, OpenLDAP and integration into AOLserver is a PITA. One we did not even bother to write a documentation for so far (otherwise I'd have said right in the beginning, here is the URL, that's how we did it, go figure out for yourself). Once we have it, I'll announce, how long will it take, I don't know. How long will it take an average person to setup: 3 days. Maybe more. Or less, if you start without RPM's, take bleeding edge software and pray it works together.

LDAP is a crucial part into integration in general, though you can play around it for sure (or keep databases in sync as we do with Jabber). Therefore we look forward to Collaboraid's effort in this matter, as it will allow us to integrate even more different systems that clients happen to use (Next on our target list is Lotus Notes, probably).

I played with the webmail package in December, and it's not great, but it's not too bad either. With some guidance, he or another student or novice could probably make it a lot better.

I made some improvements to webmail, and I should probably stick the result in CVS under contrib.

I don't know if ns_imap is production-quality, but it was pretty simple to work with, and it worked for me to check my mail.

I undoubtedly think, however, that using IMAP is the way to go. We don't want to make our own mail storage in the DB, the way Jin did with the old webmail package. Let an IMAP server deal with that, and we'll just integrate with that IMAP server. Everybody already has an IMAP server anyway.

Then if you want to reuse an email as a knowledge object, say, we could just offer a "post to KM" link, which would copy the content. The same thing could be done with forums and other content, for that matter.

/Lars

As owner of ns_imap i can say that it in production-quality for about 90-99%. There are some issues with fatal error handling because of the way UW IMAP c-client handles them, but they are very rare. We use it our Webmail based on this module for almost year now without any problems.
More complete Webmail solution is now available in opensource package(ftp://ftp.crystalballinc.com/pub/vlad/oss2.tar.gz) and it does many features of IMP, not everything because we did not need all of them.
Before it we used NeoMail, IMP, SquirrelMail and others, but we wanted same environment(including GUI) where all tools can be easily connected to each other, reuse same database and data, easily configured and maintained. If everything runs in AOLserver it may be pretty easy. Supporting apache/php and other tools can be easy too, but they are additional components.

There is one more product which looks interesting, dbMail(www.dbmail.org), they store email in the database and building webmail client is just writing/reading from database, they have couple webmail clients, writing in OACS may be very easy task.

I would not expect aolserver/php to be well tested, let alone optimized. Why would someone use php when tcl is right there?

IMP works well in our environment (http://web.brandeis.edu/pages/view/Network/EmailArchitecture).

IMP talking to UW IMAPd or any other server that needs to fork a new heavyweight process per connection can suck. IMP flaps a new process for EVERY OPERATION, which isn't really how IMAP is supposed to work. ImapProxy (http://www.horde.org/imapproxy/) is intended to address this, but I don't trust it yet. Large mbox-formatted mailboxes suck in general. With UW IMAP, read drivers.txt and use mbx format. Cyrus and Maildir have their fans, too. Exchange tends to do reasonably well because it's multithreaded.