rfc2683.txt

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

   here, and must pass them, unchanged, to the server (being careful to
   send them as literals when necessary).  In particular, some server
   configurations use "@" in user names, and some clients do not allow
   that character to be entered; this creates a severe interoperability
   problem.

3.4.3. UIDs and UIDVALIDITY

   Servers that support existing back-end mail stores often have no good
   place to save UIDs for messages.  Often the existing mail store will
   not have the concept of UIDs in the sense that IMAP has: strictly
   increasing, never re-issued, 32-bit integers.  Some servers solve
   this by storing the UIDs in a place that's accessible to end users,
   allowing for the possibility that the users will delete them.  Others
   solve it by re-assigning UIDs every time a mailbox is selected.

   The server should maintain UIDs permanently for all messages if it
   can.  If that's not possible, the server must change the UIDVALIDITY
   value for the mailbox whenever any of the UIDs may have become
   invalid.  Clients must recognize that the UIDVALIDITY has changed and
   must respond to that condition by throwing away any information that
   they have saved about UIDs in that mailbox.  There have been many
   problems in this area when clients have failed to do this; in the
   worst case it will result in loss of mail when a client deletes the



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


   wrong piece of mail by using a stale UID.

   It seems to be a common misunderstanding that "the UIDVALIDITY and
   the UID, taken together, form a 64-bit identifier that uniquely
   identifies a message on a server".  This is absolutely NOT TRUE.
   There is no assurance that the UIDVALIDITY values of two mailboxes be
   different, so the UIDVALIDITY in no way identifies a mailbox.  The
   ONLY purpose of UIDVALIDITY is, as its name indicates, to give the
   client a way to check the validity of the UIDs it has cached.  While
   it is a valid implementation choice to put these values together to
   make a 64-bit identifier for the message, the important concept here
   is that UIDs are not unique between mailboxes; they are only unique
   WITHIN a given mailbox.

   Some server implementations have attempted to make UIDs unique across
   the entire server.  This is inadvisable, in that it limits the life
   of UIDs unnecessarily.  The UID is a 32-bit number and will run out
   in reasonably finite time if it's global across the server.  If you
   assign UIDs sequentially in one mailbox, you will not have to start
   re-using them until you have had, at one time or another, 2**32
   different messages in that mailbox.  In the global case, you will
   have to reuse them once you have had, at one time or another, 2**32
   different messages in the entire mail store.  Suppose your server has
   around 8000 users registered (2**13).  That gives an average of 2**19
   UIDs per user.  Suppose each user gets 32 messages (2**5) per day.
   That gives you 2**14 days (16000+ days = about 45 years) before you
   run out.  That may seem like enough, but multiply the usage just a
   little (a lot of spam, a lot of mailing list subscriptions, more
   users) and you limit yourself too much.

   What's worse is that if you have to wrap the UIDs, and, thus, you
   have to change UIDVALIDITY and invalidate the UIDs in the mailbox,
   you have to do it for EVERY mailbox in the system, since they all
   share the same UID pool.  If you assign UIDs per mailbox and you have
   a problem, you only have to kill the UIDs for that one mailbox.

   Under extreme circumstances (and this is extreme, indeed), the server
   may have to invalidate UIDs while a mailbox is in use by a client -
   that is, the UIDs that the client knows about in its active mailbox
   are no longer valid.  In that case, the server must immediately
   change the UIDVALIDITY and must communicate this to the client.  The
   server may do this by sending an unsolicited UIDVALIDITY message, in
   the same form as in response to the SELECT command.  Clients must be
   prepared to handle such a message and the possibly coincident failure
   of the command in process.  For example:






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


       C: 032 UID STORE 382 +Flags.silent \Deleted
       S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value!
       S: 032 NO UID command rejected because UIDVALIDITY changed!
       C: ...invalidates local information and re-fetches...
       C: 033 FETCH 1:* UID
       ...etc...

   At the time of the writing of this document, the only server known to
   do this does so only under the following condition: the client
   selects INBOX, but there is not yet a physical INBOX file created.
   Nonetheless, the SELECT succeeds, exporting an empty INBOX with a
   temporary UIDVALIDITY of 1.  While the INBOX remains selected, mail
   is delivered to the user, which creates the real INBOX file and
   assigns a permanent UIDVALIDITY (that is likely not to be 1).  The
   server reports the change of UIDVALIDITY, but as there were no
   messages before, so no UIDs have actually changed, all the client
   must do is accept the change in UIDVALIDITY.

   Alternatively, a server may force the client to re-select the
   mailbox, at which time it will obtain a new UIDVALIDITY value.  To do
   this, the server closes this client session (see "Severed
   Connections" above) and the client then reconnects and gets back in
   synch.  Clients must be prepared for either of these behaviours.

   We do not know of, nor do we anticipate the future existance of, a
   server that changes UIDVALIDITY while there are existing messages,
   but clients must be prepared to handle this eventuality.

3.4.4. FETCH Responses

   When a client asks for certain information in a FETCH command, the
   server may return the requested information in any order, not
   necessarily in the order that it was requested.  Further, the server
   may return the information in separate FETCH responses and may also
   return information that was not explicitly requested (to reflect to
   the client changes in the state of the subject message).  Some
   examples:

       C: 001 FETCH 1 UID FLAGS INTERNALDATE
       S: * 5 FETCH (FLAGS (\Deleted))
       S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345)
       S: 001 OK done

   (In this case, the responses are in a different order.  Also, the
   server returned a flag update for message 5, which wasn't part of the
   client's request.)





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


       C: 002 FETCH 2 UID FLAGS INTERNALDATE
       S: * 2 FETCH (INTERNALDATE "...")
       S: * 2 FETCH (UID 399)
       S: * 2 FETCH (FLAGS ())
       S: 002 OK done

   (In this case, the responses are in a different order and were
   returned in separate responses.)

       C: 003 FETCH 2 BODY[1]
       S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14}
       S: Hello world!
       S: )
       S: 003 OK done

   (In this case, the FLAGS response was added by the server, since
   fetching the body part caused the server to set the \Seen flag.)

   Because of this characteristic a client must be ready to receive any
   FETCH response at any time and should use that information to update
   its local information about the message to which the FETCH response
   refers.  A client must not assume that any FETCH responses will come
   in any particular order, or even that any will come at all.  If after
   receiving the tagged response for a FETCH command the client finds
   that it did not get all of the information requested, the client
   should send a NOOP command to the server to ensure that the server
   has an opportunity to send any pending EXPUNGE responses to the
   client (see [RFC-2180]).

3.4.5. RFC822.SIZE

   Some back-end mail stores keep the mail in a canonical form, rather
   than retaining the original MIME format of the messages.  This means
   that the server must reassemble the message to produce a MIME stream
   when a client does a fetch such as RFC822 or BODY[], requesting the
   entire message.  It also may mean that the server has no convenient
   way to know the RFC822.SIZE of the message.  Often, such a server
   will actually have to build the MIME stream to compute the size, only
   to throw the stream away and report the size to the client.

   When this is the case, some servers have chosen to estimate the size,
   rather than to compute it precisely.  Such an estimate allows the
   client to display an approximate size to the user and to use the
   estimate in flood control considerations (q.v.), but requires that
   the client not use the size for things such as allocation of buffers,
   because those buffers might then be too small to hold the actual MIME
   stream.  Instead, a client should use the size that's returned in the
   literal when you fetch the data.



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


   The protocol requires that the RFC822.SIZE value returned by the
   server be EXACT.  Estimating the size is a protocol violation, and
   server designers must be aware that, despite the performance savings
   they might realize in using an estimate, this practice will cause
   some clients to fail in various ways.  If possible, the server should
   compute the RFC822.SIZE for a particular message once, and then save
   it for later retrieval.  If that's not possible, the server must
   compute the value exactly every time.  Incorrect estimates do cause
   severe interoperability problems with some clients.

3.4.6. Expunged Messages

   If the server allows multiple connections to the same mailbox, it is
   often possible for messages to be expunged in one client unbeknownst
   to another client.  Since the server is not allowed to tell the
   client about these expunged messages in response to a FETCH command,
   the server may have to deal with the issue of how to return
   information about an expunged message.  There was extensive
   discussion about this issue, and the results of that discussion are
   summarized in [RFC-2180].  See that reference for a detailed
   explanation and for recommendations.

3.4.7. The Namespace Issue

   Namespaces are a very muddy area in IMAP4 implementation right now
   (see [NAMESPACE] for a proposal to clear the water a bit).  Until the
   issue is resolved, the important thing for client developers to
   understand is that some servers provide access through IMAP to more
   than just the user's personal mailboxes, and, in fact, the user's
   personal mailboxes may be "hidden" somewhere in the user's default
   hierarchy.  The client, therefore, should provide a setting wherein
   the user can specify a prefix to be used when accessing mailboxes. If
   the user's mailboxes are all in "~/mail/", for instance, then the
   user can put that string in the prefix.  The client would then put
   the prefix in front of any name pattern in the LIST and LSUB
   commands:

       C: 001 LIST "" ~/mail/%

   (See also "Reference Names in the LIST Command" below.)

3.4.8. Creating Special-Use Mailboxes

   It may seem at first that this is part of the namespace issue; it is
   not, and is only indirectly related to it.  A number of clients like
   to create special-use mailboxes with particular names.  Most
   commonly, clients with a "trash folder" model of message deletion
   want to create a mailbox with the name "Trash" or "Deleted".  Some



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


   clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a
   "Sent Mail" mailbox.  And so on.  There are two major
   interoperability problems with this practice:

   1. different clients may use different names for mailboxes with
      similar functions (such as "Trash" and "Deleted"), or may manage
      the same mailboxes in different ways, causing problems if a user
      switches between clients and
   2. there is no guarantee that the server will allow the creation of
      the desired mailbox.

   The client developer is, therefore, well advised to consider
   carefully the creation of any special-use mailboxes on the server,
   and, further, the client must not require such mailbox creation -
   that is, if you do decide to do this, you must handle gracefully the
   failure of the CREATE command and behave reasonably when your
   special-use mailboxes do not exist and can not be created.

   In addition, the client developer should provide a convenient way for
   the user to select the names for any special-use mailboxes, allowing
   the user to make these names the same in all clients used and to put
   them where the user wants them.

3.4.9. Reference Names in the LIST Command

   Many implementers of both clients and servers are confused by the
   "reference name" on the LIST command.  The reference name is intended
   to be used in much the way a "cd" (change directory) command is used
   on Unix, PC DOS, Windows, and OS/2 systems.  That is, the mailbox
   name is interpreted in much the same way as a file of that name would
   be found if one had done a "cd" command into the directory specified
   by the reference name.  For example, in Unix we have the following:

       > cd /u/jones/junk
       > vi banana        [file is "/u/jones/junk/banana"]
       > vi stuff/banana  [file is "/u/jones/junk/stuff/banana"]
       > vi /etc/hosts    [file is "/etc/hosts"]

   In the past, there have been several interoperability problems with
   this.  First, while some IMAP servers are built on Unix or PC file
   systems, many others are not, and the file system semantics do not
   make sense in those configurations.  Second, while some IMAP servers
   expose the underlying file system to the clients, others allow access
   only to the user's personal mailboxes, or to some other limited set
   of files, making such file-system-like semantics less meaningful.
   Third, because the IMAP spec leaves the interpretation of the
   reference name as "implementation-dependent", in the past the various
   server implementations handled it in vastly differing ways.



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


   The following recommendations are the result of significant
   operational experience, and are intended to maximize
   interoperability.

   Server implementations must implement the reference argument in a way
   that matches the intended "change directory" operation as closely as
   possible.  As a minimum implementation, the reference argument may be
   prepended to the mailbox name (while suppressing double delimiters;
   see the next paragraph).  Even servers that do not provide a way to
   break out of the current hierarchy (see "breakout facility" below)
   must provide a reasonable implementation of the reference argument,