SF.net SVN: mahogany:[7492] trunk/M/lib/imap
[email protected] Sat, 26 Jul 2008 17:00:38 +0000
| Newsgroups | gmane.mail.mahogany.cvs |
|---|---|
| Message-ID | <[email protected]> |
Revision: 7492
http://mahogany.svn.sourceforge.net/mahogany/?rev=7492&view=rev
Author: vadz
Date: 2008-07-26 17:00:21 +0000 (Sat, 26 Jul 2008)
Log Message:
-----------
merged imap 2007b into trunk
Modified Paths:
--------------
trunk/M/lib/imap/Makefile
trunk/M/lib/imap/README
trunk/M/lib/imap/docs/BUILD
trunk/M/lib/imap/docs/FAQ.html
trunk/M/lib/imap/docs/FAQ.txt
trunk/M/lib/imap/docs/RELNOTES
trunk/M/lib/imap/docs/SSLBUILD
trunk/M/lib/imap/docs/bugs.txt
trunk/M/lib/imap/docs/draft/README
trunk/M/lib/imap/docs/draft/i18n.txt
trunk/M/lib/imap/docs/draft/sort.txt
trunk/M/lib/imap/docs/rfc/README
trunk/M/lib/imap/src/c-client/env.h
trunk/M/lib/imap/src/c-client/imap4r1.c
trunk/M/lib/imap/src/c-client/imap4r1.h
trunk/M/lib/imap/src/c-client/mail.c
trunk/M/lib/imap/src/c-client/mail.h
trunk/M/lib/imap/src/c-client/nntp.c
trunk/M/lib/imap/src/c-client/pop3.c
trunk/M/lib/imap/src/c-client/rfc822.c
trunk/M/lib/imap/src/c-client/smtp.c
trunk/M/lib/imap/src/c-client/smtp.h
trunk/M/lib/imap/src/c-client/utf8.c
trunk/M/lib/imap/src/c-client/utf8.h
trunk/M/lib/imap/src/c-client/utf8aux.c
trunk/M/lib/imap/src/c-client/utf8aux.h
trunk/M/lib/imap/src/dmail/Makefile
trunk/M/lib/imap/src/dmail/dmail.1
trunk/M/lib/imap/src/dmail/dmail.c
trunk/M/lib/imap/src/imapd/imapd.c
trunk/M/lib/imap/src/ipopd/ipop2d.c
trunk/M/lib/imap/src/ipopd/ipop3d.c
trunk/M/lib/imap/src/mailutil/mailutil.1
trunk/M/lib/imap/src/mailutil/mailutil.c
trunk/M/lib/imap/src/mlock/mlock.c
trunk/M/lib/imap/src/mtest/mtest.c
trunk/M/lib/imap/src/osdep/amiga/dummy.c
trunk/M/lib/imap/src/osdep/amiga/env_ami.c
trunk/M/lib/imap/src/osdep/amiga/fdstring.c
trunk/M/lib/imap/src/osdep/amiga/mbx.c
trunk/M/lib/imap/src/osdep/amiga/mh.c
trunk/M/lib/imap/src/osdep/amiga/mix.c
trunk/M/lib/imap/src/osdep/amiga/mmdf.c
trunk/M/lib/imap/src/osdep/amiga/mtx.c
trunk/M/lib/imap/src/osdep/amiga/mx.c
trunk/M/lib/imap/src/osdep/amiga/phile.c
trunk/M/lib/imap/src/osdep/amiga/tcp_ami.c
trunk/M/lib/imap/src/osdep/amiga/tenex.c
trunk/M/lib/imap/src/osdep/amiga/unix.c
trunk/M/lib/imap/src/osdep/dos/fdstring.c
trunk/M/lib/imap/src/osdep/dos/makefile
trunk/M/lib/imap/src/osdep/dos/tcp_dos.c
trunk/M/lib/imap/src/osdep/dos/tcp_dwa.c
trunk/M/lib/imap/src/osdep/dos/tcp_wsk.c
trunk/M/lib/imap/src/osdep/mac/linkage.c
trunk/M/lib/imap/src/osdep/mac/tcp_mac.c
trunk/M/lib/imap/src/osdep/nt/dummynt.c
trunk/M/lib/imap/src/osdep/nt/env_nt.c
trunk/M/lib/imap/src/osdep/nt/fdstring.c
trunk/M/lib/imap/src/osdep/nt/makefile.nt
trunk/M/lib/imap/src/osdep/nt/makefile.ntk
trunk/M/lib/imap/src/osdep/nt/makefile.old
trunk/M/lib/imap/src/osdep/nt/makefile.w2k
trunk/M/lib/imap/src/osdep/nt/mbxnt.c
trunk/M/lib/imap/src/osdep/nt/mtxnt.c
trunk/M/lib/imap/src/osdep/nt/os_nt.h
trunk/M/lib/imap/src/osdep/nt/os_old.c
trunk/M/lib/imap/src/osdep/nt/ssl_nt.c
trunk/M/lib/imap/src/osdep/nt/ssl_old.c
trunk/M/lib/imap/src/osdep/nt/ssl_w2k.c
trunk/M/lib/imap/src/osdep/nt/tcp_nt.c
trunk/M/lib/imap/src/osdep/nt/tenexnt.c
trunk/M/lib/imap/src/osdep/nt/unixnt.c
trunk/M/lib/imap/src/osdep/os2/mbxnt.c
trunk/M/lib/imap/src/osdep/os2/mtxnt.c
trunk/M/lib/imap/src/osdep/os2/tcp_os2.c
trunk/M/lib/imap/src/osdep/os2/tenexnt.c
trunk/M/lib/imap/src/osdep/os2/unixnt.c
trunk/M/lib/imap/src/osdep/tops-20/linkage.c
trunk/M/lib/imap/src/osdep/tops-20/shortsym.h
trunk/M/lib/imap/src/osdep/tops-20/tcp_t20.c
trunk/M/lib/imap/src/osdep/unix/Makefile
trunk/M/lib/imap/src/osdep/unix/Makefile.gss
trunk/M/lib/imap/src/osdep/unix/ckp_gss.c
trunk/M/lib/imap/src/osdep/unix/dummy.c
trunk/M/lib/imap/src/osdep/unix/env_unix.c
trunk/M/lib/imap/src/osdep/unix/fdstring.c
trunk/M/lib/imap/src/osdep/unix/flocksim.c
trunk/M/lib/imap/src/osdep/unix/mbx.c
trunk/M/lib/imap/src/osdep/unix/mh.c
trunk/M/lib/imap/src/osdep/unix/mix.c
trunk/M/lib/imap/src/osdep/unix/mmdf.c
trunk/M/lib/imap/src/osdep/unix/mtx.c
trunk/M/lib/imap/src/osdep/unix/mx.c
trunk/M/lib/imap/src/osdep/unix/os_aix.c
trunk/M/lib/imap/src/osdep/unix/os_aos.c
trunk/M/lib/imap/src/osdep/unix/os_bsd.c
trunk/M/lib/imap/src/osdep/unix/os_bsf.c
trunk/M/lib/imap/src/osdep/unix/os_bsi.c
trunk/M/lib/imap/src/osdep/unix/os_cvx.c
trunk/M/lib/imap/src/osdep/unix/os_do4.c
trunk/M/lib/imap/src/osdep/unix/os_dyn.c
trunk/M/lib/imap/src/osdep/unix/os_hpp.c
trunk/M/lib/imap/src/osdep/unix/os_lnx.c
trunk/M/lib/imap/src/osdep/unix/os_mnt.c
trunk/M/lib/imap/src/osdep/unix/os_nxt.c
trunk/M/lib/imap/src/osdep/unix/os_osx.c
trunk/M/lib/imap/src/osdep/unix/os_osx.h
trunk/M/lib/imap/src/osdep/unix/os_ptx.c
trunk/M/lib/imap/src/osdep/unix/os_s40.c
trunk/M/lib/imap/src/osdep/unix/os_shp.c
trunk/M/lib/imap/src/osdep/unix/os_slx.c
trunk/M/lib/imap/src/osdep/unix/os_sol.c
trunk/M/lib/imap/src/osdep/unix/os_sun.c
trunk/M/lib/imap/src/osdep/unix/os_ult.c
trunk/M/lib/imap/src/osdep/unix/os_vu2.c
trunk/M/lib/imap/src/osdep/unix/phile.c
trunk/M/lib/imap/src/osdep/unix/ssl_unix.c
trunk/M/lib/imap/src/osdep/unix/tcp_unix.c
trunk/M/lib/imap/src/osdep/unix/tenex.c
trunk/M/lib/imap/src/osdep/unix/unix.c
trunk/M/lib/imap/src/osdep/vms/linkage.c
trunk/M/lib/imap/src/osdep/vms/tcp_vmsl.c
trunk/M/lib/imap/src/osdep/vms/tcp_vmsm.c
trunk/M/lib/imap/src/osdep/wce/tcp_wce.c
trunk/M/lib/imap/src/tmail/Makefile
trunk/M/lib/imap/src/tmail/tmail.1
trunk/M/lib/imap/src/tmail/tmail.c
trunk/M/lib/imap/tools/an
Added Paths:
-----------
trunk/M/lib/imap/docs/rfc/rfc4959.txt
trunk/M/lib/imap/docs/rfc/rfc4978.txt
trunk/M/lib/imap/docs/rfc/rfc5032.txt
trunk/M/lib/imap/docs/rfc/rfc5051.txt
trunk/M/lib/imap/docs/rfc/rfc5092.txt
trunk/M/lib/imap/docs/rfc/rfc5161.txt
trunk/M/lib/imap/docs/rfc/rfc5162.txt
trunk/M/lib/imap/docs/rfc/rfc5234.txt
trunk/M/lib/imap/src/dmail/dquota.c
trunk/M/lib/imap/src/dmail/dquota.h
trunk/M/lib/imap/src/osdep/unix/os_sua.c
trunk/M/lib/imap/src/osdep/unix/os_sua.h
trunk/M/lib/imap/src/tmail/tquota.c
trunk/M/lib/imap/src/tmail/tquota.h
Removed Paths:
-------------
trunk/M/lib/imap/docs/rfc/rfc2192.txt
trunk/M/lib/imap/docs/rfc/rfc4234.txt
Modified: trunk/M/lib/imap/Makefile
===================================================================
--- trunk/M/lib/imap/Makefile 2008-07-26 16:30:01 UTC (rev 7491)
+++ trunk/M/lib/imap/Makefile 2008-07-26 17:00:21 UTC (rev 7492)
@@ -1,5 +1,5 @@
# ========================================================================
-# Copyright 1988-2006 University of Washington
+# Copyright 1988-2008 University of Washington
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
@@ -13,15 +13,12 @@
# Program: IMAP Toolkit Makefile
#
# Author: Mark Crispin
-# Networks and Distributed Computing
-# Computing & Communications
-# University of Washington
-# Administration Building, AG-44
+# UW Technology
# Seattle, WA 98195
-# Internet: [email protected]
+# Internet: [email protected]
#
# Date: 7 December 1989
-# Last Edited: 29 March 2007
+# Last Edited: 12 May 2008
# Normal command to build IMAP toolkit:
@@ -82,6 +79,7 @@
# isc Interactive Systems
# ldb Debian Linux
# lfd Fedora Core 4
+# ln8 Linux for Nokia N800
# lnx Linux with traditional passwords and crypt() in the C library
# (see lnp, sl4, sl5, and slx)
# lnp Linux with Pluggable Authentication Modules (PAM)
@@ -92,13 +90,14 @@
# lyn LynxOS
# mct MachTen
# mnt Atari ST Mint (not MacMint)
-# neb NetBSD/FreeBSD
+# neb NetBSD
# nec NEC UX
# nto QNX Neutrine RTP
# nxt NEXTSTEP
# nx3 NEXTSTEP 3.x
# osf OSF/1 (see sos, os4)
# os4 OSF/1 (Digital UNIX) 4
+# osi Apple iPhone and iPod Touch
# osx Mac OS X
# oxp Mac OS X with Pluggable Authentication Modules (PAM)
# ptx PTX
@@ -118,6 +117,7 @@
# sol Solaris (won't work unless "ucbcc" works -- use gso instead)
# sos OSF/1 with SecureWare
# ssn SUN-OS with shadow password security
+# sua Windows Vista (Enterprise or Ultima) Subsystem for Unix Applications
# sun SUN-OS 4.1 or better (*not* Solaris) (see ssn)
# sv2 SVR2 on AT&T PC-7300 (incomplete port)
# sv4 generic SVR4
@@ -306,7 +306,7 @@
# Note on SCO you may have to set LN to "ln".
-a32 a41 aix bs3 bsi d-g d54 do4 drs epx ga4 gas gh9 ghp ghs go5 gsc gsg gso gul h11 hpp hpx lnp lyn mct mnt neb nec nto nxt nx3 osf os4 ptx qnx sc5 sco sgi sg6 shp sl4 sl5 slx snx soc sol sos uw2: an
+a32 a41 aix bs3 bsi d-g d54 do4 drs epx ga4 gas gh9 ghp ghs go5 gsc gsg gso gul h11 hpp hpx lnp lyn mct mnt nec nto nxt nx3 osf os4 ptx qnx sc5 sco sgi sg6 shp sl4 sl5 slx snx soc sol sos uw2: an
$(BUILD) BUILDTYPE=$@
# If you use sv4, you may find that it works to move it to use the an process.
@@ -319,15 +319,29 @@
# Knotheads moved Kerberos and SSL locations on these platforms
+# Paul Vixie claims that all FreeBSD versions have working IPv6
+
bsf: an
- $(BUILD) BUILDTYPE=$@ \
+ $(TOUCH) ip6
+ $(BUILD) BUILDTYPE=$@ IP=$(IP6) \
PASSWDTYPE=pam \
- SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/etc/ssl/certs SSLKEYS=/etc/ssl/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib LOCKPGM=/usr/sbin/mlock PAMLDFLAGS=-lpam"
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/etc/ssl/certs SSLKEYS=/etc/ssl/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib PAMLDFLAGS=-lpam"
+# I assume that Theo did the right thing for IPv6. OpenBSD does not have PAM.
+
bso: an
- $(BUILD) BUILDTYPE=$@ \
- SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/etc/ssl SSLKEYS=/etc/ssl/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib LOCKPGM=/usr/sbin/mlock"
+ $(TOUCH) ip6
+ $(BUILD) BUILDTYPE=$@ IP=$(IP6) \
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/etc/ssl SSLKEYS=/etc/ssl/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib"
+# Info from Joel Reicher about NetBSD SSL paths. I assume it has PAM because pam is in NetBSD sources...
+
+neb: an
+ $(TOUCH) ip6
+ $(BUILD) BUILDTYPE=$@ IP=$(IP6) \
+ PASSWDTYPE=pam \
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/etc/openssl/certs SSLKEYS=/etc/openssl/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib PAMLDFLAGS=-lpam"
+
cyg: an
$(BUILD) BUILDTYPE=cyg \
SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/usr/ssl/certs SSLKEYS=/usr/ssl/certs"
@@ -338,21 +352,34 @@
ldb: an
$(BUILD) BUILDTYPE=lnp IP=$(IP6) \
- SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/etc/ssl/certs SSLKEYS=/etc/ssl/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib LOCKPGM=/usr/sbin/mlock"
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/etc/ssl/certs SSLKEYS=/etc/ssl/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib MAILSPOOL=/var/mail"
-lfd lr5: an
+lfd: an
$(BUILD) BUILDTYPE=lnp IP=$(IP6) \
- EXTRACFLAGS="$(EXTRACFLAGS) -I/usr/kerberos/include" \
- SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/etc/pki/tls/certs SSLKEYS=/etc/pki/tls/private GSSDIR=/usr/kerberos LOCKPGM=/usr/sbin/mlock"
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/etc/pki/tls/certs SSLKEYS=/etc/pki/tls/private GSSDIR=/usr/kerberos"
+ln8: an
+ $(TOUCH) ip6
+ $(BUILD) BUILDTYPE=slx IP=$(IP6) \
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/usr/lib/ssl/certs MAILSPOOL=/var/mail"
+
+
+# RHE5 does not have the IPv6 bug
+
+lr5: an
+ $(TOUCH) ip6
+ $(BUILD) BUILDTYPE=lnp IP=$(IP6) \
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/etc/pki/tls/certs SSLKEYS=/etc/pki/tls/private GSSDIR=/usr/kerberos"
+
lmd: an
$(BUILD) BUILDTYPE=lnp IP=$(IP6) \
- SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/usr/lib/ssl/certs SSLKEYS=/usr/lib/ssl/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib LOCKPGM=/usr/sbin/mlock"
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/usr/lib/ssl/certs SSLKEYS=/usr/lib/ssl/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib"
+# RHE3 definitely has the IPv6 bug
+
lrh: lrhok an
$(BUILD) BUILDTYPE=lnp IP=$(IP6) \
- EXTRACFLAGS="$(EXTRACFLAGS) -I/usr/kerberos/include" \
- SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/usr/share/ssl/certs SSLKEYS=/usr/share/ssl/private GSSDIR=/usr/kerberos LOCKPGM=/usr/sbin/mlock"
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/usr/share/ssl/certs SSLKEYS=/usr/share/ssl/private GSSDIR=/usr/kerberos"
lrhok:
@$(SH) -c '(test ! -d /etc/pki/tls ) || make lrhwarn'
@@ -376,20 +403,28 @@
lsu: an
$(BUILD) BUILDTYPE=lnp IP=$(IP6) \
- EXTRACFLAGS="$(EXTRACFLAGS) -I/usr/kerberos/include" \
- SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/usr/share/ssl/certs SSLKEYS=/usr/share/ssl/private GSSDIR=/usr/kerberos LOCKPGM=/usr/sbin/mlock"
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/usr/share/ssl/certs SSLKEYS=/usr/share/ssl/private GSSDIR=/usr/kerberos"
+# iToy does not have Kerberos or PAM. It doesn't have a
+# /System/Library/OpenSSL directory either, but the libcrypto shared library
+# has these locations so this is what we will use.
+
+osi: an
+ $(TOUCH) ip6
+ $(BUILD) BUILDTYPE=osx IP=$(IP6) CC=arm-apple-darwin-gcc \
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/System/Library/OpenSSL/certs SSLKEYS=/System/Library/OpenSSL/private"
+
oxp: an
$(TOUCH) ip6
$(BUILD) BUILDTYPE=osx IP=$(IP6) EXTRAAUTHENTICATORS="$(EXTRAAUTHENTICATORS) gss" \
PASSWDTYPE=pam \
EXTRACFLAGS="$(EXTRACFLAGS) -DMAC_OSX_KLUDGE=1" \
- SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/System/Library/OpenSSL/certs SSLKEYS=/System/Library/OpenSSL/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib LOCKPGM=/usr/sbin/mlock PAMDLFLAGS=-lpam"
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/System/Library/OpenSSL/certs SSLKEYS=/System/Library/OpenSSL/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib PAMDLFLAGS=-lpam"
osx: osxok an
$(TOUCH) ip6
$(BUILD) BUILDTYPE=$@ IP=$(IP6) EXTRAAUTHENTICATORS="$(EXTRAAUTHENTICATORS) gss" \
- SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/System/Library/OpenSSL/certs SSLKEYS=/System/Library/OpenSSL/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib LOCKPGM=/usr/sbin/mlock"
+ SPECIALS="SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLCERTS=/System/Library/OpenSSL/certs SSLKEYS=/System/Library/OpenSSL/private GSSINCLUDE=/usr/include GSSLIB=/usr/lib"
osxok:
@$(SH) -c '(test ! -f /usr/include/pam/pam_appl.h ) || make osxwarn'
@@ -475,7 +510,15 @@
$(MAKE) ua LN=ln
$(BUILD) BUILDTYPE=$@ LN=ln
+# Hard links don't quite work right in SUA, and there don't seem to be any
+# SSL includes. However, IPv6 works.
+sua:
+ $(TOUCH) ip6 sslnone
+ $(MAKE) an LN=cp SSLTYPE=none
+ $(BUILD) BUILDTYPE=$@ LN=cp IP=$(IP6) SSLTYPE=none
+
+
# Pine port names, not distinguished in c-client
bs2: an
Modified: trunk/M/lib/imap/README
===================================================================
--- trunk/M/lib/imap/README 2008-07-26 16:30:01 UTC (rev 7491)
+++ trunk/M/lib/imap/README 2008-07-26 17:00:21 UTC (rev 7492)
@@ -1,5 +1,5 @@
/* ========================================================================
- * Copyright 1988-2006 University of Washington
+ * Copyright 1988-2007 University of Washington
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -9,10 +9,10 @@
*
*
* ========================================================================
-*/
+ */
IMAP Toolkit Environment
- 30 August 2006
+ 4 April 2007
Mark Crispin
@@ -29,7 +29,7 @@
(including building a non-compliant server without SSL support), please
refer to the docs/BUILD file for more information.
-1) Look in imap-2006/Makefile and find your system type code. For example,
+1) Look in the top-level Makefile and find your system type code. For example,
modern versions of Linux will use either "slx", "lnp", or one of the
lnp-variants (such as "lrh").
Modified: trunk/M/lib/imap/docs/BUILD
===================================================================
--- trunk/M/lib/imap/docs/BUILD 2008-07-26 16:30:01 UTC (rev 7491)
+++ trunk/M/lib/imap/docs/BUILD 2008-07-26 17:00:21 UTC (rev 7492)
@@ -1,5 +1,5 @@
/* ========================================================================
- * Copyright 1988-2006 University of Washington
+ * Copyright 1988-2007 University of Washington
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -12,7 +12,7 @@
*/
BUILD AND INSTALLATION NOTES
- Last Updated: 15 June 2006
+ Last Updated: 15 November 2007
Table of Contents:
1. UNIX Build Notes
@@ -38,12 +38,12 @@
Note that doing so will produce an IMAP server which is NON-COMPLIANT with
RFC 3501.
- You must build through the top-level imap-2006/Makefile, which will run
-a "process" step the first time and create the imap-2006/c-client,
-imap-2006/ipopd, and imap-2006/imapd directories in which building actually
+ You must build through the top-level imap-2007/Makefile, which will run
+a "process" step the first time and create the imap-2007/c-client,
+imap-2007/ipopd, and imap-2007/imapd directories in which building actually
takes place.
- Before doing a make on UNIX, you should read imap-2006/Makefile and see
+ Before doing a make on UNIX, you should read imap-2007/Makefile and see
if your system type is known. The various system types are three-letter codes.
If your system type is known, then use this as the make option. After the
first time you do a make, this option is remembered in a file called OSTYPE,
@@ -55,7 +55,7 @@
To build for RedHat, do:
make lrh
- There are other make options, described in imap-2006/src/osdep/Makefile.
+ There are other make options, described in imap-2007/src/osdep/Makefile.
It's probably best to see if an existing port will work on your system
before inventing a new port. Try:
@@ -65,7 +65,7 @@
bsf modern BSD
If you must invent a new port, you need to create an entry in
-imap-2006/Makefile and imap-2006/src/osdep/Makefile for your new port, as
+imap-2007/Makefile and imap-2007/src/osdep/Makefile for your new port, as
well as osdep/os_???.h and osdep/os_???.c files with the appropriate
OS-dependent support for that system. You also need to determine which setup
process to use. You should use the ua process unless you are sure that your
@@ -91,10 +91,10 @@
UNIX INSTALLATION NOTES
Binaries from the build are:
- imap-2006/mtest/mtest c-client testbed program
- imap-2006/ipopd/ipop2d POP2 daemon
- imap-2006/ipopd/ipop3d POP3 daemon
- imap-2006/imapd/imapd IMAP4rev1 daemon
+ imap-2007/mtest/mtest c-client testbed program
+ imap-2007/ipopd/ipop2d POP2 daemon
+ imap-2007/ipopd/ipop3d POP3 daemon
+ imap-2007/imapd/imapd IMAP4rev1 daemon
mtest is normally not used except by c-client developers.
@@ -272,11 +272,11 @@
There is also considerable debate about how new mail is to be snarfed.
I am currently using something that seems to work with WinSMTP. Look at
-the definition of MAILFILE in imap-2006/src/osdep/nt/mailfile.h and at the
-sysinbox() function in imap-2006/src/osdep/nt/env_nt.c to see what's there
+the definition of MAILFILE in imap-2007/src/osdep/nt/mailfile.h and at the
+sysinbox() function in imap-2007/src/osdep/nt/env_nt.c to see what's there
now, so you have a clue about how to hack it.
- To build under Windows 95/98/NT, connect to the imap-2006 directory
+ To build under Windows 95/98/NT, connect to the imap-2007 directory
and do:
nmake -f makefile.nt
The resulting binaries will support SSL if either schannel.dll or
@@ -284,7 +284,7 @@
interfaces. You can also use this to build under Me/2000/XP, but it is
not the preferred build on this platform.
- To build with MIT Kerberos support, connect to the imap-2006 directory
+ To build with MIT Kerberos support, connect to the imap-2007 directory
and do:
nmake -f makefile.ntk
The resulting binaries will support SSL if either schannel.dll or
@@ -293,7 +293,7 @@
these binaries will only run on systems which have the MIT Kerberos DLLs
installed, and will not run otherwise.
- To build under Windows Me/2000/XP, connect to the imap-2006 directory
+ To build under Windows Me/2000/XP, connect to the imap-2007 directory
and do:
nmake -f makefile.w2k
The resulting binaries will support SSL and Microsoft Kerberos, using the
@@ -303,10 +303,10 @@
WIN32 INSTALLATION NOTES
The resulting binaries will be:
- imap-2006\mtest\mtest.exe (testbed client)
- imap-2006\ipopd\ipop2d.exe POP2 server
- imap-2006\ipopd\ipop3d.exe POP3 server
- imap-2006\imapd\imapd.exe IMAP4rev1 server
+ imap-2007\mtest\mtest.exe (testbed client)
+ imap-2007\ipopd\ipop2d.exe POP2 server
+ imap-2007\ipopd\ipop3d.exe POP3 server
+ imap-2007\imapd\imapd.exe IMAP4rev1 server
These servers are stdio servers. I wrote a simple network listener
for NT called inetlisn; currently it is available as:
@@ -347,10 +347,10 @@
person will try porting Pine to TOPS-20. This assumes the use of KCC 6, and
probably will not build with other compilers or older versions of KCC.
- You do not use imap-2006/Makefile under TOPS-20, nor do you build any
+ You do not use imap-2007/Makefile under TOPS-20, nor do you build any
components other than c-client and mtest. Merge the contents of
-imap-2006/src/c-client, imap-2006/src/charset, imap-2006/src/mtest, and
-imap-2006/src/osdep/tops-20 onto a single directory on TOPS-20 and build from
+imap-2007/src/c-client, imap-2007/src/charset, imap-2007/src/mtest, and
+imap-2007/src/osdep/tops-20 onto a single directory on TOPS-20 and build from
that. The command:
DO BUILD.CTL
will build the sources. If you don't have MIC, then SUBMIT BUILD.CTL and let
@@ -359,14 +359,14 @@
VMS BUILD NOTES
- The VMS port has been tested with imap-2006, but as I am soon going
+ The VMS port has been tested with imap-2007, but as I am soon going
to lose access to a VMS system I will no longer be able able to test and
this port will be moved to the "other ports" category".
- You do not use imap-2006/Makefile under VMS, nor do you build any
+ You do not use imap-2007/Makefile under VMS, nor do you build any
components other than c-client and mtest. Merge the contents of
-imap-2006/src/c-client, imap-2006/src/charset, imap-2006/src/mtest, and
-imap-2006/src/osdep/vms onto a single directory on VMS and build from that.
+imap-2007/src/c-client, imap-2007/src/charset, imap-2007/src/mtest, and
+imap-2007/src/osdep/vms onto a single directory on VMS and build from that.
The command to build it is:
@BUILD MULTINET
or @BUILD NETLIB
@@ -401,10 +401,10 @@
If you are building a Macintosh client, you will need MacTCP installed on
your system as well as the MacTCP C includes and libraries.
- You do not use imap-2006/Makefile on the Mac, nor do you build any
+ You do not use imap-2007/Makefile on the Mac, nor do you build any
components other than c-client and mtest. Merge the contents of
-imap-2006/src/c-client, imap-2006/src/charset, imap-2006/src/mtest, and
-imap-2006/src/osdep/mac onto a single directory on the Mac and build from
+imap-2007/src/c-client, imap-2007/src/charset, imap-2007/src/mtest, and
+imap-2007/src/osdep/mac onto a single directory on the Mac and build from
that. mtext.sit.hqx is a THINK C project file and cute icon for building
mtest, encoded with Binhex and StuffIt.
@@ -451,10 +451,10 @@
supported stacks are Beame & Whiteside, PC-NFS, Novell, PC/IP, Waterloo, and
Winsock. mtest and a version of Pine called PC Pine run under DOS.
- You do not use imap-2006/Makefile under DOS, nor do you build any
+ You do not use imap-2007/Makefile under DOS, nor do you build any
components other than c-client and mtest. Merge the contents of
-imap-2006/src/c-client, imap-2006/src/charset, imap-2006/src/mtest, and
-imap-2006/src/osdep/dos onto a single directory on DOS and build from that.
+imap-2007/src/c-client, imap-2007/src/charset, imap-2007/src/mtest, and
+imap-2007/src/osdep/dos onto a single directory on DOS and build from that.
The MAKE command on DOS takes an argument identifying the TCP/IP stack in use.
For example, do:
MAKE MAKEFILE OS=WSK (or MAKE -F MAKEFILE OS=WSK)
@@ -474,7 +474,7 @@
I build using Visual C++ 6.0 with the WCE extensions. The current code
has SH3 wired in for the compiler building.
- To build under NT, connect to the imap-2006 directory and do:
+ To build under NT, connect to the imap-2007 directory and do:
nmake -f makefile.wce
The only binary produced is a cclient.lib file. I haven't gotten as far
Modified: trunk/M/lib/imap/docs/FAQ.html
===================================================================
--- trunk/M/lib/imap/docs/FAQ.html 2008-07-26 16:30:01 UTC (rev 7491)
+++ trunk/M/lib/imap/docs/FAQ.html 2008-07-26 17:00:21 UTC (rev 7492)
@@ -1,6 +1,6 @@
<!--
* ========================================================================
- * Copyright 1988-2006 University of Washington
+ * Copyright 1988-2007 University of Washington
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -863,7 +863,7 @@
directory and each message is a file within that directory; these
formats support sub-mailboxes within such mailboxes. However, for
technical reasons, the "flat file" formats are generally preferred
- since they perform better. Read imap-2006/docs/formats.txt for more
+ since they perform better. Read imap-2007/docs/formats.txt for more
information on this topic.</p>
<p>It is always permissible to create a directory that is not a
@@ -1377,12 +1377,12 @@
<dl>
<dd>
- imap-2006 supports SSL and TLS client functionality on UNIX and 32-bit
+ imap-2007 supports SSL and TLS client functionality on UNIX and 32-bit
Windows for IMAP, POP3, SMTP, and NNTP; and SSL and TLS server
functionality on UNIX for IMAP and POP3.
<p>UNIX SSL build requires that a third-party software package,
- OpenSSL, be installed on the system first. Read imap-2006/docs/SSLBUILD
+ OpenSSL, be installed on the system first. Read imap-2007/docs/SSLBUILD
for more information.</p>
<p>SSL is supported via undocumented Microsoft interfaces in Windows 9x
@@ -1427,7 +1427,7 @@
<dl>
<dd>
- imap-2006 supports client and server functionality on UNIX and 32-bit
+ imap-2007 supports client and server functionality on UNIX and 32-bit
Windows.
<p>Kerberos V5 is supported by default in Windows 2000 builds:</p>
@@ -1957,7 +1957,7 @@
<p>A number of sites have done full-fledged format conversions, and are
reportedly quite happy with the results. Feel free to ask in the
- comp.mail.imap newsgroup or the c-client mailing list for advice or
+ comp.mail.imap newsgroup or the imap-uw mailing list for advice or
help.</p>
</dd>
</dl>
@@ -2993,7 +2993,7 @@
the directory by itself, it will try to call mlock to do it. I do not
recommend doing this for performance reasons.</p>
- <p>A sample mlock program is included as part of imap-2006. We have
+ <p>A sample mlock program is included as part of imap-2007. We have
tried to make this sample program secure, but it has not been
thoroughly audited.</p>
</dd>
@@ -4089,7 +4089,7 @@
<p>The SECURITY PROBLEM came about because the server advertised the
AUTH=PLAIN SASL authentication mechanism outside of a TLS-encrypted
- session, in violation of RFC 2595. This message is just a warning, and
+ session, in violation of RFC 4616. This message is just a warning, and
in fact occurred after the server had disconnected.</p>
</dd>
</dl>
@@ -4116,18 +4116,18 @@
initial challenge, qmail issues a bogus response:</p>
<pre>
334 ok, go on
-</pre>The problem is the "ok, go on". This violates RFC 2554's requirement
+</pre>The problem is the "ok, go on". This violates RFC 4954's requirement
that the text part in a 334 response be a BASE64 encoded string; in other
words, it is a protocol syntax error.
- <p>In the case of AUTH=PLAIN, RFC 2222 (pp 4-5) requires that the
+ <p>In the case of AUTH=PLAIN, RFC 4422 (page 7) requires that the
encoded string have no data. In other words, the appropropiate
standards-compliant server response is "334" followed by a SPACE and a
CRLF.</p>
<p>The SECURITY PROBLEM came about because the server advertised the
AUTH=PLAIN SASL authentication mechanism outside of a TLS-encrypted
- session, in violation of RFC 2595. This message is just a warning, and
+ session, in violation of RFC 4616. This message is just a warning, and
is not related the "Authentication cancelled" problem.</p>
</dd>
</dl>
@@ -4170,16 +4170,23 @@
<dd>
If you have questions about the IMAP protocol, or want to participate
in discussions of future directions of the IMAP protocol, the
- appropriate mailing list is [email protected]. You must be a
- subscriber to post to the list; to subscribe, use <a href=
- "mailto:[email protected]"><tt>[email protected]</tt></a>
+ appropriate mailing list is [email protected]. You can
+ subscribe to this list via <a href=
+ "mailto:[email protected]"><tt>[email protected]</tt></a>
<p>If you have questions about this software, you can send me email
- directly or use the [email protected] mailing list. You can
+ directly or use the [email protected] mailing list. You can
subscribe to this list via <a href=
- "mailto:[email protected]"><tt>[email protected]</tt></a></p>
+ "mailto:[email protected]"><tt>[email protected]</tt></a></p>
- <p>As an alternative to either of these, you can use the
+ <p>If you have general questions about the use of IMAP software
+ (not specific to the UW IMAP toolkit) use the
+ [email protected] mailing list. You can subscribe to
+ this list via <a href=
+ "mailto:[email protected]"><tt>[email protected]</tt></a></p>
+
+ <p>You must be a subscriber to post to these lists. As an
+ alternative, you can use the
<strong>comp.mail.imap</strong> newsgroup.</p>
</dd>
</dl>
@@ -4213,7 +4220,7 @@
<p><a href="#top">Back to top</a></p>
- <p>Last Updated: 11 December 2006</p>
+ <p>Last Updated: 15 November 2007</p>
<!--chtml include "//imap/incs/bottom.inc"-->
Modified: trunk/M/lib/imap/docs/FAQ.txt
===================================================================
--- trunk/M/lib/imap/docs/FAQ.txt 2008-07-26 16:30:01 UTC (rev 7491)
+++ trunk/M/lib/imap/docs/FAQ.txt 2008-07-26 17:00:21 UTC (rev 7492)
@@ -1,5 +1,5 @@
/* ========================================================================
- * Copyright 1988-2006 University of Washington
+ * Copyright 1988-2007 University of Washington
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -449,7 +449,7 @@
directory; these formats support sub-mailboxes within such
mailboxes. However, for technical reasons, the "flat file"
formats are generally preferred since they perform better. Read
- imap-2006/docs/formats.txt for more information on this topic.
+ imap-2007/docs/formats.txt for more information on this topic.
It is always permissible to create a directory that is not a
mailbox, and have sub-mailboxes under it. The easiest way to
@@ -768,13 +768,13 @@
3.5 How do I configure SSL?
3.6 How do I configure TLS and the STARTTLS facility?
- imap-2006 supports SSL and TLS client functionality on UNIX and
+ imap-2007 supports SSL and TLS client functionality on UNIX and
32-bit Windows for IMAP, POP3, SMTP, and NNTP; and SSL and TLS
server functionality on UNIX for IMAP and POP3.
UNIX SSL build requires that a third-party software package,
OpenSSL, be installed on the system first. Read
- imap-2006/docs/SSLBUILD for more information.
+ imap-2007/docs/SSLBUILD for more information.
SSL is supported via undocumented Microsoft interfaces in
Windows 9x and NT4; and via standard interfaces in Windows
@@ -801,7 +801,7 @@
3.10 How do I configure Kerberos V5?
- imap-2006 supports client and server functionality on UNIX and
+ imap-2007 supports client and server functionality on UNIX and
32-bit Windows.
Kerberos V5 is supported by default in Windows 2000 builds:
@@ -1188,7 +1188,7 @@
A number of sites have done full-fledged format conversions,
and are reportedly quite happy with the results. Feel free to
- ask in the comp.mail.imap newsgroup or the c-client mailing
+ ask in the comp.mail.imap newsgroup or the imap-uw mailing
list for advice or help.
_________________________________________________________________
@@ -2010,7 +2010,7 @@
try to call mlock to do it. I do not recommend doing this for
performance reasons.
- A sample mlock program is included as part of imap-2006. We
+ A sample mlock program is included as part of imap-2007. We
have tried to make this sample program secure, but it has not
been thoroughly audited.
_________________________________________________________________
@@ -2895,7 +2895,7 @@
The SECURITY PROBLEM came about because the server advertised
the AUTH=PLAIN SASL authentication mechanism outside of a
- TLS-encrypted session, in violation of RFC 2595. This message
+ TLS-encrypted session, in violation of RFC 4616. This message
is just a warning, and in fact occurred after the server had
disconnected.
_________________________________________________________________
@@ -2917,18 +2917,18 @@
334 ok, go on
- The problem is the "ok, go on". This violates RFC 2554's
+ The problem is the "ok, go on". This violates RFC 4954's
requirement that the text part in a 334 response be a BASE64
encoded string; in other words, it is a protocol syntax error.
- In the case of AUTH=PLAIN, RFC 2222 (pp 4-5) requires that the
+ In the case of AUTH=PLAIN, RFC 4422 (page 7) requires that the
encoded string have no data. In other words, the appropropiate
standards-compliant server response is "334" followed by a
SPACE and a CRLF.
The SECURITY PROBLEM came about because the server advertised
the AUTH=PLAIN SASL authentication mechanism outside of a
- TLS-encrypted session, in violation of RFC 2595. This message
+ TLS-encrypted session, in violation of RFC 4616. This message
is just a warning, and is not related the "Authentication
cancelled" problem.
_________________________________________________________________
@@ -2958,18 +2958,23 @@
If you have questions about the IMAP protocol, or want to
participate in discussions of future directions of the IMAP
protocol, the appropriate mailing list is
- [email protected]. You must be a subscriber to post to the
- list; to subscribe, use [email protected]
+ [email protected]. You can subscribe to this
+ list via [email protected]
If you have questions about this software, you can send me
- email directly or use the [email protected] mailing
+ email directly or use the [email protected] mailing
list. You can subscribe to this list via
- [email protected]
+ [email protected]
- As an alternative to either of these, you can use the
- comp.mail.imap newsgroup.
- _________________________________________________________________
+ If you have general questions about the use of IMAP software
+ (not specific to the UW IMAP toolkit) use the
+ [email protected] mailing list. You can subscribe to
+ this list via [email protected]
+ You must be a subscriber to post to these lists. As an
+ alternative, you can use the comp.mail.imap newsgroup.
+ _________________________________________________________________
+
8.3 Where can I read more about IMAP and other email protocols?
We recommend Internet Email Protocols: A Developer's Guide, by
@@ -2985,4 +2990,4 @@
This book also has an excellent comparison of the UW and Cyrus
IMAP servers.
- Last Updated: 11 December 2006
+ Last Updated: 15 November 2007
Modified: trunk/M/lib/imap/docs/RELNOTES
===================================================================
--- trunk/M/lib/imap/docs/RELNOTES 2008-07-26 16:30:01 UTC (rev 7491)
+++ trunk/M/lib/imap/docs/RELNOTES 2008-07-26 17:00:21 UTC (rev 7492)
@@ -1,5 +1,5 @@
/* ========================================================================
- * Copyright 1988-2007 University of Washington
+ * Copyright 1988-2008 University of Washington
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -11,6 +11,88 @@
* ========================================================================
*/
+Updated: 25 March 2008
+
+imap-2007b is a maintenance release, consisting primarily of bugfixes to
+problems discovered in the release that affected a small number of users.
+
+
+Updated: 2 January 2008
+
+imap-2007a is a maintenance release, consisting primarily of bugfixes to
+problems discovered in the release that affected a small number of users.
+
+
+Updated: 20 December 2007
+
+imap-2007 is a release corresponding with the release of Alpine 1.0.
+The primary focus of the imap-2007 release is bugfixes and reliability
+improvements. This includes:
+ . fixes to problems discovered between the Alpine 0.99999 pre-release
+ and Alpine 1.0
+ . fixes to the mix driver to timing race problems uncovered by Timo
+ Sirainen's imaptest suite. imap-2007 using the mix format is
+ believed to pass imaptest completely.
+
+A new function, utf8_csvalidmap(), has been added for the benefit of
+Alpine to use in examining UTF-8 text and determining efficiently
+whether it can be downgraded to a legacy charset. If you develop an
+MUA, this may be useful for you too, although you'll have to read the
+source code to see how to use it. The purpose of the "not-CJK" bit is
+to prevent messages being downgraded to a CJK charset if all they have
+in that charset are some special punctuation.
+
+
+Updated: 5 September 2007
+
+imap-2006k is a maintenance release, consisting primarily of bugfixes to
+problems discovered in the release that affected a small number of users.
+
+The primary focus of this maintenance release is to correct deadlock
+issues. There were two major causes of the deadlocks:
+ . a change in imap-2006i attempted to resolve a glibc mutex-based
+ deadlock in imapd's signal handler, but ended up worsening the problem.
+ . a bug in the mbx driver, introduced as part of the UIDPLUS work in 2006,
+ applied an mbx-style lock briefly on a traditional UNIX format mailbox.
+ If the traditional UNIX format mailbox was already locked by some other
+ process, the result would be a deadlock of both processes.
+
+imapd's signal handling logic is rewritten to avoid the mutex issue, and
+the mbx driver is fixed so that mbx-style locks are only applied to mbx
+format mailboxes.
+
+imapd now supports the WITHIN extension.
+
+
+Updated: 14 June 2007
+
+imap-2006j is a maintenance release, consisting primarily of bugfixes to
+problems discovered in the release that affected a small number of users.
+
+
+Updated: 5 June 2007
+
+imap-2006i is a maintenance release, consisting primarily of bugfixes to
+problems discovered in the release that affected a small number of users.
+
+imapd now supports the CHILDREN and ESEARCH extensions.
+
+imapd's attempt to return COPYUID/APPENDUID information for a traditional
+UNIX (and MMDF) format mailbox when the mailbox is open by another process
+has been declared to be a failure and is now revoked. It was subject to a
+timing race, loss of which involved an expensive reset of the mailbox's UID
+regime. Any imapd COPY or APPEND to a traditional UNIX or MMDF format that
+is open by some other process will now no longer return COPYUID/APPEND.
+Although this is technically in violation of RFC 4315, there is a loophole
+in that document and the timing race/performance problem is worse.
+
+
+Updated: 4 April 2007
+
+imap-2006h is a maintenance release, consisting primarily of bugfixes to
+problems discovered in the release that affected a small number of users.
+
+
Updated: 30 March 2007
imap-2006g is a maintenance release, consisting primarily of bugfixes to
Modified: trunk/M/lib/imap/docs/SSLBUILD
===================================================================
--- trunk/M/lib/imap/docs/SSLBUILD 2008-07-26 16:30:01 UTC (rev 7491)
+++ trunk/M/lib/imap/docs/SSLBUILD 2008-07-26 17:00:21 UTC (rev 7492)
@@ -1,5 +1,5 @@
/* ========================================================================
- * Copyright 1988-2006 University of Washington
+ * Copyright 1988-2007 University of Washington
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -12,17 +12,17 @@
*/
SSL/TLS BUILD AND INSTALLATION NOTES FOR UNIX
- Last Updated: 20 August 2006
+ Last Updated: 15 November 2007
PREREQUISITES BEFORE STARTING:
- 1) Review the information in imap-2006/docs/BUILD.
+ 1) Review the information in imap-2007/docs/BUILD.
2) Obtain a copy of OpenSSL. OpenSSL is available from third parties. We
do not provide OpenSSL.
3) Make sure that you know how to build OpenSSL properly on the standard
/usr/local/ssl directory. In particular, /usr/local/ssl/include (and
/usr/local/ssl/include/openssl) and /usr/local/ssl/lib must be set up
from the OpenSSL build. If you have a non-standard installation, then
- you must modify the imap-2006/src/osdep/unix/Makefile file to point
+ you must modify the imap-2007/src/osdep/unix/Makefile file to point
to the appropriate locations.
4) Make sure that you know how to obtain appropriate certificates on your
system.
@@ -48,7 +48,7 @@
with RFC 3501.
There are other make options relevant to SSL, described in
- imap-2006/src/osdep/unix/Makefile
+ imap-2007/src/osdep/unix/Makefile
The most important of these are SSLDIR, SSLCRYPTO, and SSLRSA.
SSLDIR is set to /usr/local/ssl by default. This is the normal
@@ -70,10 +70,10 @@
SSL INSTALLATION:
Binaries from the build are:
- imap-2006/mtest/mtest c-client testbed program
- imap-2006/ipopd/ipop2d POP2 daemon
- imap-2006/ipopd/ipop3d POP3 daemon
- imap-2006/imapd/imapd IMAP4rev1 daemon
+ imap-2007/mtest/mtest c-client testbed program
+ imap-2007/ipopd/ipop2d POP2 daemon
+ imap-2007/ipopd/ipop3d POP3 daemon
+ imap-2007/imapd/imapd IMAP4rev1 daemon
mtest is normally not used except by c-client developers.
@@ -114,10 +114,10 @@
pop3s stream tcp nowait root /usr/local/etc/ipop3d ipop3d
imaps stream tcp nowait root /usr/local/etc/imapd imapd
- Please refer to imap-2006/docs/BUILD for an important note about inetd's
+ Please refer to imap-2007/docs/BUILD for an important note about inetd's
limit on the number of new connections. If that note applies to you, and you
can configure the number of connection in /etc/inetd.conf as described in
-imap-2006/docs/build, here is the sample /etc/inetd.conf entry with SSL:
+imap-2007/docs/build, here is the sample /etc/inetd.conf entry with SSL:
pop3 stream tcp nowait.100 root /usr/local/etc/ipop3d ipop3d
pop3s stream tcp nowait.100 root /usr/local/etc/ipop3d ipop3d
Modified: trunk/M/lib/imap/docs/bugs.txt
===================================================================
--- trunk/M/lib/imap/docs/bugs.txt 2008-07-26 16:30:01 UTC (rev 7491)
+++ trunk/M/lib/imap/docs/bugs.txt 2008-07-26 17:00:21 UTC (rev 7492)
@@ -1,5 +1,5 @@
/* ========================================================================
- * Copyright 1988-2006 University of Washington
+ * Copyright 1988-2007 University of Washington
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -12,9 +12,9 @@
*/
KNOWN BUGS/MISFEATURES/DEFICIENCIES IN THE IMAP TOOLKIT
- Last Updated: 30 August 2006
+ Last Updated: 15 November 2007
-The following are known problems/deficiencies in the imap-2006 toolkit:
+The following are known problems/deficiencies in the imap-2007 toolkit:
. Possible problems for some installations:
. In some versions of Redhat Linux, SVR4-style timezone name lookup
@@ -28,7 +28,7 @@
the SSLDIR variable, either by including a setting of EXTRASPECIALS
in the make command line, e.g.
build lnp SPECIALAUTHENTICATORS=ssl EXTRASPECIALS="SSLDIR=/usr/ssl"
- or by editing imap-2006/src/osdep/unix/Makefile
+ or by editing .../src/osdep/unix/Makefile
. /tmp, /usr/tmp or /var/tmp (if present), and the mail spool directory
must be protected 1777 (world write with sticky bit); otherwise
mailbox locking and updates won't work. An alternative to 1777 on
@@ -70,11 +70,11 @@
the public domain on September 6, 2000. There is no longer any need to
use RSAREF, and since RSAREF is slower than OpenSSL's RSA routines
there's good reason not to. If for some reason you still want to use
- RSAREF, you will need to edit imap-2006/src/osdep/unix/Makefile to
+ RSAREF, you will need to edit .../src/osdep/unix/Makefile to
change SSLRSA to load libRSAglue and librsaref.
. By default, the UNIX SSL build assumes that no name conflict exists
between OpenSSL and Kerberos 5. If you are using an older version
- of Kerberos, you may need to edit imap-2006/src/osdep/unix/Makefile
+ of Kerberos, you may need to edit .../src/osdep/unix/Makefile
to change SSLCRYPTO so that it loads the OpenSSL libcrypto library
explicitly as libcrypto.a.
. By default, host names are canonicalized via gethostbyname() and
@@ -97,25 +97,24 @@
. UIDPLUS bugs/limitations:
. Not supported in all local file formats (see below).
. There are two known issues with UIDPLUS in the mmdf and unix formats:
- (a) There is a known timing race if the destination mailbox is
- currently selected by a different IMAP server session. If the
- timing race is lost, then all UID in the mailbox will be reassigned
- by the IMAP session which has the mailbox selected (thus making the
- returned APPENDUID/COPYUID data useless).
- This timing race occurs if the IMAP server doing APPEND/COPY does
- multiple APPEND or COPY operations and the other IMAP server does
- not see each new message before the next APPEND/COPY happens.
- Aggregate COPY or MULTIAPPEND does not have this problem.
- This issue can be avoided by using aggregate COPY and MULTIAPPEND,
- or by inserting enough of a delay between separate copies so that
- the other session has an opportunity to see the new message.
+ (a) If the destination mailbox is currently selected (whether in this
+ or another session), no COPYUID or APPENDUID is returned. The other
+ choice was to assign a UID based upon the uid_last value and hope
+ that the session selecting the mailbox would pick it up and update
+ uid_last. The problem was a timing race if another message was
+ copied/appended to that mailbox before the selecting session updated
+ the mailbox. If the timing race is lost, then all UID in the mailbox
+ would be reassigned by the selecting session, thus making the
+ returned APPENDUID/COPYUID data useless and causing a performance
+ problem.
+ Earlier versions did the "hope for the best" method. This was
+ revoked in favor of not returning COPYUID/APPENDUID.
+ Although this violates RFC 4315, there is a loophole which, although
+ for other purposes, permits this behavior.
(b) There is a known failure if the destination mailbox is currently
selected by legacy software (e.g. older versions of the IMAP
server, Pine, etc.). In this case, all UIDs end up being
reassigned by the legacy software.
- Note that if Pine is rebuilt with imap-2006 version of the c-client
- library, it will not have the (b) issue but it will have the (a)
- issue.
. Annoyances:
. Friendly host names (e.g. "server" instead of "server.foo.com") can't be
@@ -143,8 +142,8 @@
. No support for enhanced status codes
. UNIX limitations:
- . IPv6 is supported but is not the default; you have to use IP=6 in the make
- command
+ . IPv6 is supported but is not the default on most platforms; you have to
+ use IP=6 in the make command
. Supported local file formats: mbx, mh, mmdf, mix, mtx, mx, news, phile,
tenex, unix
. Supported SASL mechanisms: CRAM-MD5, PLAIN, LOGIN, ANONYMOUS, GSSAPI
Modified: trunk/M/lib/imap/docs/draft/README
===================================================================
--- trunk/M/lib/imap/docs/draft/README 2008-07-26 16:30:01 UTC (rev 7491)
+++ trunk/M/lib/imap/docs/draft/README 2008-07-26 17:00:21 UTC (rev 7492)
@@ -1,4 +1,4 @@
-Last Updated: 15 March 2007
+Last Updated: 6 March 2008
This directory contains Internet Drafts which, at the time of release of
this software, were not yet been published as RFCs. These documents are
@@ -11,9 +11,9 @@
File Name I-D Name
--------- --------
-sort.txt draft-ietf-imapext-sort-19.txt
+sort.txt draft-ietf-imapext-sort-20.txt
;; SORT and THREAD commands
;; Status: approved, blocked waiting for i18n
-i18n.txt draft-ietf-imapext-i18n-10.txt
+i18n.txt draft-ietf-imapext-i18n-15.txt
;; internationalization in IMAP
Modified: trunk/M/lib/imap/docs/draft/i18n.txt
===================================================================
--- trunk/M/lib/imap/docs/draft/i18n.txt 2008-07-26 16:30:01 UTC (rev 7491)
+++ trunk/M/lib/imap/docs/draft/i18n.txt 2008-07-26 17:00:21 UTC (rev 7492)
@@ -1,3 +1,9 @@
+
+
+
+
+
+
Network Working Group Chris Newman
Internet-Draft Sun Microsystems
Intended Status: Proposed Standard Arnt Gulbrandsen
@@ -2,6 +8,8 @@
Oryx Mail Systems GmhH
- March 2007
+ Alexey Melnikov
+ Isode Limited
+ February 1, 2008
Internet Message Access Protocol Internationalization
- draft-ietf-imapext-i18n-10.txt
+ draft-ietf-imapext-i18n-15.txt
@@ -29,12 +37,12 @@
Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft expires in September 2007.
+ This Internet-Draft expires in August 2008.
Copyright Notice
- Copyright (C) The IETF Trust (2007).
+ Copyright (C) The IETF Trust (2008).
Abstract
@@ -44,16 +52,20 @@
substrings. It also supports non-ASCII message headers and content
encoded as specified by Multipurpose Internet Mail Extensions
(MIME). This specification defines a collection of IMAP extensions
- which improve international support including comparator negotiation
- for search, sort and thread, language negotiation for international
-Newman, Gulbrandsen Expires September 2007 [Page 1]
-
-Internet-draft March 2007
+Newman & Co Expires August 2008 FF[Page 1]
+
+
+
+Internet-draft February 2008
+
+
+ which improve international support including comparator negotiation
+ for search, sort and thread, language negotiation for international
error text, and translations for namespace prefixes.
@@ -64,15 +76,20 @@
3. LANGUAGE Extension . . . . . . . . . . . . . . . . . . . . . 3
3.1 LANGUAGE Extension Requirements . . . . . . . . . . . . . . . 3
3.2 LANGUAGE Command . . . . . . . . . . . . . . . . . . . . . . 4
- 3.3 LANGUAGE Response . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.3 LANGUAGE Response . . . . . . . . . . . . . . . . . . . . . . 6
3.4 TRANSLATION Extension to the NAMESPACE Response . . . . . . . 6
3.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6
- 4. COMPARATOR Extension . . . . . . . . . . . . . . . . . . . . 7
- 4.1 COMPARATOR Extension Requirements . . . . . . . . . . . . . . 8
- 4.2 Comparators and Charsets . . . . . . . . . . . . . . . . . . 8
- 4.3 COMPARATOR Command . . . . . . . . . . . . . . . . . . . . . 9
- 4.4 COMPARATOR Response . . . . . . . . . . . . . . . . . . . . . 10
- 4.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 4. I18NLEVEL=1 and I18NLEVEL=2 Extensions . . . . . . . . . . . 7
+ 4.1 Introduction and Overview . . . . . . . . . . . . . . . . . . 8
+ 4.2 Requirements common to both I18NLEVEL=1 and I18NLEVEL=2 . . .
+ 4.3 I18NLEVEL=1 Extension Requirements . . . . . . . . . . . . . 8
+ 4.4 I18NLEVEL=2 Extension Requirements . . . . . . . . . . . . . 8
+ 4.5 Compatibility Notes
+ 4.6 Comparators and Charsets . . . . . . . . . . . . . . . . . . 9
+ 4.7 COMPARATOR Command . . . . . . . . . . . . . . . . . . . . . 9
+ 4.8 COMPARATOR Response . . . . . . . . . . . . . . . . . . . . . 10
+ 4.9 BADCOMPARATOR Response Code . . . . . . . . . . . . . . . . .
+ 4.10 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 10
5. Other IMAP Internationalization Issues . . . . . . . . . . . 11
5.1 UTF-8 Userids and Passwords . . . . . . . . . . . . . . . . . 11
5.2 UTF-8 Mailbox Names . . . . . . . . . . . . . . . . . . . . . 11
@@ -95,6 +112,18 @@
The formal syntax use the Augmented Backus-Naur Form (ABNF)
[RFC4234] notation including the core rules defined in Appendix A.
+
+
+
+Newman & Co Expires August 2008 FF[Page 2]
+
+
+
+
+
+Internet-draft February 2008
+
+
The UTF8-related productions are defined in [RFC3629].
In examples, "C:" and "S:" indicate lines sent by the client and
@@ -104,12 +133,6 @@
exchange.
-
-Newman, Gulbrandsen Expires September 2007 [Page 2]
-
-Internet-draft March 2007
-
-
2. Introduction
This specification defines two IMAP4rev1 [RFC3501] extensions to
@@ -120,11 +143,10 @@
language for protocol error messages and in combination with the
NAMESPACE extension [RFC2342] enables namespace translations.
- The COMPARATOR extension allows the client to request a suitable
- comparator which will modify the behavior of the base
- specification's SEARCH command as well as the SORT and THREAD
- extensions [SORT]. This leverages the comparator registry
- [RFC4790].
+ The I18NLEVEL=2 extension allows the client to request a suitable
+ collation which will modify the behavior of the base specification's
+ SEARCH command as well as the SORT and THREAD extensions [SORT].
+ This leverages the collation registry [RFC4790].
3. LANGUAGE Extension
@@ -150,6 +172,18 @@
CAPABILITY data.
A server that advertises this extension MUST use the language "i-
+
+
+
+Newman & Co Expires August 2008 FF[Page 3]
+
+
+
+
+
+Internet-draft February 2008
+
+
default" as described in [RFC2277] as its default language until
another supported language is negotiated by the client. A server
MUST include "i-default" as one of its supported languages.
@@ -157,15 +191,18 @@
Clients and servers that support this extension MUST also support
the NAMESPACE extension [RFC2342].
- The LANGUAGE command is valid in all states.
+ The LANGUAGE command is valid in all states. Clients are urged to
+ issue LANGUAGE before authentication, since some servers send
+ valuable user information as part of authentication (e.g. "password
+ is correct, but expired"). If a security layer (such as SASL or
+ TLS) is subsequently negotiated by the client, it MUST re-issue the
+ LANGUAGE command in order to make sure that no previous active
+ attack (if any) on LANGUAGE negotiation has effect on subsequent
+ error messages. (See Section 7 for a more detailed explanation of
+ the attack.)
-Newman, Gulbrandsen Expires September 2007 [Page 3]
-
-Internet-draft March 2007
-
-
3.2 LANGUAGE Command
Arguments: Optional language range arguments.
@@ -179,7 +216,7 @@
The LANGUAGE command requests that human-readable text emitted by
the server be localized to a language matching one of the language
- range argument as described by section 2.5 of RFC 3066.
+ range argument as described by section 2 of [RFC4647].
If the command succeeds, the server will return human-readable
responses in the first supported language specified. These
@@ -190,11 +227,23 @@
If the command fails, the server continues to return human-readable
responses in the language it was previously using.
- The special "*" language range argument indicates a request to use a
- language designated as preferred by the server administrator. The
- preferred language MAY vary based on the currently active user.
+ The special "default" language range argument indicates a request to
+ use a language designated as preferred by the server administrator.
+ The preferred language MAY vary based on the currently active user.
If a language range does not match a known language tag exactly but
+
+
+
+Newman & Co Expires August 2008 FF[Page 4]
+
+
+
+
+
+Internet-draft February 2008
+
+
does match a language by the rules of [RFC4647], the server MUST
send an untagged LANGUAGE response indicating the language selected.
@@ -214,14 +263,6 @@
C: A002 LANGUAGE MUL
S: A002 NO Unsupported language MUL
-
-
-
-Newman, Gulbrandsen Expires September 2007 [Page 4]
-
-Internet-draft March 2007
-
-
< A LANGUAGE command with no arguments is a request to enumerate
the list of languages the server supports. >
@@ -242,7 +283,7 @@
S: * LANGUAGE (DE)
S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
- "TRANSLATION" ("Gemeinsame Mailboxen/")))
+ "TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
< If a server does not support the requested primary language,
@@ -251,13 +292,25 @@
C: D001 LANGUAGE FR
S: D001 NO Diese Sprache ist nicht unterstuetzt
+
+
+
+Newman & Co Expires August 2008 FF[Page 5]
+
+
+
+
+
+Internet-draft February 2008
+
+
C: D002 LANGUAGE DE-IT
S: * LANGUAGE (DE-IT)
S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
- "TRANSLATION" ("Gemeinsame Mailboxen/")))
+ "TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: D002 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
- C: D003 LANGUAGE "*"
+ C: D003 LANGUAGE "default"
S: * LANGUAGE (DE)
S: D003 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
@@ -270,14 +323,6 @@
-
-
-
-Newman, Gulbrandsen Expires September 2007 [Page 5]
-
-Internet-draft March 2007
-
-
3.3 LANGUAGE Response
Contents: A list of one or more language tags.
@@ -307,12 +352,24 @@
Users" to its Other Users' Namespace and a prefix of "Public
Folders" to its only Shared Namespace. Since a client will often
display these prefixes to the user, the server includes a
+
+
+
+Newman & Co Expires August 2008 FF[Page 6]
+
+
+
+
+
+Internet-draft February 2008
+
+
translation of them that can be presented to the user.
C: A001 LANGUAGE DE-IT
S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
- "TRANSLATION" ("Gemeinsame Mailboxen/")))
+ "TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: A001 OK LANGUAGE-Befehl ausgefuehrt
@@ -320,29 +377,23 @@
The following syntax specification inherits ABNF [RFC4234] rules
from IMAP4rev1 [RFC3501], IMAP4 Namespace [RFC2342], Tags for the
- Identifying Languages [RFC4646], and UTF-8 [RFC3629].
+ Identifying Languages [RFC4646], UTF-8 [RFC3629] and Collected
+ Extensions to IMAP4 ABNF [RFC4466].
command-any =/ language-cmd
; LANGUAGE command is valid in all states
language-cmd = "LANGUAGE" *(SP lang-range-quoted)
+ response-payload =/ language-data
+ language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP
+ lang-tag-quoted) ")"
-Newman, Gulbrandsen Expires September 2007 [Page 6]
-
-Internet-draft March 2007
-
-
- response-payload =/ language-data / comparator-data
-
- language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP lang-tag-
- quoted) ")"
-
namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")"
; the string is encoded in Modified UTF-7.
; this is a subset of the syntax permitted by
- ; the Namespace_Response_Extension rule in [RFC2342]
+ ; the Namespace-Response-Extension rule in [RFC4466]
lang-range-quoted = astring
; Once any literal wrapper or quoting is removed, this
@@ -362,8 +413,22 @@
; UTF-8 excluding 7-bit control characters and "["
-4. COMPARATOR Extension
+
+Newman & Co Expires August 2008 FF[Page 7]
+
+
+
+
+
+Internet-draft February 2008
+
+
+4. I18NLEVEL=1 and I18NLEVEL=2 Extensions
+
+
+4.1 Introduction and Overview
+
IMAP4rev1 [RFC3501] includes the SEARCH command which can be used to
locate messages matching criteria including human-readable text.
The SORT extension [SORT] to IMAP allows the client to ask the
@@ -371,24 +436,31 @@
including human-readable text. These mechanisms require the ability
to support non-English search and sort functions.
- This section defines an IMAP extension to negotiate use of
- comparators [RFC4790] to internationalize IMAP SEARCH, SORT and
- THREAD. The IMAP extension consists of a new command to determine
- or change the active comparator and a new response to indicate the
- active comparator and possibly other available comparators.
+ Section 4 defines two IMAP extensions for internationalizing IMAP
+ SEARCH, SORT and THREAD [SORT] using the comparator framework
+ [RFC4790].
- The term "default comparator" refers to the comparator which is used
- by SEARCH and SORT absent any negotiation using the COMPARATOR
- command. The term "active comparator" refers to the comparator
- which will be used within a session e.g. by SEARCH and SORT. The
- COMPARATOR command is used to change the active comparator.
+ The I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use
+ i;unicode-casemap comparator, as defined in [UCM]. See Sections 4.2
+ and 4.3 for more details.
+ The I18NLEVEL=2 extension is a superset of the I18NLEVEL=1
+ extension. It adds to I18NLEVEL=1 extension the ability to determine
+ the active comparator (see definition below) and negotiate use of
+ comparators using the COMPARATOR command. It also adds the
+ COMPARATOR response that indicates the active comparator and
+ possibly other available comparators. See Sections 4.2 and 4.4 for
+ more details.
-Newman, Gulbrandsen Expires September 2007 [Page 7]
-
-Internet-draft March 2007
+4.2 Requirements common to both I18NLEVEL=1 and I18NLEVEL=2
+ The term "default comparator" refers to the comparator which is used
+ by SEARCH and SORT absent any negotiation using the COMPARATOR (see
+ Section 4.7) command. The term "active comparator" refers to the
+ comparator which will be used within a session e.g. by SEARCH and
+ SORT. The COMPARATOR command is used to change the active
+ comparator.
The active comparator applies to the following SEARCH keys: "BCC",
"BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO" and "HEADER". If the
@@ -401,113 +473,271 @@
REFERENCES threading algorithm. Future extensions may choose to
apply the active comparator to their SEARCH keys.
+
+
+Newman & Co Expires August 2008 FF[Page 8]
+
+
+
+
+
+Internet-draft February 2008
+
+
For SORT and THREAD, the pre-processing necessary to extract the
base subject text from a Subject header occurs prior to the
application of a comparator.
+ A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST
+ implement the i;unicode-casemap comparator, as defined in [UCM].
-4.1 COMPARATOR Extension Requirements
+ A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST
+ support UTF-8 as a SEARCH charset.
- IMAP servers that support this extension MUST list the keyword
- COMPARATOR in their CAPABILITY data once IMAP enters authenticated
- state, and MAY list that keyword in other states.
- A server that advertises this extension MUST implement the i;ascii-
- casemap and i;octet comparators, as defined in [RFC4790]. A server
- intended to be deployed globally MUST implement the i;unicode-
- casemap comparator, as defined in [UCM].
+4.3 I18NLEVEL=1 Extension Requirements
- A server that advertises this extension SHOULD use i;ascii-casemap
- as the default comparator. The selection of the default comparator
- MAY be adjustable by the server administrator, and MAY be sensitive
- to the current user. Once the IMAP connection enters authenticated
- state, the default comparator MUST remain static for the remainder
- of that connection.
+ An IMAP server that satisfies all requirements specified in sections
+ 4.2 and 4.6 (and doesn't support/advertise any other I18NLEVEL=<n>
+ extension, where n > 1) MUST list the keyword I18NLEVEL=1 in its
+ CAPABILITY data once IMAP enters the authenticated state, and MAY
+ list that keyword in other states.
- A server that advertises this extension MUST support UTF-8 as a
- SEARCH charset.
- The COMPARATOR command is valid in authenticated and selected
- states.
+4.4 I18NLEVEL=2 Extension Requirements
-4.2 Comparators and Character Encodings
+ IMAP server that satisfies all requirements specified in sections
+ 4.2, 4.4, 4.6-4.10 (and doesn't support/advertise any other
+ I18NLEVEL=<n> extension, where n > 2) MUST list the keyword
+ I18NLEVEL=2 in its CAPABILITY data once IMAP enters the
+ authenticated state, and MAY list that keyword in other states.
- When SEARCH, SORT, THREAD or another command needs to perform
- collation operations on messages (or on the command's arguments),
- the server MUST remove MIME encoding (see [RFC2047] for headers and
- [RFC2045] for bodyparts) and convert character encodings compatibly
- before doing the collation operation.
+ A server that advertises this extension MUST implement the
+ i;unicode-casemap comparator, as defined in [UCM]. It MAY implement
+ other comparators from the IANA registry established by [RFC4790].
+ See also section 4.5 of this document.
+ A server that advertises this extension SHOULD use i;unicode-casemap
+ as the default comparator. (Note that i;unicode-casemap is the
+ default comparator for I18NLEVEL=1, but not necessarily the default
+ for I18NLEVEL=2.) The selection of the default comparator MAY be
+ adjustable by the server administrator, and MAY be sensitive to the
+ current user. Once the IMAP connection enters authenticated state,
+ the default comparator MUST remain static for the remainder of that
+ connection.
+ Note that since SEARCH uses the substring operation, IMAP servers
+ can only implement collations that offer the substring operation
+ (see [RFC4790 section 4.2.2). Since SORT uses ordering operation
+ (and by implication equality), IMAP servers which advertise the SORT
+ extension can only implement collations that offer all three
-Newman, Gulbrandsen Expires September 2007 [Page 8]
-
-Internet-draft March 2007
- Strings encoded using unknown character encodings should never match
- when using the SEARCH command, and should sort together with invalid
- input for the SORT and THREAD commands.
+Newman & Co Expires August 2008 FF[Page 9]
-4.3 COMPARATOR Command
+
+
+Internet-draft February 2008
+
+
+ operations (see [RFC4790] sections 4.2.2-4).
+
+ If the active collation does not provide the operations needed by an
+ IMAP command, the server MUST respond with a tagged BAD.
+
+
+4.5 Compatibility Notes
+
+ Several server implementations deployed prior to the publication of
+ this specification comply with I18NLEVEL=1 (see section 4.3), but do
+ not advertise that. Other legacy servers use the i;ascii-casemap
+ (see [RFC4790]) comparator.
+
+ There is no good way for a client to know which comparator that a
+ legacy server uses. If the client has to assume the worst, it may
+ end up doing expensive local operations to obtain i;unicode-casemap
+ comparisons even though the server implements it.
+
+ Legacy server implementations which comply with I18NLEVEL=1 should
+ be updated to advertise I18NLEVEL=1. All server implementations
+ should eventually be updated to comply with the I18NLEVEL=2
+ extension.
+
+
+4.6 Comparators and Character Encodings
+
+ RFC 3501, section 6.4.4 says:
+
+ In all search keys that use strings, a message matches
+ the key if the string is a substring of the field. The
+ matching is case-insensitive.
+
+ When performing the SEARCH operation, the active comparator is
+ applied instead of the case-insensitive matching specified above.
+
+ An IMAP server which performs collation operations (e.g., as part of
+ commands such as SEARCH, SORT, THREAD) does so according to the
+ following procedure:
+
+ (a) MIME encoding (for example see [RFC2047] for headers and
+ [RFC2045] for body parts) MUST be removed in the texts being
+ collated.
+
+ If MIME encoding removal fails for a message (e.g., a body part
+ of the message has an unsupported Content-Transfer-Encoding,
+ uses characters not allowed by the Content-Transfer-Encoding,
+ etc.), the collation of this message is undefined by this
+ specification, and is handled in an implementation-dependent
+
+
+
+Newman & Co Expires August 2008 FF[Page 10]
+
+
+
+
+
+Internet-draft February 2008
+
+
+ manner.
+
+ (b) The decoded text from (a) MUST be converted to the charset
+ expected by the active comparator.
+
+ (c) For the substring operation:
+ If step (b) failed (e.g., the text is in an unknown charset,
+ contains a sequence which is not valid according in that
+ charset, etc.), the original decoded text from (a) (i.e.,
+ before the charset conversion attempt) is collated using the
+ i;octet comparator (see [RFC4790]).
+
+ If step (b) was successful, the converted text from (b) is
+ collated according to the active comparator.
+
+
+ For the ordering operation:
+
+ All strings that were successfully converted by step (b) are
+ separated from all strings that failed step (b). Strings in
+ each group are collated independently. All strings successfully
+ converted by step (b) are then validated by the active
+ comparator. Strings that pass validation are collated using the
+ active comparator. All strings that either fail step (b) or fail
+ the active collation's validity operation are collated (after
+ applying step (a)) using the i;octet comparator (see [RFC4790]).
+ The resulting sorted list is produced by appending all collated
+ "failed" strings after all strings collated using the active
+ comparator.
+
+
+ Example: The following example demonstrates ordering of 4
+ different strings using i;unicode-casemap [UCM] comparator.
+ Strings are represented using hexadecimal notation used by
+ ABNF [RFC4234].
+
+ (1) %xD0 %xC0 %xD0 %xBD %xD0 %xB4 %xD1 %x80 %xD0 %xB5
+ %xD0 %xB9 (labeled with charset=UTF-8)
+ (2) %xD1 %x81 %xD0 %x95 %xD0 %xA0 %xD0 %x93 %xD0 %x95
+ %xD0 %x99 (labeled with charset=UTF-8)
+ (3) %xD0 %x92 %xD0 %xB0 %xD1 %x81 %xD0 %xB8 %xD0 %xBB
+ %xD0 %xB8 %xFF %xB9 (labeled with charset=UTF-8)
+ (4) %xE1 %xCC %xC5 %xCB %xD3 %xC5 %xCA (labeled with
+ charset=KOI8-R)
+
+ Step (b) will convert string # 4 to the following
+ sequence of octets (in UTF-8):
+
+
+
+
+Newman & Co Expires August 2008 FF[Page 11]
+
+
+
+
+
+Internet-draft February 2008
+
+
+ %xD0 %x90 %xD0 %xBB %xD0 %xB5 %xD0 %xBA %xD1 %x81 %xD0
+ %xB5 %xD0 %xB9
+
+ and will reject strings (1) and (3), as they contain
+ octets not allowed in charset=UTF-8.
+ After that, using the i;unicode-casemap collation,
+ string (4) will collate before string (2). Using the
+ i;octet collation on the original strings, string (3)
+ will collate before string (1). So the final ordering
+ is as follows: (4) (2) (3) (1).
+
+ If the substring operation (e.g., IMAP SEARCH) of the active
+ comparator returns the "undefined" result (see section 4.2.3 of
+ [RFC4790]) for either the text specified in the SEARCH command or
+ the message text, then the operation is repeated on the result of
+ step (a) using the i;octet comparator.
+
+ The ordering operation (e.g., IMAP SORT and THREAD) SHOULD collate
+ the following together: strings encoded using unknown or invalid
+ character encodings, strings in unrecognized charsets, and invalid
+ input (as defined by the active collation).
+
+
+
+4.7 COMPARATOR Command
+
Arguments: Optional comparator order arguments.
- Response: A possible COMPARATOR response (see Section 4.4).
+ Response: A possible COMPARATOR response (see Section 4.8).
Result: OK - Command completed
NO - No matching comparator found
BAD - arguments invalid
+ The COMPARATOR command is valid in authenticated and selected
+ states.
+
The COMPARATOR command is used to determine or change the active
comparator. When issued with no arguments, it results in a
COMPARATOR response indicating the currently active comparator.
- When issued with one or more comparator order argument, it will
- change the active comparator if any comparator matches any argument.
- The COMPARATOR response will list other matching comparators if more
- than one matches the specified patterns.
- The argument "*" refers to the server's default comparator.
- Otherwise each argument is an comparator specification as defined in
- the Internet Application Protocol Comparator Registry [RFC4790].
+ When issued with one or more comparator argument, it changes the
+ active comparator as directed. (If more than one installed
+ comparator is matched by an argument, the first argument wins.) The
+ COMPARATOR response lists all matching comparators if more than one
+ matches the specified patterns.
- < The client requests activating a Czech comparator if possible,
- or else a generic international comparator which it considers
- suitable for Czech. The server picks the first supported
- comparator. >
+ The argument "default" refers to the server's default comparator.
- C: A001 COMPARATOR cz;* i;basic
- S: * COMPARATOR i;basic
- S: A001 OK Will use i;basic for collation
- < The client requests pure octet matching, then does a search
- for potential GIF files, then switches back to its usual
- comparator. Note that this may not work on all IMAP servers,
- see RFC 3501, page 50, second paragraph. >
+Newman & Co Expires August 2008 FF[Page 12]
- C: B123 COMPARATOR i;octet
- S: * COMPARATOR i;octet
- S: B123 OK
- C: B124 SEARCH OR BODY GIF87A BODY GIF89A
- S: * SEARCH 42 69
- S: B124 OK
-Newman, Gulbrandsen Expires September 2007 [Page 9]
-
-Internet-draft March 2007
+Internet-draft February 2008
- C: B125 COMPARATOR cz;* i;basic
+
+ Otherwise each argument is an collation specification as defined in
+ the Internet Application Protocol Comparator Registry [RFC4790].
+
+ < The client requests activating a Czech comparator if possible,
+ or else a generic international comparator which it considers
+ suitable for Czech. The server picks the first supported
+ comparator. >
+
+ C: A001 COMPARATOR "cz;*" i;basic
S: * COMPARATOR i;basic
- S: B125 OK.
+ S: A001 OK Will use i;basic for collation
-4.4 COMPARATOR Response
+4.8 COMPARATOR Response
Contents: The active comparator.
An optional list of available matching comparators
@@ -519,45 +749,54 @@
present only if more than one match is found.
-4.5 Formal Syntax
+4.9 BADCOMPARATOR response code
+ This response code SHOULD be returned as a result of server failing
+ an IMAP command (returning NO), when the server knows that none of
+ the specified comparators match the requested comparator(s).
+
+
+4.10 Formal Syntax
+
The following syntax specification inherits ABNF [RFC4234] rules
from IMAP4rev1 [RFC3501], and Internet Application Protocol
Comparator Registry [RFC4790].
command-auth =/ comparator-cmd
- resp-text-code =/ "BADCOMPARATOR" / "BADMATCH"
+ resp-text-code =/ "BADCOMPARATOR"
comparator-cmd = "COMPARATOR" *(SP comp-order-quoted)
+ response-payload =/ comparator-data
+
comparator-data = "COMPARATOR" SP comp-sel-quoted [SP "("
- comp-name-quoted *(SP comp-name-quoted) ")"]
+ comp-id-quoted *(SP comp-id-quoted) ")"]
- comp-name-quoted = astring
- ; Once any literal wrapper or quoting is removed, this
- ; follows the collation-name rule from [RFC4790]
- comp-order-quoted = astring
- ; Once any literal wrapper or quoting is removed, this
- ; follows the collation-order rule from [RFC4790]
- comp-sel-quoted = astring
- ; Once any literal wrapper or quoting is removed, this
- ; follows the collation-sel rule from [RFC4790]
+Newman & Co Expires August 2008 FF[Page 13]
+Internet-draft February 2008
+ comp-id-quoted = astring
+ ; Once any literal wrapper or quoting is removed, this
+ ; follows the collation-id rule from [RFC4790]
-Newman, Gulbrandsen Expires September 2007 [Page 10]
-
-Internet-draft March 2007
+ comp-order-quoted = astring
+ ; Once any literal wrapper or quoting is removed, this
+ ; follows the collation-order rule from [RFC4790]
+ comp-sel-quoted = astring
+ ; Once any literal wrapper or quoting is removed, this
+ ; follows the collation-selected rule from [RFC4790]
+
5. Other IMAP Internationalization Issues
The following sections provide an overview of various other IMAP
@@ -568,7 +807,7 @@
5.1 Unicode Userids and Passwords
- IMAP4rev1 presently restricts the userid and password fields of the
+ IMAP4rev1 currently restricts the userid and password fields of the
LOGIN command to US-ASCII. The "userid" and "password" fields of the
IMAP LOGIN command are restricted to US-ASCII only until a future
standards track RFC states otherwise. Servers are encouraged to
@@ -593,6 +832,18 @@
non-interoperability.
The requirements in section 5.1 of RFC 3501 are very important if
+
+
+
+Newman & Co Expires August 2008 FF[Page 14]
+
+
+
+
+
+Internet-draft February 2008
+
+
we're ever going to be able to deploy UTF-8 mailbox names. Servers
are encouraged to enforce them.
@@ -604,16 +855,6 @@
standard, an argument can be made that it would be helpful to simple
clients if the IMAP server could perform this conversion (the same
argument would apply to MIME header encoding [RFC2047]). However,
-
-
-
-
-
-Newman, Gulbrandsen Expires September 2007 [Page 11]
-
-Internet-draft March 2007
-
-
it would be unwise to move forward with such work until the work in
progress to define the format of international email addresses is
complete.
@@ -621,9 +862,9 @@
6. IANA Considerations
- The IANA is requested to add LANGUAGE and COMPARATOR to the IMAP
- Extensions registry,
- http://www.iana.org/assignments/imap4-capabilities.
+ The IANA is requested to add LANGUAGE, I18NLEVEL=1 and I18NLEVEL=2
+ to the IMAP4 Capabilities Registry. [Note to IANA:
+ http://www.iana.org/assignments/imap4-capabilities]
7. Security Considerations
@@ -644,35 +885,38 @@
issue the LANGUAGE command once a security layer is active, so this
does not impact subsequent protocol operations.
- Both the LANGUAGE and COMPARATOR extensions use the UTF-8 charset,
- thus the security considerations for UTF-8 [RFC3629] are relevent.
- However, neither uses UTF-8 for identifiers so the most serious
- concerns do not apply.
+ LANGUAGE, I18NLEVEL=1 and I18NLEVEL=2 extensions use the UTF-8
+ charset, thus the security considerations for UTF-8 [RFC3629] are
+ relevent. However, neither uses UTF-8 for identifiers so the most
+ serious concerns do not apply.
8. Acknowledgements
- The LANGUAGE extension is based on a previous Internet draft by Mike
- Gahrns and Alexey Melnikov, a substantial portion of the text in
- that section was written by them. Many people have participated in
- discussions about an IMAP Language extension in the various fora of
- the IETF and Internet working groups, so any list of contributors is
- bound to be incomplete. However, the authors would like to thank
- Andrew McCown for early work on the original proposal, John Myers
- for suggestions regarding the namespace issue, along with Jutta
- Degener, Mark Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo
- and Martin Duerst for their many suggestions that have been
+Newman & Co Expires August 2008 FF[Page 15]
-Newman, Gulbrandsen Expires September 2007 [Page 12]
-
-Internet-draft March 2007
- incorporated into this document.
- Initial discussion of the COMPARATOR extension involved input from
+
+Internet-draft February 2008
+
+
+ The LANGUAGE extension is based on a previous Internet draft by Mike
+ Gahrns, a substantial portion of the text in that section was
+ written by him. Many people have participated in discussions about
+ an IMAP Language extension in the various fora of the IETF and
+ Internet working groups, so any list of contributors is bound to be
+ incomplete. However, the authors would like to thank Andrew McCown
+ for early work on the original proposal, John Myers for suggestions
+ regarding the namespace issue, along with Jutta Degener, Mark
+ Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo, Martin Duerst,
+ Timo Sirainen, Ben Campbell and Magnus Nystrom for their many
+ suggestions that have been incorporated into this document.
+
+ Initial discussion of the I18NLEVEL=2 extension involved input from
Mark Crispin and other participants of the IMAP Extensions WG.
@@ -681,7 +925,7 @@
This is a non-normative list of standards to consider when
implementing i18n aware IMAP software.
- o The LANGUAGE and COMPARATOR extensions to IMAP (this
+ o The LANGUAGE and I18NLEVEL=2 extensions to IMAP (this
specification).
o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501.
o The Mailbox International Naming Convention in section 5.1.3 of
@@ -695,7 +939,7 @@
BODYSTRUCTURE. There is also some deployed non-standard use of
MIME header encoding inside double-quotes for filenames.
o IDNA [RFC3490] and punycode [RFC3492] for domain names
- (presently only relevant to IMAP clients).
+ (currently only relevant to IMAP clients).
o The UTF-8 charset [RFC3629].
o The IETF policy on Character Sets and Languages [RFC2277].
@@ -708,6 +952,18 @@
[RFC2277] Alvestrand, "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
+
+
+
+Newman & Co Expires August 2008 FF[Page 16]
+
+
+
+
+
+Internet-draft February 2008
+
+
[RFC2342] Gahrns, Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[RFC3501] Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
@@ -718,19 +974,14 @@
[RFC4234] Crocker, Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, Brandenburg
-
-
-
-Newman, Gulbrandsen Expires September 2007 [Page 13]
-
-Internet-draft March 2007
-
-
Internetworking, Demon Internet Ltd, October 2005.
[RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security
Layer (SASL)", RFC 4422, June 2006.
+ [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF",
+ RFC 4466, Isode Ltd., April 2006.
+
[RFC4646] Philips, Davis, "Tags for Identifying Languages", BCP 47,
RFC 4646, September 2006.
@@ -738,10 +989,14 @@
4647, September 2006.
[RFC4790] Newman, Duerst, Gulbrandsen, "Internet Application
- Protocol Comparator Registry", RFC 4790, February 2007
+ Protocol Comparator Registry", RFC 4790, February 2007.
+ [SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS
+ PROTOCOL - SORT AND THREAD EXTENSION", draft-ietf-
+ imapext-sort-19 (work in progress), November 2006.
-Informative References
+ [UCM] Crispin, "i;unicode-casemap - Simple Unicode Collation
+ Algorithm", RFC 5051, October 2007.
[RFC2045] Freed, Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies", RFC
@@ -751,39 +1006,38 @@
Three: Message Header Extensions for Non-ASCII Text", RFC
2047, November 1996.
+
+Informative References
+
+
[RFC2231] Freed, Moore, "MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and
- Continuations", RFC 2231, November 1997.
- [RFC3490] Faltstrom, Hoffman, Costello, "Internationalizing Domain
- Names in Applications (IDNA)", RFC 3490, March 2003.
- [RFC3492] Costello, "Punycode: A Bootstring encoding of Unicode for
- Internationalized Domain Names in Applications (IDNA)",
- RFC 3492, March 2003.
- [SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS
- PROTOCOL - SORT AND THREAD EXTENSION", draft-ietf-
- imapext-sort-17 (work in progress), May 2004.
+Newman & Co Expires August 2008 FF[Page 17]
- [METADATA] Daboo, C., "IMAP METADATA Extension", draft-daboo-imap-
- annotatemore-10 (work in progress), November 2006.
- [UCM] Crispin,, "i;unicode-casemap - Simple Unicode Collation
- Algorithm", draft-crispin-collation-unicasemap-00.txt,
- December 2006.
+Internet-draft February 2008
-Newman, Gulbrandsen Expires September 2007 [Page 14]
-
-Internet-draft March 2007
+ Continuations", RFC 2231, November 1997.
+ [RFC3490] Faltstrom, Hoffman, Costello, "Internationalizing Domain
+ Names in Applications (IDNA)", RFC 3490, March 2003.
+ [RFC3492] Costello, "Punycode: A Bootstring encoding of Unicode for
+ Internationalized Domain Names in Applications (IDNA)",
+ RFC 3492, March 2003.
+
+ [METADATA] Daboo, C., "IMAP METADATA Extension", draft-daboo-imap-
+ annotatemore-12 (work in progress), December 2007.
+
[IMAP-EAI] Resnick, Newman, "IMAP Support for UTF-8", draft-ietf-
- iea-imap-utf8 (work in progress), May 2006.
+ eai-imap-utf8 (work in progress), May 2006.
@@ -809,63 +1063,55 @@
Fax: +49 89 4502 9758
+ Alexey Melnikov
+ Isode Limited
+ 5 Castle Business Village, 36 Station Road,
+ Hampton, Middlesex, TW12 2BX, UK
+ Email: [email protected]
+Newman & Co Expires August 2008 FF[Page 18]
+Internet-draft February 2008
-
-
-
-
-
-
-
-
-
-
-Newman, Gulbrandsen Expires September 2007 [Page 15]
-
-Internet-draft March 2007
-
-
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed
- to pertain to the implementation or use of the technology described
- in this document or the extent to which any license under such
- rights might or might not be available; nor does it represent that
- it has made any independent effort to identify any such rights.
- Information on the procedures with respect to rights in RFC
- documents can be found in BCP 78 and BCP 79.
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use
- of such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository
- at http://www.ietf.org/ipr.
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- [email protected].
+ this standard. Please address the information to the IETF at
+ [email protected].
Full Copyright Statement
- Copyright (C) The IETF Trust (2007). This document is subject to
+ Copyright (C) The IETF Trust (2008). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
@@ -889,5 +1135,6 @@
-Newman, Gulbrandsen Expires September 2007 [Page 16]
-
\ No newline at end of file
+Newman & Co Expires August 2008 FF[Page 19]
+
+
Modified: trunk/M/lib/imap/docs/draft/sort.txt
===================================================================
--- trunk/M/lib/imap/docs/draft/sort.txt 2008-07-26 16:30:01 UTC (rev 7491)
+++ trunk/M/lib/imap/docs/draft/sort.txt 2008-07-26 17:00:21 UTC (rev 7492)
@@ -1,13 +1,9 @@
-
-
-
-
-
IMAP Extensions Working Group M. Crispin
-INTERNET-DRAFT: IMAP SORT K. Murchison
-Document: internet-drafts/draft-ietf-imapext-sort-19.txt November 2006
+Internet-Draft K. Murchison
+Intended status: Proposed Standard March 10, 2008
+Expires: September 10, 2008
+Document: internet-drafts/draft-ietf-imapext-sort-20.txt
-
INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS
Status of this Memo
@@ -34,16 +30,13 @@
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- A revised version of this document will be submitted to the RFC
- editor as an Informational Document for the Internet Community.
-
A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to
- [email protected]. This document will expire before 20 May 2007.
+ [email protected].
+
Distribution of this memo is unlimited.
-
Abstract
This document describes the base-level server-based sorting and
@@ -51,7 +44,6 @@
provide substantial performance improvements for IMAP clients which
offer sorted and threaded views.
-
1. Introduction
The SORT and THREAD extensions to the [IMAP] protocol provide a means
@@ -69,10 +61,23 @@
supported threading algorithm name as described in this document.
This provides for future upwards-compatible extensions.
- A server which implements the SORT and/or THREAD extensions SHOULD
- also implement the COMPARATOR extension as described in [IMAP-I18N].
+ A server which implements the SORT and/or THREAD extensions MUST
+ collate strings in accordance with the requirements of I18NLEVEL=1,
+ as described in [IMAP-I18N], and SHOULD implement and advertise the
+ I18NLEVEL=1 extension. Alternatively, a server MAY implement
+ I18NLEVEL=2 (or higher) and comply with the rules of that level.
+ Discussion: the SORT and THREAD extensions predate [IMAP-I18N] by
+ several years. At the time of this writing, all known server
+ implementations of SORT and THREAD comply with the rules of
+ I18NLEVEL=1, but do not necessarily advertise it. As discussed
+ in [IMAP-I18N] section 4.5, all server implementations should
+ eventually be updated to comply with the I18NLEVEL=2 extension.
+ Historical note: the REFERENCES threading algorithm is based on the
+ [THREADING] algorithm written used in "Netscape Mail and News"
+ versions 2.0 through 3.0.
+
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -89,7 +94,6 @@
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
-
2.1 Base Subject
Subject sorting and threading use the "base subject," which has
@@ -132,7 +136,6 @@
Otherwise there is potential for a user to get inconsistent results
based on whether they are running in connected or disconnected mode.
-
2.2 Sent Date
As used in this document, the term "sent date" refers to the date and
@@ -149,7 +152,14 @@
(described in [IMAP] section 6.4.4), which use just the date and not
the time, and are not adjusted by time zone.
+ If the sent date can not be determined (a Date: header is missing or
+ can not be parsed), the INTERNALDATE for that message is used as the
+ sent date.
+ When comparing two sent dates that match exactly, the order in which
+ the two messages appear in the mailbox (that is, by sequence number)
+ is used as a tie-breaker to determine the order.
+
3. Additional Commands
These commands are extension to the [IMAP] base protocol.
@@ -229,9 +239,7 @@
[IMAP] addr-mailbox of the first "cc" address.
DATE
- Sent date and time from the Date: header, adjusted by time
- zone. This differs from the SENTON criteria in SEARCH, which
- uses just the date and not the time, nor adjusts by time zone.
+ Sent date and time, as described in section 2.2.
FROM
[IMAP] addr-mailbox of the first "From" address.
@@ -258,7 +266,6 @@
TO
[IMAP] addr-mailbox of the first "To" address.
-
Example: C: A282 SORT (SUBJECT) UTF-8 SINCE 1-Feb-1994
S: * SORT 2 84 882
S: A282 OK SORT completed
@@ -269,7 +276,6 @@
S: * SORT
S: A284 OK SORT completed
-
BASE.6.4.THREAD. THREAD Command
Arguments: threading algorithm
@@ -333,34 +339,20 @@
message at the root. Hence, there are no grandchildren in
ORDEREDSUBJECT threading.
- Note: early drafts of this specification specified
- that each message in an ORDEREDSUBJECT thread is a child
- (as opposed to a sibling) of the previous message. This
- is now deprecated. For compatibility with servers which
- may still use the old definition, client implementations
- SHOULD treat descendents of a child as being siblings of
- that child.
+ Children in ORDEREDSUBJECT threading do not have descendents.
+ Client implementations SHOULD treat descendents of a child in
+ a server response as being siblings of that child.
- This is because the old definition mistakenly indicated
- that there was a parent/child relationship between
- successive messages in a thread; when in fact there was
- only a chronological relationship. In clients which
- indicate parent/child relationships in a thread tree,
- this would indicate levels of descent which did not
- exist.
-
-
REFERENCES
- The REFERENCES threading algorithm is based on the [THREADING]
- algorithm written used in "Netscape Mail and News" versions 2.0
- through 3.0. This algorithm threads the searched messages by
- grouping them together in parent/child relationships based on
- which messages are replies to others. The parent/child
- relationships are built using two methods: reconstructing a
- message's ancestry using the references contained within it;
- and checking the original (not base) subject of a message to
- see if it is a reply to (or forward of) another message.
+ The REFERENCES threading algorithm threads the searched
+ messages by grouping them together in parent/child
+ relationships based on which messages are replies to others.
+ The parent/child relationships are built using two methods:
+ reconstructing a message's ancestry using the references
+ contained within it; and checking the original (not base)
+ subject of a message to see if it is a reply to (or forward of)
+ another message.
Note: "Message ID" in the following description refers to a
normalized form of the msg-id in [RFC-2822]. The actual
@@ -480,13 +472,9 @@
children of the root, unless there is only one child.
(4) Sort the messages under the root (top-level siblings only)
- by sent date. In the case of an exact match on sent date, use
- the order in which the messages appear in the mailbox (that is,
- by sequence number) to determine the order. In the case of a
+ by sent date as described in section 2.2. In the case of a
dummy message, sort its children by sent date and then use the
- first child for the top-level sort. If the sent date can not
- be determined (a Date: header is missing or can not be parsed),
- the INTERNALDATE for that message is used as the sent date.
+ first child for the top-level sort.
(5) Gather together messages under the root that have the same
base subject text.
@@ -564,18 +552,13 @@
Considerations."
(6) Traverse the messages under the root and sort each set of
- siblings by sent date. Traverse the messages in such a way
- that the "youngest" set of siblings are sorted first, and the
- "oldest" set of siblings are sorted last (grandchildren are
- sorted before children, etc). In the case of an exact match on
- sent date or if either of the Date: headers used in a
- comparison can not be parsed, use the order in which the
- messages appear in the mailbox (that is, by sequence number) to
- determine the order. In the case of a dummy message (which can
- only occur with top-level siblings), use its first child for
- sorting.
+ siblings by sent date as described in section 2.2. Traverse
+ the messages in such a way that the "youngest" set of siblings
+ are sorted first, and the "oldest" set of siblings are sorted
+ last (grandchildren are sorted before children, etc). In the
+ case of a dummy message (which can only occur with top-level
+ siblings), use its first child for sorting.
-
Example: C: A283 THREAD ORDEREDSUBJECT UTF-8 SINCE 5-MAR-2000
S: * THREAD (166)(167)(168)(169)(172)(170)(171)
(173)(174 (175)(176)(178)(181)(180))(179)(177
@@ -594,12 +577,10 @@
(199)(200 202)(201)(203)(204)(205 206 207)(208)
S: A285 OK THREAD completed
-
Note: The line breaks in the first and third server
responses are for editorial clarity and do not appear in
real THREAD responses.
-
4. Additional Responses
These responses are extensions to the [IMAP] base protocol.
@@ -619,7 +600,6 @@
Example: S: * SORT 2 3 6
-
BASE.7.2.THREAD. THREAD Response
Data: zero or more threads
@@ -667,7 +647,6 @@
match the search criteria (and/or does not exist in the mailbox);
however they are members of the same thread.
-
5. Formal Syntax of SORT and THREAD Commands and Responses
The following syntax specification uses the Augmented Backus-Naur
@@ -705,7 +684,6 @@
thread-nested = 2*thread-list
-
The following syntax describes base subject extraction rules (2)-(6):
subject = *subj-leader [subj-middle] *subj-trailer
@@ -737,7 +715,6 @@
NONWSP = %x01-08 / %x0a-1f / %x21-ff
; any CHAR8 other than WSP
-
6. Security Considerations
The SORT and THREAD extensions do not raise any security
@@ -747,18 +724,30 @@
data, are sent in the clear over the network unless protection from
snooping is negotiated, either by the use of STARTTLS, privacy
protection is negotiated in the AUTHENTICATE command, or some other
- protection mechanism is in effect.
+ protection mechanism.
+ Although not a security consideration, it is important to recognize
+ that sorting by REFERENCES can lead to misleading threading trees.
+ For example, a message with false References: header data will cause
+ a thread to be incorporated into another thread.
+ The process of extracting the base subject may lead to incorrect
+ collation if the extracted data was significant text as opposed to
+ a subject artifact.
+
7. Internationalization Considerations
- As described in [IMAP-I18N], strings in charsets other than US-ASCII
- and UTF-8 MUST be converted to UTF-8 and compared in ascending order
- according to the selected or active collation algorithm. If the
- server does not support the [IMAP-I18N] COMPARATOR extension, the
- collation algorithm used is the "en;ascii-casemap" collation
- described in [COMPARATOR].
+ As stated in the introduction, the rules of I18NLEVEL=1 as described
+ in [IMAP-I18N] MUST be followed; that is, the SORT and THREAD
+ extensions MUST collate strings according to the i;unicode-casemap
+ collation described in [UNICASEMAP]. Servers SHOULD also advertise
+ the I18NLEVEL=1 extension. Alternatively, a server MAY implement
+ I18NLEVEL=2 (or higher) and comply with the rules of that level.
+ As discussed in [IMAP-I18N] section 4.5, all server implementations
+ should eventually be updated to support the [IMAP-I18N] I18NLEVEL=2
+ extension.
+
Translations of the "re" or "fw"/"fwd" tokens are not specified for
@@ Diff output truncated at 100000 characters. @@
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/