* Changes to configure.ac to add -lkrb5 to the link

  * Changes to avoud errors in compilation when -Wformat-security is used
  * Remove RFC files from source code

1 files changed, 0 insertions, 563 deletions

diff --git a/imap/docs/rfc/rfc2342.txt b/imap/docs/rfc/rfc2342.txt
deleted file mode 100644
index 0926646d..00000000
--- a/imap/docs/rfc/rfc2342.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Gahrns
-Request for Comments: 2342                                    Microsoft
-Category: Standards Track                                     C. Newman
-                                                               Innosoft
-                                                               May 1998
-
-
-                            IMAP4 Namespace
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-1. Abstract
-
-   IMAP4 [RFC-2060] does not define a default server namespace. As a
-   result, two common namespace models have evolved:
-
-   The "Personal Mailbox" model, in which the default namespace that is
-   presented consists of only the user's personal mailboxes. To access
-   shared mailboxes, the user must use an escape mechanism to reach
-   another namespace.
-
-   The "Complete Hierarchy" model, in which the default namespace that
-   is presented includes the user's personal mailboxes along with any
-   other mailboxes they have access to.
-
-   These two models, create difficulties for certain client operations.
-   This document defines a NAMESPACE command that allows a client to
-   discover the prefixes of namespaces used by a server for personal
-   mailboxes, other users' mailboxes, and shared mailboxes.  This allows
-   a client to avoid much of the manual user configuration that is now
-   necessary when mixing and matching IMAP4 clients and servers.
-
-2. Conventions used in this document
-
-   In examples, "C:" and "S:" indicate lines sent by the client and
-   server respectively.  If such lines are wrapped without a new "C:" or
-   "S:" label, then the wrapping is for editorial clarity and is not
-   part of the command.
-
-
-
-Gahrns & Newman             Standards Track                     [Page 1]
-
-RFC 2342                    IMAP4 Namespace                     May 1998
-
-
-   Personal Namespace: A namespace that the server considers within the
-   personal scope of the authenticated user on a particular connection.
-   Typically, only the authenticated user has access to mailboxes in
-   their Personal Namespace. It is the part of the namespace that
-   belongs to the user that is allocated for mailboxes. If an INBOX
-   exists for a user, it MUST appear within the user's personal
-   namespace.  In the typical case, there SHOULD be only one Personal
-   Namespace on a server.
-
-   Other Users' Namespace: A namespace that consists of mailboxes from
-   the Personal Namespaces of other users.  To access mailboxes in the
-   Other Users' Namespace, the currently authenticated user MUST be
-   explicitly granted access rights.  For example, it is common for a
-   manager to grant to their secretary access rights to their mailbox.
-   In the typical case, there SHOULD be only one Other Users' Namespace
-   on a server.
-
-   Shared Namespace: A namespace that consists of mailboxes that are
-   intended to be shared amongst users and do not exist within a user's
-   Personal Namespace.
-
-   The namespaces a server uses MAY differ on a per-user basis.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC-2119].
-
-3. Introduction and Overview
-
-   Clients often attempt to create mailboxes for such purposes as
-   maintaining a record of sent messages (e.g. "Sent Mail") or
-   temporarily saving messages being composed (e.g. "Drafts").  For
-   these clients to inter-operate correctly with the variety of IMAP4
-   servers available, the user must enter the prefix of the Personal
-   Namespace used by the server.  Using the NAMESPACE command, a client
-   is able to automatically discover this prefix without manual user
-   configuration.
-
-   In addition, users are often required to manually enter the prefixes
-   of various namespaces in order to view the mailboxes located there.
-   For example, they might be required to enter the prefix of #shared to
-   view the shared mailboxes namespace. The NAMESPACE command allows a
-   client to automatically discover the namespaces that are available on
-   a server. This allows a client to present the available namespaces to
-   the user in what ever manner it deems appropriate.  For example, a
-
-
-
-
-
-
-Gahrns & Newman             Standards Track                     [Page 2]
-
-RFC 2342                    IMAP4 Namespace                     May 1998
-
-
-   client could choose to initially display only personal mailboxes, or
-   it may choose to display the complete list of mailboxes available,
-   and initially position the user at the root of their Personal
-   Namespace.
-
-   A server MAY choose to make available to the NAMESPACE command only a
-   subset of the complete set of namespaces the server supports. To
-   provide the ability to access these namespaces, a client SHOULD allow
-   the user the ability to manually enter a namespace prefix.
-
-4. Requirements
-
-   IMAP4 servers that support this extension MUST list the keyword
-   NAMESPACE in their CAPABILITY response.
-
-   The NAMESPACE command is valid in the Authenticated and Selected
-   state.
-
-5. NAMESPACE Command
-
-   Arguments: none
-
-   Response:  an untagged NAMESPACE response that contains the prefix
-                 and hierarchy delimiter to the server's Personal
-                 Namespace(s), Other Users' Namespace(s), and Shared
-                 Namespace(s) that the server wishes to expose. The
-                 response will contain a NIL for any namespace class
-                 that is not available. Namespace_Response_Extensions
-                 MAY be included in the response.
-                 Namespace_Response_Extensions which are not on the IETF
-                 standards track, MUST be prefixed with an "X-".
-
-   Result:    OK - Command completed
-                 NO - Error: Can't complete command
-                 BAD - argument invalid
-
-   Example 5.1:
-   ===========
-
-      < A server that supports a single personal namespace.  No leading
-      prefix is used on personal mailboxes and "/" is the hierarchy
-      delimiter.>
-
-      C: A001 NAMESPACE
-      S: * NAMESPACE (("" "/")) NIL NIL
-      S: A001 OK NAMESPACE command completed
-
-
-
-
-
-Gahrns & Newman             Standards Track                     [Page 3]
-
-RFC 2342                    IMAP4 Namespace                     May 1998
-
-
-   Example 5.2:
-   ===========
-
-      < A user logged on anonymously to a server.  No personal mailboxes
-      are associated with the anonymous user and the user does not have
-      access to the Other Users' Namespace.  No prefix is required to
-      access shared mailboxes and the hierarchy delimiter is "." >
-
-      C: A001 NAMESPACE
-      S: * NAMESPACE NIL NIL (("" "."))
-      S: A001 OK NAMESPACE command completed
-
-   Example 5.3:
-   ===========
-
-      < A server that contains a Personal Namespace and a single Shared
-      Namespace. >
-
-      C: A001 NAMESPACE
-      S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
-      S: A001 OK NAMESPACE command completed
-
-   Example 5.4:
-   ===========
-
-      < A server that contains a Personal Namespace, Other Users'
-      Namespace and multiple Shared Namespaces.  Note that the hierarchy
-      delimiter used within each namespace can be different. >
-
-      C: A001 NAMESPACE
-      S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
-         ("#public/" "/")("#ftp/" "/")("#news." "."))
-      S: A001 OK NAMESPACE command completed
-
-   The prefix string allows a client to do things such as automatically
-   creating personal mailboxes or LISTing all available mailboxes within
-   a namespace.
-
-   Example 5.5:
-   ===========
-
-      < A server that supports only the Personal Namespace, with a
-      leading prefix of INBOX to personal mailboxes and a hierarchy
-      delimiter of ".">
-
-      C: A001 NAMESPACE
-      S: * NAMESPACE (("INBOX." ".")) NIL  NIL
-      S: A001 OK NAMESPACE command completed
-
-
-
-Gahrns & Newman             Standards Track                     [Page 4]
-
-RFC 2342                    IMAP4 Namespace                     May 1998
-
-
-      < Automatically create a mailbox to store sent items.>
-
-      C: A002 CREATE "INBOX.Sent Mail"
-      S: A002 OK CREATE command completed
-
-   Although typically a server will support only a single Personal
-   Namespace, and a single Other User's Namespace, circumstances exist
-   where there MAY be multiples of these, and a client MUST be prepared
-   for them.   If a client is configured such that it is required to
-   create a certain mailbox, there can be circumstances where it is
-   unclear which Personal Namespaces it should create the mailbox in.
-   In these situations a client SHOULD let the user select which
-   namespaces to create the mailbox in.
-
-   Example 5.6:
-   ===========
-
-      < In this example, a server supports 2 Personal Namespaces.  In
-      addition to the regular Personal Namespace, the user has an
-      additional personal namespace to allow access to mailboxes in an
-      MH format mailstore. >
-
-      < The client is configured to save a copy of all mail sent by the
-      user into a mailbox called 'Sent Mail'.  Furthermore, after a
-      message is deleted from a mailbox, the client is configured to
-      move that message to a mailbox called 'Deleted Items'.>
-
-      < Note that this example demonstrates how some extension flags can
-      be passed to further describe the #mh namespace. >
-
-      C: A001 NAMESPACE
-      S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM" ("FLAG1" "FLAG2")))
-         NIL NIL
-      S: A001 OK NAMESPACE command completed
-
-      < It is desired to keep only one copy of sent mail. It is unclear
-      which Personal Namespace the client should use to create the 'Sent
-      Mail' mailbox.  The user is prompted to select a namespace and
-      only one 'Sent Mail' mailbox is created. >
-
-      C: A002 CREATE "Sent Mail"
-      S: A002 OK CREATE command completed
-
-      < The client is designed so that it keeps two 'Deleted Items'
-      mailboxes, one for each namespace. >
-
-      C: A003 CREATE "Delete Items"
-      S: A003 OK CREATE command completed
-
-
-
-Gahrns & Newman             Standards Track                     [Page 5]
-
-RFC 2342                    IMAP4 Namespace                     May 1998
-
-
-      C: A004 CREATE "#mh/Deleted Items"
-      S: A004 OK CREATE command completed
-
-   The next level of hierarchy following the Other Users' Namespace
-   prefix SHOULD consist of <username>, where <username> is a user name
-   as per the IMAP4 LOGIN or AUTHENTICATE command.
-
-   A client can construct a LIST command by appending a "%" to the Other
-   Users' Namespace prefix to discover the Personal Namespaces of other
-   users that are available to the currently authenticated user.
-
-   In response to such a LIST command, a server SHOULD NOT return user
-   names that have not granted access to their personal mailboxes to the
-   user in question.
-
-   A server MAY return a LIST response containing only the names of
-   users that have explicitly granted access to the user in question.
-
-   Alternatively, a server MAY return NO to such a LIST command,
-   requiring that a user name be included with the Other Users'
-   Namespace prefix before listing any other user's mailboxes.
-
-   Example 5.7:
-   ===========
-
-      < A server that supports providing a list of other user's
-      mailboxes that are accessible to the currently logged on user. >
-
-      C: A001 NAMESPACE
-      S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL
-      S: A001 OK NAMESPACE command completed
-
-      C: A002 LIST "" "Other Users/%"
-      S: * LIST () "/" "Other Users/Mike"
-      S: * LIST () "/" "Other Users/Karen"
-      S: * LIST () "/" "Other Users/Matthew"
-      S: * LIST () "/" "Other Users/Tesa"
-      S: A002 OK LIST command completed
-
-   Example 5.8:
-   ===========
-
-      < A server that does not support providing a list of other user's
-      mailboxes that are accessible to the currently logged on user.
-      The mailboxes are listable if the client includes the name of the
-      other user with the Other Users' Namespace prefix. >
-
-
-
-
-
-Gahrns & Newman             Standards Track                     [Page 6]
-
-RFC 2342                    IMAP4 Namespace                     May 1998
-
-
-      C: A001 NAMESPACE
-      S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL
-      S: A001 OK NAMESPACE command completed
-
-      < In this example, the currently logged on user has access to the
-      Personal Namespace of user Mike, but the server chose to suppress
-      this information in the LIST response.  However, by appending the
-      user name Mike (received through user input) to the Other Users'
-      Namespace prefix, the client is able to get a listing of the
-      personal mailboxes of user Mike. >
-
-      C: A002 LIST "" "#Users/%"
-      S: A002 NO The requested item could not be found.
-
-      C: A003 LIST "" "#Users/Mike/%"
-      S: * LIST () "/" "#Users/Mike/INBOX"
-      S: * LIST () "/" "#Users/Mike/Foo"
-      S: A003 OK LIST command completed.
-
-      A prefix string might not contain a hierarchy delimiter, because
-      in some cases it is not needed as part of the prefix.
-
-      Example 5.9:
-      ===========
-
-      < A server that allows access to the Other Users' Namespace by
-      prefixing the others' mailboxes with a '~' followed by <username>,
-      where <username> is a user name as per the IMAP4 LOGIN or
-      AUTHENTICATE command.>
-
-      C: A001 NAMESPACE
-      S: * NAMESPACE (("" "/")) (("~" "/")) NIL
-      S: A001 OK NAMESPACE command completed
-
-      < List the mailboxes for user mark >
-
-      C: A002 LIST "" "~mark/%"
-      S: * LIST () "/" "~mark/INBOX"
-      S: * LIST () "/" "~mark/foo"
-      S: A002 OK LIST command completed
-
-   Historical convention has been to start all namespaces with the "#"
-   character.  Namespaces that include the "#" character are not IMAP
-   URL [IMAP-URL] friendly requiring the "#" character to be represented
-   as %23 when within URLs.  As such, server implementers MAY instead
-   consider using namespace prefixes that do not contain the "#"
-   character.
-
-
-
-
-Gahrns & Newman             Standards Track                     [Page 7]
-
-RFC 2342                    IMAP4 Namespace                     May 1998
-
-
-6. Formal Syntax
-
-   The following syntax specification uses the augmented Backus-Naur
-   Form (BNF) as described in [ABNF].
-
-   atom = <atom>
-      ; <atom> as defined in [RFC-2060]
-
-   Namespace = nil / "(" 1*( "(" string SP  (<"> QUOTED_CHAR <"> /
-      nil) *(Namespace_Response_Extension) ")" ) ")"
-
-   Namespace_Command = "NAMESPACE"
-
-   Namespace_Response_Extension = SP string SP "(" string *(SP string)
-      ")"
-
-   Namespace_Response = "*" SP "NAMESPACE" SP Namespace SP Namespace SP
-      Namespace
-
-      ; The first Namespace is the Personal Namespace(s)
-      ; The second Namespace is the Other Users' Namespace(s)
-      ; The third Namespace is the Shared Namespace(s)
-
-      nil = <nil>
-         ; <nil> as defined in [RFC-2060]
-
-      QUOTED_CHAR = <QUOTED_CHAR>
-         ; <QUOTED_CHAR> as defined in [RFC-2060]
-
-      string = <string>
-         ; <string> as defined in [RFC-2060]
-         ; Note that  the namespace prefix is to a mailbox and following
-         ; IMAP4 convention, any international string in the NAMESPACE
-         ; response MUST be of modified UTF-7 format as described in
-         ;  [RFC-2060].
-
-7. Security Considerations
-
-   In response to a LIST command containing an argument of the Other
-   Users' Namespace prefix, a server SHOULD NOT list users that have not
-   granted list access to their personal mailboxes to the currently
-   authenticated user.  Providing such a list, could compromise security
-   by potentially disclosing confidential information of who is located
-   on the server, or providing a starting point of a list of user
-   accounts to attack.
-
-
-
-
-
-
-Gahrns & Newman             Standards Track                     [Page 8]
-
-RFC 2342                    IMAP4 Namespace                     May 1998
-
-
-8. 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.
-
-   [ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
-   Specifications: ABNF", RFC 2234, November 1997.
-
-   [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
-
-9.  Acknowledgments
-
-   Many people have participated in the discussion of IMAP namespaces on
-   the IMAP mailing list.  In particular, the authors would like to
-   thank Mark Crispin for many of the concepts relating to the Personal
-   Namespace and accessing the Personal Namespace of other users, Steve
-   Hole for summarizing the two namespace models, John Myers and Jack De
-   Winter for their work in a preceding effort trying to define a
-   standardized personal namespace, and Larry Osterman for his review
-   and collaboration on this document.
-
-11. Authors' Addresses
-
-   Mike Gahrns
-   Microsoft
-   One Microsoft Way
-   Redmond, WA, 98072, USA
-
-   Phone: (425) 936-9833
-   EMail: mikega@microsoft.com
-
-
-   Chris Newman
-   Innosoft International, Inc.
-   1050 East Garvey Ave. South
-   West Covina, CA, 91790, USA
-
-   EMail: chris.newman@innosoft.com
-
-
-
-
-
-
-
-
-
-
-Gahrns & Newman             Standards Track                     [Page 9]
-
-RFC 2342                    IMAP4 Namespace                     May 1998
-
-
-12.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gahrns & Newman             Standards Track                    [Page 10]
-