I posted the message below to the imap list at U Washington, to see if I could get any comments. I didn't get much of a response, so I thought I would try here as well. Thank you for any comments you might have. ---------- Forwarded message ---------- Date: Tue, 9 May 2000 17:12:34 -0500 (EST) From: Chris Dent <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: potentially touchy topic of courier imap v imap clients I realize this is probably a topic which has been beaten to death, but my review of the list archives did not return a great deal, so I thought I would poke around and see what kind of responses I was able to get. Feel free to respond to me directly or to the list, I can summarize if necessary. My work environment is a smallish ISP with approximately 10,000 email accounts. Right now the vast majority of those users have their mail housed on pop servers running qmail and qmail-pop3d. We went with qmail because of several reasons: we had significant success with it on our relays we could use Maildir on the POP machine, which meant that management of mail messages, quota, user management, logging, and a whole slew of stuff was going to be very easy to customize, tweak, make just so and generally be good. it's all fast and small Soon we will be moving from our pop only or shell based mail only mail environment to something we are calling mailstore, which will be a place where users keep their mail that has multiple access modes (initially just POP, IMAP and IMAP with something like stunnel, but growing to Webmail and probably IMAP access from the shell machine). We would like to avoid having to migrate people's mail collections to a new format, to maintain the advantages that Maildir gives us and to continue using the considerable collection of custom code we have put together to manage the machines. Which says to me that we should use an IMAP server which supports Maildir. I'm not sure of all the options (input is most welcome) but those I've thought about so far have issues: - UW with Maildir support, I've been told, still suffers from the memory footprint problems that the c-client programs suffer - Courier-IMAP, I've beent old (again), suffers from signicant "doesn't play well with clients" issues and suffers from an author that doesn't want to play with others either. - Cyrus present a lot of advantages and we can make it interoperate with whatever mail server we choose, but we will need to migrate from the existing Maildir structure and tools which manage users will need to be changed. I want to use Courier-IMAP because I agree with the spirit of it's design--small, modular, extensible through pipelines--but because this is an ISP environment we have next to no control over client use and must, for the sake of customer satisfaction and technical support costs, minimize the trouble that an IMAP server will cause. Are the client interaction problems in Courier-IMAP that significant? If so, does anyone care to guess how hard it would be for a motivated person to code around them? Sam, if you are listening, what are your comments or suggestions? My feeling on this whole issue are nicely captured by Postel in RFC 760 section 3.2: The implementation of a protocol must be robust. Each implementation must expect to interoperate with others created by different individuals. While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior. That is, it should be careful to send well-formed datagrams, but should accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear). Which, unfortunately, people get very uptight about. (I know I've been there).
