The UW IMAP server was[3] the reference server implementation of the Internet Message Access Protocol.[4][5][6][7][8][9] It was developed at the University of Washington by Mark Crispin and others.[4][5][6][7][8][9]
Quick Facts Original author(s), Developer(s) ...
Close
UW-IMAP's development began c.1988.[6]
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.[3]
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.[3] 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] 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] 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] 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.
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]
UW IMAP uses the c-client mail engine that is also used by the Alpine[citation needed] and Pine e-mail clients.[6] c-client supports multiple mail store formats including Usenet news spools,[citation needed] MIX,[citation needed] mbox, mbx, mx, mh, tenex, mtx, MMDF, and phile.[6] c-client also includes support for IMAP, POP3, NNTP, and SMTP Internet protocols.[citation needed]
Also bundled with UW IMAP are POP2 and POP3 servers,[33] the mailutil utility program, and the dmail and tmail mail delivery agents.[2]
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. However, UW IMAP can be patched to support other formats, such as maildir. 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]
"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.)
"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.
Christenson 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." Gareiss, 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.
Golubitsky 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." Koka & 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." Blum 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." 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." Bautts, 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." Golubitsky 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." 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." 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..." Blum 2001, p. 458: "The University of Washington IMAP program supports both POP3 and IMAP."
Bibliography
- Bauer, Mick (2003). "Paranoid penguin: secure mail with LDAP and IMAP, Part I". Linux Journal. 2003 (115, November 2003): 12 – via ACM.
- Bautts, Tony; Dawson, Terry; Purdy, Gregor N. (2005). Linux network administrator's guide. O'Reilly Media. ISBN 9780596005481.
- Blum, Richard (2001). Postfix. SAMS. ISBN 9780672321146.
- Christenson, Nick (2003). Sendmail Performance Tuning. Addison-Wesley Professional. ISBN 9780321115706.
- Elprin, Nick; Parno, Bryan (2003). An Analysis of Database-Driven Mail Servers. 17th Large Installation System Administration Conference (LISA ’03). USENIX.
- Glennon, Katharine, ed. (2000). E-Mail Virus Protection Handbook: Protect Your E-mail from Trojan Horses, Viruses, and Mobile Code Attacks. Elsevier. ISBN 9780080477534.
- Golubitsky, Chaos (2005). Toward an Automated Vulnerability Comparison of Open Source IMAP Servers (PDF). 19th Large Installation System Administration Conference (LISA ’05). USENIX.
- Koka, Pranay; Lipasti, Mikko H. (2004). Characterization of an IMAP Server on a Shared-Memory Multiprocessor. 7th Workshop on CAECW.
- McNab, Chris (2007). Network Security Assessment: Know Your Network. O'Reilly Media. ISBN 9780596519339.
- Mullet, Dianna; Mullet, Kevin (2000). Managing IMAP. O'Reilly Media. ISBN 9780596000127.
- Sill, Dave (2003). The qmail Handbook. Apress. ISBN 9781430211341.
- Smith, Roderick W. (2003). Linux Power Tools. Wiley. ISBN 9780782142266.
- Smith, Roderick W. (2011). LPIC-2 Linux Professional Institute Certification Study Guide: Exams 201 and 202. John Wiley & Sons. ISBN 9781118100448.
- Soyinka, Wale (2008). Linux Administration: A Beginner's Guide, Fifth Edition. McGraw Hill Professional. ISBN 9780071546256.
- Varshavchik, Sam (2014). "FUD". Courier Mail Server.
- Ziobrzynski, Peter (2006). "Stealth e-mail to the rescue". Linux Journal. 2006 (143, March 2003) – via ACM.
