I've been doing some research on file locking for mail systems and have noticed in several places mention made to IMAP "[Not needing file locking]".
Any place that says such a thing is uninformed (at best).
Although the IMAP protocol itself has no locking, this says nothing about what actually goes on within the implementation of an IMAP server. There is no magic wand in IMAP that repeals all the locking requires of a mail store which an IMAP server may access.
Indeed, IMAP has several requirement which, while not necessarily requiring locking, are difficult to fufill without locking. In particular, consider the issues discussed in RFCs 2180 and 2683.
If I understand correctly c-client is a library that aides in development of email systems.
Basically, yes.
Is this library used in general distributions of the UW Imap server?
The c-client library is the fundamental platform on which all of UW's IMAP software is built upon. This includes the UW IMAP server, the UW POP3 server, the tmail MDA, the Pine/PC-Pine/WebPine MUA, the mailutil utility, and a fair amount of other software.
c-client is also used in numerous third-party applications. I don't know if anyone has an authoritative list of them; I don't, and I wrote c-client.
I guess what I'm asking is does the information listed regarding c-client have any impact on an installation of IMAP as already developed and distributed, or is it a concern for those developing additional software?
The information regarding c-client's locking is only of interest to non-c-client applications which wish to access local files concurrently with c-client. It does not apply to IMAP access.
Here is why I'm concerned about file locking. Consider a system that has one or several IMAP Servers, three or more sendmail servers and at least one pop server that must all access the same data server. This data [snip...asking if NFS is the solution]
As you noted, everybody says "do not implement email over NFS." There is a reason for this.
The fundamental architecture of your system is wrong. It presumes that IMAP, SMTP, and POP are CPU-intensive services that require many separate CPUs but can share a single disk facility via a network.
The exact opposite of this presumption is the case: these are all extremely I/O intensive services that require many separate I/O ports.
An IMAP server system may be slower than cold molasses in January, but when you look at the load it isn't high at all. Instead, it's doing I/O just as far as it can.
To a lesser extent, email server systems are also memory-hungry. The more memory, the better; this will not only feed individual IMAP server processes' cache but also feed the host system's I/O buffer cache. A 300MHz 486 with 4GB of RAM will perform better as an IMAP server than a 2500MHz Pentium 4 with 512MB.
What we do -- and many other sites have done -- is split the user space so that every user has his own assigned IMAP/POP server (IMAP and POP co-exist on the same server). Each server has its own private disk (this does not preclude RAID or EMC) with its portion of the user space.
These systems are in their own DNS zone (at UW, deskmail.washington.edu), in which every user and his assigned server are listed. For example, mrc's IMAP server at UW is always mrc.deskmail.washington.edu. We have tools to move users while they are not online. Today, mrc.deskmail happens to be a system called mailer52; tomorrow it may be a different system, and I never care.
Each of the IMAP/POP servers has an incoming SMTP server that only does delivery; it could run LMTP just as well. These SMTP servers refuse connections from outside. The real SMTP servers are on separate systems, and handle both routing to the appropriate IMAP/POP server and spam filtering.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
