Subject: UW IMAP toolkit 2000 (imap-2000) BETA released

From: Mark Crispin <[email-masked]>
Date: Tue, 30 May 2000 18:39:58 -0700 (PDT)

University of Washington IMAP toolkit 2000 (imap-2000) is now available as
a BETA distribution.  imap-2000 has a large set of major internal and
external functional enhancements, as well as the usual set of bugfixes.
Formal release notes haven't been written up yet, but a list of the most
important changes is below.

imap-2000 includes the c-client API, a test program, and servers for the
POP2, POP3, and IMAP4rev1 protocols.  This is the reference implementation
of IMAP client and server code.

Note that this is a BETA release.  It has received limited loadtesting and
production use but is not yet deployed on all of our production servers.

imap-2000 is available from:
  ftp://ftp.cac.washington.edu/mail/imap-2000.BETA.tar.Z

Here are the most notable user-visible features in imap-2000:

1) SSL (port 993) support in client and server, and server TLS support
   (STARTTLS command).  Windows versions of imap-2000 have SSL support
   incorporated automatically.  To build a UNIX version with SSL, first
   install the OpenSSL package from a third party, then build the IMAP
   toolkit with "SPECIALAUTHENTICATORS=ssl" in the make command line.
   For example:
	make lnp SPECIALAUTHENTICATORS=ssl
   will build the software for Linux with PAM and SSL.

   To use SSL, add "/ssl" to the host name, e.g.
	{imapserver.foo.com/ssl}INBOX

   SSL certificate validation is also available for testing.  To use
   this, add "/validate-cert" to the host name.  This is available only
   on UNIX and Windows 2000/Millenium.

2) Microsoft Kerberos support for Windows 2000 and Windows Millenium.
   To get this support, you need to use "nmake -f makefile.w2k" (the w2k
   port) instead of the nt or ntk ports.

3) Support for the concept of "IMAP administrators".  An IMAP
   administrator is a user who can log in as any other user, and is
   defined as a user in the "mailadm" group.  The login is done by using
   the SASL authorization vs. authentication user facility as described
   in RFC 2222 and the various SASL mechanisms.

4) Support for the MULTIAPPEND extension.

5) All known buffer overflows sealed.

6) New c-client.h file to use instead of mail.h, osdep.h, etc.  It's a
   jacket around the other files, and is C++ safe.

-- Mark --

* RCW 19.190 notice: This email address is located in Washington State.	*
* Unsolicited commercial email may be billed $500 per message.		*
Science does not emerge from voting, party politics, or public debate.

-- 
-----------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------

---

From: David Lee <[email-masked]>
Date: Thu, 1 Jun 2000 12:22:01 +0100 (BST)

> important changes is below.

Thanks.  I'll try to take a look sometime soon.

Meanwhile, could you indicate whether there is any ability for building
the code with "shared libraries", ("lib*.so" files) on those operating
systems that support such a facility?

We currently use imap-4.7b (which seems not to be able to generate shared
libraries) on Solaris 2.6+ (which has the facility).  For a system running
imapd, ipop3d, dmail, tmail, chkmail, ... it would seem that shared
libraries could be beneficial. 

Are there substantial reasons against their implementation and use?

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/~dcl0tdl            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :

---

From: Mark Crispin <[email-masked]>
Date: Thu, 1 Jun 2000 10:48:52 -0700 (PDT)

> Are there substantial reasons against their implementation and use?

The only reason why we haven't a shared library version is that we have
limited experience with building shared libraries on the wide variety of
platforms supported by the IMAP toolkit; and the experience that we have has
tended to shy us away.

We had a instance where we wasted a lot of time tracking down a report of a
bug that we thought we fixed, only to have it turn out to be that one of our
modules had been made into a shared library.  The site had neglected to update
it when they updated the rest of the program!

It's probably a good idea to do shared libraries, and it will probably happen
eventually.