rfc2683.txt

广泛使用的邮件服务器！同时

   as described here, so that they will interoperate with clients that
   use it.

   Server implementations that prepend the reference argument to the
   mailbox name should insert a hierarchy delimiter between them, and
   must not insert a second if one is already present:

       C: A001 LIST ABC DEF
       S: * LIST () "/" ABC/DEF   <=== should do this
       S: A001 OK done

       C: A002 LIST ABC/ /DEF
       S: * LIST () "/" ABC//DEF     <=== must not do this
       S: A002 OK done

   On clients, the reference argument is chiefly used to implement a
   "breakout facility", wherein the user may directly access a mailbox
   outside the "current directory" hierarchy.  Client implementations
   should have an operational mode that does not use the reference
   argument.  This is to interoperate with older servers that did not
   implement the reference argument properly.  While it's a good idea to
   give the user access to a breakout facility, clients that do not
   intend to do so should not use the reference argument at all.

   Client implementations should always place a trailing hierarchy
   delimiter on the reference argument.  This is because some servers
   prepend the reference argument to the mailbox name without inserting
   a hierarchy delimiter, while others do insert a hierarchy delimiter
   if one is not already present.  A client that puts the delimiter in
   will work with both varieties of server.

   Client implementations that implement a breakout facility should
   allow the user to choose whether or not to use a leading hierarchy
   delimiter on the mailbox argument.  This is because the handling of a
   leading mailbox hierarchy delimiter also varies from server to
   server, and even between different mailstores on the same server.  In
   some cases, a leading hierarchy delimiter means "discard the



Leiba                        Informational                     [Page 18]

RFC 2683          IMAP4 Implementation Recommendations    September 1999


   reference argument" (implementing the intended breakout facility),
   thus:

       C: A001 LIST ABC/ /DEF
       S: * LIST () "/" /DEF
       S: A001 OK done

   In other cases, however, the two are catenated and the extra
   hierarchy delimiter is discarded, thus:

       C: A001 LIST ABC/ /DEF
       S: * LIST () "/" ABC/DEF
       S: A001 OK done

   Client implementations must not assume that the server supports a
   breakout facility, but may provide a way for the user to use one if
   it is available.  Any breakout facility should be exported to the
   user interface.  Note that there may be other "breakout" characters
   besides the hierarchy delimiter (for instance, UNIX filesystem
   servers are likely to use a leading "~" as well), and that their
   interpretation is server-dependent.

3.4.10.   Mailbox Hierarchy Delimiters

   The server's selection of what to use as a mailbox hierarchy
   delimiter is a difficult one, involving several issues: What
   characters do users expect to see?  What characters can they enter
   for a hierarchy delimiter if it is desired (or required) that the
   user enter it?  What character can be used for the hierarchy
   delimiter, noting that the chosen character can not otherwise be used
   in the mailbox name?

   Because some interfaces show users the hierarchy delimiters or allow
   users to enter qualified mailbox names containing them, server
   implementations should use delimiter characters that users generally
   expect to see as name separators.  The most common characters used
   for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows
   file names), and "." (as in news groups).  There is little to choose
   among these apart from what users may expect or what is dictated by
   the underlying file system, if any.  One consideration about using
   "\" is that it's also a special character in the IMAP protocol. While
   the use of other hierarchy delimiter characters is permissible, A
   DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the
   server is intended for special purposes only.  Implementers might be
   thinking about using characters such as "-", "_", ";", "&", "#", "@",
   and "!", but they should be aware of the surprise to the user as well
   as of the effect on URLs and other external specifications (since
   some of these characters have special meanings there).  Also, a



Leiba                        Informational                     [Page 19]

RFC 2683          IMAP4 Implementation Recommendations    September 1999


   server that uses "\" (and clients of such a server) must remember to
   escape that character in quoted strings or to send literals instead.
   Literals are recommended over escaped characters in quoted strings in
   order to maintain compatibility with older IMAP versions that did not
   allow escaped characters in quoted strings (but check the grammar to
   see where literals are allowed):

       C: 001 LIST "" {13}
       S: + send literal
       C: this\%\%\%\h*
       S: * LIST () "\\" {27}
       S: this\is\a\mailbox\hierarchy
       S: 001 OK LIST complete

   In any case, a server should not use normal alpha-numeric characters
   (such as "X" or "0") as delimiters; a user would be very surprised to
   find that "EXPENDITURES" actually represented a two-level hierarchy.
   And a server should not use characters that are non-printable or
   difficult or impossible to enter on a standard US keyboard.  Control
   characters, box-drawing characters, and characters from non-US
   alphabets fit into this category.  Their use presents
   interoperability problems that are best avoided.

   The UTF-7 encoding of mailbox names also raises questions about what
   to do with the hierarchy delimiters in encoded names: do we encode
   each hierarchy level and separate them with delimiters, or do we
   encode the fully qualified name, delimiters and all?  The answer for
   IMAP is the former: encode each hierarchy level separately, and
   insert delimiters between.  This makes it particularly important not
   to use as a hierarchy delimiter a character that might cause
   confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding.

   To repeat: a server should use "/", "\", or "." as its hierarchy
   delimiter.  The use of any other character is likely to cause
   problems and is STRONGLY DISCOURAGED.

3.4.11.   ALERT Response Codes

   The protocol spec is very clear on the matter of what to do with
   ALERT response codes, and yet there are many clients that violate it
   so it needs to be said anyway: "The human-readable text contains a
   special alert that must be presented to the user in a fashion that
   calls the user's attention to the message."  That should be clear
   enough, but I'll repeat it here: Clients must present ALERT text
   clearly to the user.






Leiba                        Informational                     [Page 20]

RFC 2683          IMAP4 Implementation Recommendations    September 1999


3.4.12.   Deleting Mailboxes

   The protocol does not guarantee that a client may delete a mailbox
   that is not empty, though on some servers it is permissible and is,
   in fact, much faster than the alternative or deleting all the
   messages from the client.  If the client chooses to try to take
   advantage of this possibility it must be prepared to use the other
   method in the even that the more convenient one fails.  Further, a
   client should not try to delete the mailbox that it has selected, but
   should first close that mailbox; some servers do not permit the
   deletion of the selected mailbox.

   That said, a server should permit the deletion of a non-empty
   mailbox; there's little reason to pass this work on to the client.
   Moreover, forbidding this prevents the deletion of a mailbox that for
   some reason can not be opened or expunged, leading to possible
   denial-of-service problems.

   Example:

       [User tells the client to delete mailbox BANANA, which is
       currently selected...]
       C: 008 CLOSE
       S: 008 OK done
       C: 009 DELETE BANANA
       S: 009 NO Delete failed; mailbox is not empty.
       C: 010 SELECT BANANA
       S: * ... untagged SELECT responses
       S: 010 OK done
       C: 011 STORE 1:* +FLAGS.SILENT \DELETED
       S: 011 OK done
       C: 012 CLOSE
       S: 012 OK done
       C: 013 DELETE BANANA
       S: 013 OK done

3.5.   A Word About Testing

   Since the whole point of IMAP is interoperability, and since
   interoperability can not be tested in a vacuum, the final
   recommendation of this treatise is, "Test against EVERYTHING."  Test
   your client against every server you can get an account on.  Test
   your server with every client you can get your hands on.  Many
   clients make limited test versions available on the Web for the
   downloading.  Many server owners will give serious client developers
   guest accounts for testing.  Contact them and ask.  NEVER assume that
   because your client works with one or two servers, or because your
   server does fine with one or two clients, you will interoperate well



Leiba                        Informational                     [Page 21]

RFC 2683          IMAP4 Implementation Recommendations    September 1999


   in general.

   In particular, in addition to everything else, be sure to test
   against the reference implementations: the PINE client, the
   University of Washington server, and the Cyrus server.

   See the following URLs on the web for more information here:

       IMAP Products and Sources: http://www.imap.org/products.html
       IMC MailConnect: http://www.imc.org/imc-mailconnect

4. Security Considerations

   This document describes behaviour of clients and servers that use the
   IMAP4 protocol, and as such, has the same security considerations as
   described in [RFC-2060].

5. References

   [RFC-2060]  Crispin, M., "Internet Message Access Protocol - Version
               4rev1", RFC 2060, December 1996.

   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC-2180]  Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
               2180, July 1997.

   [UTF-8]     Yergeau, F., " UTF-8, a transformation format of Unicode
               and ISO 10646", RFC 2044, October 1996.

   [UTF-7]     Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe
               Transformation Format of Unicode", RFC 2152, May 1997.

   [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in
               Progress.

6. Author's Address

   Barry Leiba
   IBM T.J. Watson Research Center
   30 Saw Mill River Road
   Hawthorne, NY  10532

   Phone: [phone]
   EMail: [e-mail]





Leiba                        Informational                     [Page 22]

RFC 2683          IMAP4 Implementation Recommendations    September 1999


7. Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Leiba                        Informational                     [Page 23]