[CLUE-Tech] IMAP Server Recommendations...

Ryan Kirkpatrick ug at rkirkpat.net
Mon Jul 28 07:16:04 MDT 2003


On Thu, 24 Jul 2003, Jeffery Cann wrote:

> On Thursday 24 July 2003 16:50, Ryan Kirkpatrick wrote:
> >   *) Courier fails this for the same reason, and even the standalone
> >      IMAP server's configuration and init.d scripts are kludge to say the
> >      least.
> 
> In what way do you think they are a kludge?  

	My biggest beef is with the init.d script. Instead of merely
starting and stopping the courier daemon(s), it proceeds to parse the
configuration file into environmental shell variables, and then builds a
very large and confusing command line using these variables. As well,
there is no configuration variable for the location of the user's mail
directory (i.e. ~/Mail), that is hard coded in the init.d
script. Basically, all of this should have been placed in a seperate
script (i.e. /usr/sbin/courier-imapctl), and a few more configuration
options provided.

> > I may be over picky in my needs here, but this does not seem too difficult
> > of a set of requirements. It appears that almost all of the IMAP servers
> > seem to use an overly complex sequence of port listener, authentication
> > daemon, login handler, and actual IMAP server processes, all chained
> > together in a rather complex and commentless init.d script (i.e.
> > courier-imap). 
> 
> Hmm - as a fellow postfix user, I am surprised that you're complaining about a 
> plethora of processes.  Postfix (as described by the author) was built with 
> several separate daemons to increase security.

	I agree that a modular use of processes is a good design
method. My problem is the stringing them together in the init.d script,
and not abstract away so the SysAdmin does not have see them. In the case
of postfix, there is /usr/sbin/postfix, which does all of the dirty work
of starting and managing the processes. The init.d script can then be
quite simple and straight forward. I don't mind complexity, but it needs
to be abstracted away at different levels, otherwise it becomes
unmanagable.

> > and forcing all subfolders to be hidden directories (start with a dot) on
> > the filesystem. 
> 
> The . folders are prescribed by the maildir format.  Go read about it on qmail 
> home page - the author invented this format.  Note that *any* IMAP server (or 
> email client for that matter) which supports maildir format will have .folder 
> names.   My Kmail has it, for example.

	Yea, though BINC IMAP is pushing a new IMAPdir standard that does
have this requirement. They have a good explaination at
http://www.bincimap.org/bincimap-faq.html#q12 of this.

> I would recommend spending some time trying to setup various IMAP servers.  
> You'll know soon enough which ones are truly difficult.  Sometimes, it takes 
> a few hours of research and reading for things to gel.

	I went ahead and tried dovecot (dovecot.procontrol.fi), and it was
quite simple indeed to setup. It too uses a set of processes to do the
different tasks, but like postfix, there is a /usr/sbin/dovecot that does
all the dirty work of starting them up and managing them. As well, the
configuration file is nice and straightforward, and allows everything to
be configured.
	Best of all, while ~/Mail (in my case) is seen as INBOX, all
folders within ~/Mail (i.e. ~/Mail/.Sent) are presented as siblings to
INBOX in any IMAP client. This meets that last requirement I had, ablity
to have sibling folders to INBOX. Additionally, it appears quite fast, and
even Mozilla 1.4 likes it (Moz was crashing with courier). 
	Anyway, at this point I would recommend dovecot to anyone looking
for a good IMAP server. Thanks for the help.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------




More information about the clue-tech mailing list