As of 2003, UW IMAP was among the three most popular free software IMAP server packages, the other two being Cyrus IMAP and Courier IMAP.[11][12][13] As of 2005, by which point its codebase had undergone extensive rewriting,[6] it was among the top two, the other being Cyrus IMAP.[14][15]
In May 2008, the University of Washington terminated development of UW IMAP.[2]
On 4 August 2008, staff at the University of Washington who had been involved in developing UW IMAP, Pine, and Alpine,[citation needed] announced that they would "shift our effort from direct development into more of a consultation and coordination role to help integrate contributions from the community,"[16] in the wake of layoffs at the University of Washington's technology division.[17]
c. January - August 2009, the maintainers of Debian GNU/Linux, a major downstream distributor of UW IMAP, began to retire their UW IMAP packages.[18][19]
In September 2009,[citation needed] Mark Crispin, the principal author of UW IMAP, announced a fork called Panda IMAP.[2] Crispin passed away in late 2012.[20]
At least one UW IMAP enthusiast maintains a public source code repository containing the UW IMAP and Panda IMAP commit history from the start of the project until Crispin's final release.[21]
Praise and criticism
For much of the 2000s, UW IMAP was considered to be a good choice due to its ready availability, its inclusion in all major Linux distributions, its support for both POP and IMAP, and its ease of installation.[22][14][23] It also received praise for its ease of administration and for its compatibility with longstanding mailbox formats,[7] and for and its small size and simplicity.[24]
Unlike later IMAP servers, UW IMAP coupled IMAP user accounts to user accounts on the server's underlying operating system.[25][26] This feature, together with UW IMAP's default use of monolithic mailbox files, was intended to ensure compatibility with legacy operating systems and email management practices,[citation needed] but drew criticism from some commentators.[27][28] In particular, Sam Varshavchik, developer of the competing Courier IMAP server, suggested that Crispin's decision not to add support for maildir (a popular non-monolithic mailbox format) to UW IMAP may have stemmed from lingering resentment over an earlier disagreement that Crispin had had with maildir's designer, Daniel J. Bernstein.[29] Crispin's insistence upon retaining UW IMAP's support for flat files as mail stores was criticised, by the maintainers of the competing Citadel IMAP server, for causing otherwise unnecessary complexity in the IMAP protocol.[30]
Additionally, Varshavchik noted that despite Crispin's insistence that other IMAP servers comply with the IMAP specifications, the UW IMAP server and its IMAP client counterpart, Pine, used a private IMAP extension that was not documented in that specification.[9] UW IMAP was also criticised for its susceptibility to buffer overflows and for its lack of privilege separation relative to its competitors Cyrus and Courier,[24] As of 2007, computer programs existed that were capable of exploiting security vulnerabilities in un-patched or improperly-configured UW IMAP installations.[31] and for its unreliable SSL support.[32]
Components and features
UW IMAP was designed to be compatible with existing legacy mail stores and systems, and to be "plug-and-play" installable without requiring any site-specific configuration.[citation needed]
As of 2005, UW IMAP's codebase consisted of 135,000 lines of code, of which the IMAP server itself comprised 4,000 lines and c-client comprised the rest.[6]
Extensibility and maildir support
UW IMAP does not officially support the maildir format.[34] However, UW IMAP can be patched to support other formats, such as maildir.[34] Gluelogic offers a patch to support maildirs in Pine.[35][third-party source needed] The patched Pine instance can then be used to compile UW IMAP with nominal maildir support.[citation needed] However, this yields a buggy server that will not correctly distinguish between Unseen and Recent messages.[citation needed] A patch is available for Alpine that can be used similarly, but with fewer drawbacks.[36][third-party source needed]
^ abcd"Panda IMAP home page". Archived from the original on 2012-07-16. Retrieved 2008-09-23. Panda IMAP forked from UW IMAP 2007b when development of UW IMAP was terminated in May 2008. Since then, the University of Washington has made only made minor support changes to UW IMAP (UW IMAP 2007f) for some (but not all) critical problems. All of the UW IMAP 2007f changes, or better, are in Panda IMAP. Unlike UW IMAP, Panda IMAP fully passes all of the IMAP Server Compliancy Status test suite. Panda IMAP is one of one three servers that do; the others being Dovecot and SurgeMail. The current version of Panda IMAP is imap-2010... Panda IMAP is available by donation. Please contact us for further details via email to the panda.com postmaster... We do not offer support for UW IMAP or Alpine. Both are dead projects. It is doubtful that UW will ever make any further updates to either.{{cite web}}: External link in |quote= (help)
^ ab"IMAP Information Center". University of Washington. July 23, 2009. Retrieved 2018-11-04. The University of Washington licenses the source code of the UW IMAP toolkit, imap-2006 and later, under the Apache License, Version 2.0. The UW IMAP tookit includes the following:
c‑client library: an API (application programming interface) used to build email clients and servers, including support for IMAP, POP3, SMTP and NNTP protocols and for local mailbox file access on Unix and Windows
UW's POP2 (ipop2d), POP3 (ipop3d) and IMAP4rev1 (imapd) servers
mailutil: a utility program which helps manage email mailboxes (both local and IMAP/POP3/NNTP)
dmail: an MDA (Mail Delivery Agent) for use with procmail
tmail: an MDA for use with the system mailer (e.g. sendmail, postfix, etc.)
^ abChristenson 2003, p. 110: "UW IMAP is the reference implementation of the IMAP protocol. It can flexibly be adapted toa wide variety of message store formats, although most often it uses a slightly modified edition of the 7th Edition folder format. For smaller servers, UW IMAP performs adequately, but it lacks some of the feature sets of other IMAP systems. Due to its relatively poor performance characteristics, this package is rarely used in demanding environments."
^ abGareiss, Robin (Feb 4, 2010). "UC and Open Source: Finding the Magic LAMP". Network World. What is the LAMP stack of [Unified Communications]? ... Nemertes defines UC systems as providing at a minimum VOIP, Unified Messaging, IM/presence, and conferencing (audio, video, web); additional features may include contact contact functionality, mobile clients, integration with room-based video and telepresence systems, and integration with social computing platforms. Let's look at open source options in the core categories. ... I would be for IMAP, specifically the UW IMAP reference implementation of the IMAP protocols, or the Panda IMAP fork off that tree.
^ abcdefgGolubitsky 2005, p. 12: "UW-IMAP is written and maintained at the University of Washington by Mark Crispin, the author of the original IMAP RFC. The purpose of this package is to provide a simple and flexible drop-in IMAP server for multi-user systems. The package uses the assumption that IMAP will be one of many login methods through which remote users can access the system. In particular, the functional differences between IMAP access and a shell access method such as SSH should be only that IMAP access is optimized for mail reading. Restricting IMAP access beyond the access afforded to a shell user is not a design goal. The UW-IMAP server has been under active development since 1988, though the entire codebase has been rewritten several times since then. The current code is considered to go back only as far as the 2000 imap-2000 release. Looking further back, I find a code overlap of approximately 20% between imap-2004c1 (the most recent version as of this writing) and the 1996 imap-4 release, and no overlap between imap-2004c1 and any release prior to imap-4. The current codebase contains 135,000 lines of code and 40,000 lines of other files. Of this code, the IMAP server itself comprises only 4,000 lines, while the remainder of the code consists of an internal (compiled-in) library called c-client. This library is also the backend for the Pine e-mail client. Compiling imapd provides a single binary with a single purpose. An external program such as inetd must be used to listen on the appropriate IMAP ports. When a connection is made, an imapd process is
spawned, handles that single connection, then terminates. Since UW imapd’s place in the system is simple, the amount of code needed for its implementation is reduced. The tradeoff is increased dependencies on other programs to perform core functions, most notably mail delivery and port listening. The imapd program also requires no configuration file – configuration options are to be selected at compile time. One more notable feature of UW-IMAP is that it is agnostic about mailbox formats. By default, the UNIX UW installation is compiled with support for mbox, mbx, mx, mh, tenex, mtx, mmdf, and phile mailbox types. This support is provided by means of mailbox drivers. Internal logic is used to guess the type of a mailbox, and then execution is passed off to the appropriate driver."
^ abcKoka & Lipasti 2004, p. 2: "The University of Washington IMAP server is an open source reference implementation of IMAP written by Mark Crispin, the inventor of IMAP. It is popular for its ease of administration, flexibility and compatibility with existing mailbox formats."
^ abBlum 2001, p. 468: "The most common POP3 and IMAP package used on the Unix platform was developed at the University of Washington. Although the software package is called IMAP, it includes a POP3 server as well as an IMAP4rev1 server. ... Many Linux distributions already come with a UW IMAP binary package. You can choose to install UW IMAP from the distribution that came with your Unix system, or you can download the current source code file and build it yourself."
^ abMullet & Mullet 2000, pp. 205–206: "The University of Washington IMAP server (UW IMAP) is an IMAP server that uses inetd or a similar Internet superdaemon to provide users IMAP access to a mailstore. Usually when people refer to UW IMAP, they're referring specifically to the IMAP daemon component of the IMAP4rev1/C-Client Development Environment. The development environment bundle includes an IMAP test utility called mtest and an IMAP API library called C-Client. It also includes a couple of POP servers that offer proxy access to your IMAP server through POP, for an easier transition from legacy POP systems. The UW IMAP daemon itself is bundled with the popular PINE mail client and included with many versions of the Linux operating system. Available in a separate package are the UW IMAP Utilities, a set of tools for managing an IMAP server. The UW IMAP utilities were developed by the University of Washington and based on the C-Client API... The UW IMAP feature set and design make it well suited for an existing system that wants to add IMAP. It can be used out of the box on any Unix shell user system, without modifications or special infrastructure. It can also be used for a dedicated IMAP server; however, you may need to start thinking about modifying it if you plan on scaling it to very large user communities. How many IMAP users a particular system will support depends greatly on the hardware and the operating system. UW IMAP does not need much in the way of system resources, but it does require adequate per-process memory and disk bandwidth. You can have more UW IMAP users on a system than Unix shell users, but within reason; if a particular machine won't handle 5,000 Unix shell users well, don't expect it to handle 100,000 UW IMAP users well. In general, scaling works better with a cluster of small systems than with a gigantic monolith. A fast CPU is much less important than lots of disk bandwidth... The University of Washington serves its community of 80,000 users with a cluster of small, inexpensive IMAP servers, each of which is assigned a portion of the overall user space. The IMAP servers are in a special DNS domain that is tied to UW's account system. User fred may be moved to a different IMAP server, but fred.deskmail.washington.edu always points to his assigned IMAP server. Most Unix variants, particularly the open source varieties, typically come with an unlabeled IMAP daemon (imapd). Chances are that this daemon is the UW IMAP server. Probably the most interesting and significant fact about the UW IMAP server is that it was written by Mark Crispin, the progenitor of IMAP itself. It's fair to say that Crispin is to the IMAP community as Linus Torvalds is to the Linux community. Crispin invented IMAP entirely on his own, when he was asked to build a distributed mail system with no guidance. He wrote the original IMAP server from scratch in DEC-20 assembly language in 1985. IMAP's early design was strongly influenced by the DEC-20 mail system, of which Crispin was also the primary developer and maintainer. The first nine years of IMAP's development can be attributed entirely to Crispin."
^Bauer 2003: "The three most popular open-source IMAP servers are University of Washington IMAP (UW IMAP), Cyrus IMAP from Carnegie Mellon University and Courier IMAP from Inter7 Internet Technologies."
^Christenson 2003, p. 5: "The three most common Open Source IMAP servers are Cyrus [CYR], UW-IMAP [UWI], and the Courier IMAP [COU] packages."
^Christenson 2003, p. 108: "Three popular Open Source IMAP server solutions exist: the University of Washington (UW), Cyrus, and Courier IMAP solutions. Each has its own niche and characteristics that makes [sic] it the best choice under certain circumstances."
^ abBautts, Dawson & Purdy 2005, p. 259: "[The] ease of configuration and installation of UW IMAP often makes it more appealing [than other IMAP servers]. In this chapter, we'll primarily focus on the two most common IMAP servers: UW IMAP, because of its popularity and ease of installation, and Cyrus IMAP, because of its additional security features."
^Golubitsky 2005, p. 10: "[There] are three freely-available open source IMAP servers which share the bulk of the market – UW-IMAP, Cyrus, and Courier-IMAP."
^Smith 2003, p. 527: "Because it's readily available, ships with all major Linux distributions, and supports both POP and IMAP, this section [of the book] describes the installation and configuration of UW IMAP."
^Soyinka 2008, pp. 468–469: "[We] cover the installation and configuration of the University of Washington (UW) IMAP server, which includes a POP server hook. This particular mail server has been available for many years. The installation process is also easy. For a small to medium-sized user base (up to a few hundred user), it should work well. If you're interested in a higher-volume mail server for IMAP, consider the Cyrus or Courier IMAP server. Both offer impressive scaling options; however, they come at the expense of needing a slightly more complex installation and configuration procedure... Most Linux distributions have prepackaged binaries for UW-IMAP in the distro's repositories. For example, UW-IMAP can be installed in Fedora by using Yum..."
^ abGolubitsky 2005, pp. 13, 20: "UW-IMAP’s primary benefit is that it is the smallest and simplest of the three servers, both in terms of code size and major functions provided, and in that it provides a smaller set of IMAP API methods than the other servers. (The small API set may be in part due to the fact that the UW author wrote the IMAP RFC, which defines the minimal allowable set of API functions.) However, the drawbacks are many, and seem to go down to the design philosophy of the package. The code is not at all modular... and since most of the functionality is provided by a c-client library which is also the backend for the mail client Pine, it is possible that functionality may be compiled in to the UW server which is really only necessary or desirable for client operation... Despite UW-IMAP’s history of buffer overflows, instances of string functions which do not perform length-checking (such as sprintf) are still plentiful within the code... [According] to the attackability metric used here, Courier is the least vulnerable of the servers, while UW and Cyrus score similarly... Despite the large size of the Cyrus codebase, its attackability is similar to that of UW-IMAP, indicating that Cyrus has good privilege separation while UW-IMAP does not."
^Glennon 2000, p. 385: "Managing a UW-style server is more tightly linked to the operating system on which it is running. In other words, if you run the UW-IMAP server on a UNIX system, be prepared to administer UNIX accounts as well as aspects of the IMAP service... If, on the other hand, you choose Cyrus IMAP as your solution, you may never [need to] create or manage any UNIX user accounts. However, your knowledge of the IMAP implementation and the utilities to maintain it will need to be more extensive."
^ abSmith 2011, p. 382: "Despite its name, the University of Washington IMAP server ... supports POP2, POP3, and IMAP. The POP servers use the IMAP server behind the scenes. This set of servers usually ships in a package called imap or uw-imapd. The IMAP server stores user mail folders in users' home directories, which can be awkward if users also log in to their accounts and store nonmail files there."
^Bauer 2003: "[Compared to Cyrus IMAP and Courier IMAP,] UW IMAP is the least flexible, as it supports only local-user-account mail file delivery; each local user's inbox is stored as a single flat file, /var/mail/myusername. This has two disadvantages: each mail user also must be a system user, and only one process may write to any given user's inbox at any given time, potentially resulting in file-locking complications."
^Elprin & Parno 2003: "This paper compares the performance of three different IMAP servers, each of which uses a different storage mechanism: Cyrus uses a database built on BerkeleyDB, Courier-IMAP uses maildirs, and UW-IMAP uses mbox files. We also use a mySQL database to simulate a relational-database-driven IMAP server. We find that Cyrus and mySQL outperform UW and Courier in most tests, often dramatically beating Courier. Cyrus is particularly efficient at scan operations such as retrieving headers, and it also does particularly well on searches on header fields. UW and Cyrus perform similarly on full-text searches, although Cyrus seems to scale slightly better as the size of the mailbox grows. mySQL excels at full-text searches and header retrieval, but it performs poorly when deleting messages."
^Varshavchik 2014: "In May 1992 Dan Bernstein suggested ... using RFC 931 to defeat certain classes of forged mail headers. Mark Crispin objected on several technical grounds... Bernstein eventually won this argument, even though working in Crispin's favor (and supporting his position) were certain other technical problems with the RFC 931 document. [Eventually] RFC 931 was revised and updated to become RFC 1413 [with credit given to Bernstein, not Crispin]. Bernstein went on to write the Qmail server. Qmail introduced a new filing method for storing E-mail, maildirs, [which] addressed several long-standing shortcomings of the traditional ... mbox mail format (the default mail format used by the UW-IMAP server)... Between 1995 and 1999 Qmail gained popularity until it became the second most popular mail server on the Internet. With Qmail's popularity growing, people began asking Crispin about adding support for Qmail's maildirs to the UW-IMAP server. Crispin, still simmering over losing the flame war over RFC 931, flogged this opportunity for all it was worth. He seemed to relish refusing every such request..."
^"What is "instant expunge" and when should I use it?". Uncensored Communications Group. Archived from the original on 2018-11-04. Retrieved 2018-11-04. Instant Expunge is a site-configurable setting that makes Citadel's IMAP service behave in a sensible way when deleting messages, as opposed to the behavior defined by RFC 3501. The IMAP protocol does not have a direct way of deleting messages. Instead, the client must set a "Deleted" flag on any messages which are to be deleted, and then perform an "Expunge" operation afterwards to actually delete the messages from the mailbox. It was designed this way because the reference implementation (UW IMAP) stores entire mailboxes in flat files, and deleting a single message requires rewriting the entire file. Rather than fix the limitations of this message store, Mark Crispin decided to implement a workaround and then define that workaround as part of the standard. By "expunging" a mailbox at a later time, the file is only rewritten once. Obviously, this functionality is obtuse and unnecessarily complicated for any other mail system, particularly one such as Citadel which stores messages in a database.
^McNab 2007, pp. 304–305: "[We list] remotely exploitable UW IMAP and Courier IMAP vulnerabilities... The following public exploit scripts are available for a number of these vulnerabilities..."
^Ziobrzynski 2006: "I prefer traditional mailboxes where multiple messages are stored in a single file per folder. Most modern IMAP servers, like Courier or Cyrus, use modern maildir or MH formats, which store each message in its own file. This consumes an insane amount of i-nodes. Unfortunately, the only open-source IMAP server I could find that uses traditional folders is the uw-imap. (CommuniGate Pro uses single files, but it's a commercial server.) The uw-imap server has a number of drawbacks, especially when it comes to SSL-protocol implementation. My tests of uw-imap with the SSL IMAP client that I had in mind for this project (PalmOS VersaMail) showed failed connections or flat failures to connect. To get what I want--the single file mail folders and working SSL--I split the function of IMAP and SSL over two separate servers: stunnel and uw-imap. Stunnel proved to be quite sophisticated in the SSL configuration and level of logging and diagnostic messages."
^Blum 2001, p. 458: "The University of Washington IMAP program supports both POP3 and IMAP."
^ abSill 2003, p. 344: "IMAP originated at the University of Washington, which distributes its own IMAP server. The UW-IMAP server doesn't support maildir mailboxes as distributed, but patches are available to add that functionality. See the unofficial qmail home pag (http://www.qmail.org/Archived 2019-06-15 at the Wayback Machine) for links to the patches for the current UW-IMAP release."
