* 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, 451 deletions

diff --git a/imap/docs/rfc/rfc4315.txt b/imap/docs/rfc/rfc4315.txt
deleted file mode 100644
index c026f422..00000000
--- a/imap/docs/rfc/rfc4315.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Crispin
-Request for Comments: 4315                                 December 2005
-Obsoletes: 2359
-Category: Standards Track
-
-
-      Internet Message Access Protocol (IMAP) - UIDPLUS extension
-
-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 (2005).
-
-Abstract
-
-   The UIDPLUS extension of the Internet Message Access Protocol (IMAP)
-   provides a set of features intended to reduce the amount of time and
-   resources used by some client operations.  The features in UIDPLUS
-   are primarily intended for disconnected-use clients.
-
-1.  Introduction and Overview
-
-   The UIDPLUS extension is present in any IMAP server implementation
-   that returns "UIDPLUS" as one of the supported capabilities to the
-   CAPABILITY command.
-
-   The UIDPLUS extension defines an additional command.  In addition,
-   this document recommends new status response codes in IMAP that
-   SHOULD be returned by all server implementations, regardless of
-   whether or not the UIDPLUS extension is implemented.
-
-   The added facilities of the features in UIDPLUS are optimizations;
-   clients can provide equivalent functionality, albeit less
-   efficiently, by using facilities in the base protocol.
-
-1.1.  Conventions Used in This Document
-
-   In examples, "C:" and "S:" indicate lines sent by the client and
-   server, respectively.
-
-
-
-
-
-Crispin                     Standards Track                     [Page 1]
-
-RFC 4315                IMAP - UIDPLUS Extension           December 2005
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
-   be interpreted as described in [KEYWORDS].
-
-   A "UID set" is similar to the [IMAP] sequence set; however, the "*"
-   value for a sequence number is not permitted.
-
-2.  Additional Commands
-
-   The following command definition is an extension to [IMAP] section
-   6.4.
-
-2.1.  UID EXPUNGE Command
-
-   Arguments:  sequence set
-
-   Data:       untagged responses: EXPUNGE
-
-   Result:     OK - expunge completed
-               NO - expunge failure (e.g., permission denied)
-               BAD - command unknown or arguments invalid
-
-      The UID EXPUNGE command permanently removes all messages that both
-      have the \Deleted flag set and have a UID that is included in the
-      specified sequence set from the currently selected mailbox.  If a
-      message either does not have the \Deleted flag set or has a UID
-      that is not included in the specified sequence set, it is not
-      affected.
-
-      This command is particularly useful for disconnected use clients.
-      By using UID EXPUNGE instead of EXPUNGE when resynchronizing with
-      the server, the client can ensure that it does not inadvertantly
-      remove any messages that have been marked as \Deleted by other
-      clients between the time that the client was last connected and
-      the time the client resynchronizes.
-
-      If the server does not support the UIDPLUS capability, the client
-      should fall back to using the STORE command to temporarily remove
-      the \Deleted flag from messages it does not want to remove, then
-      issuing the EXPUNGE command.  Finally, the client should use the
-      STORE command to restore the \Deleted flag on the messages in
-      which it was temporarily removed.
-
-      Alternatively, the client may fall back to using just the EXPUNGE
-      command, risking the unintended removal of some messages.
-
-
-
-
-
-
-Crispin                     Standards Track                     [Page 2]
-
-RFC 4315                IMAP - UIDPLUS Extension           December 2005
-
-
-   Example:    C: A003 UID EXPUNGE 3000:3002
-               S: * 3 EXPUNGE
-               S: * 3 EXPUNGE
-               S: * 3 EXPUNGE
-               S: A003 OK UID EXPUNGE completed
-
-3.  Additional Response Codes
-
-   The following response codes are extensions to the response codes
-   defined in [IMAP] section 7.1.  With limited exceptions, discussed
-   below, server implementations that advertise the UIDPLUS extension
-   SHOULD return these response codes.
-
-   In the case of a mailbox that has permissions set so that the client
-   can COPY or APPEND to the mailbox, but not SELECT or EXAMINE it, the
-   server SHOULD NOT send an APPENDUID or COPYUID response code as it
-   would disclose information about the mailbox.
-
-   In the case of a mailbox that has UIDNOTSTICKY status (as defined
-   below), the server MAY omit the APPENDUID or COPYUID response code as
-   it is not meaningful.
-
-   If the server does not return the APPENDUID or COPYUID response
-   codes, the client can discover this information by selecting the
-   destination mailbox.  The location of messages placed in the
-   destination mailbox by COPY or APPEND can be determined by using
-   FETCH and/or SEARCH commands (e.g., for Message-ID or some unique
-   marker placed in the message in an APPEND).
-
-   APPENDUID
-
-      Followed by the UIDVALIDITY of the destination mailbox and the UID
-      assigned to the appended message in the destination mailbox,
-      indicates that the message has been appended to the destination
-      mailbox with that UID.
-
-      If the server also supports the [MULTIAPPEND] extension, and if
-      multiple messages were appended in the APPEND command, then the
-      second value is a UID set containing the UIDs assigned to the
-      appended messages, in the order they were transmitted in the
-      APPEND command.  This UID set may not contain extraneous UIDs or
-      the symbol "*".
-
-         Note: the UID set form of the APPENDUID response code MUST NOT
-         be used if only a single message was appended.  In particular,
-         a server MUST NOT send a range such as 123:123.  This is
-         because a client that does not support [MULTIAPPEND] expects
-         only a single UID and not a UID set.
-
-
-
-Crispin                     Standards Track                     [Page 3]
-
-RFC 4315                IMAP - UIDPLUS Extension           December 2005
-
-
-      UIDs are assigned in strictly ascending order in the mailbox
-      (refer to [IMAP], section 2.3.1.1) and UID ranges are as in
-      [IMAP]; in particular, note that a range of 12:10 is exactly
-      equivalent to 10:12 and refers to the sequence 10,11,12.
-
-      This response code is returned in a tagged OK response to the
-      APPEND command.
-
-   COPYUID
-
-      Followed by the UIDVALIDITY of the destination mailbox, a UID set
-      containing the UIDs of the message(s) in the source mailbox that
-      were copied to the destination mailbox and containing the UIDs
-      assigned to the copied message(s) in the destination mailbox,
-      indicates that the message(s) have been copied to the destination
-      mailbox with the stated UID(s).
-
-      The source UID set is in the order the message(s) were copied; the
-      destination UID set corresponds to the source UID set and is in
-      the same order.  Neither of the UID sets may contain extraneous
-      UIDs or the symbol "*".
-
-      UIDs are assigned in strictly ascending order in the mailbox
-      (refer to [IMAP], section 2.3.1.1) and UID ranges are as in
-      [IMAP]; in particular, note that a range of 12:10 is exactly
-      equivalent to 10:12 and refers to the sequence 10,11,12.
-
-      This response code is returned in a tagged OK response to the COPY
-      command.
-
-   UIDNOTSTICKY
-
-      The selected mailbox is supported by a mail store that does not
-      support persistent UIDs; that is, UIDVALIDITY will be different
-      each time the mailbox is selected.  Consequently, APPEND or COPY
-      to this mailbox will not return an APPENDUID or COPYUID response
-      code.
-
-      This response code is returned in an untagged NO response to the
-      SELECT command.
-
-         Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores.
-         This facility exists to support legacy mail stores in which it
-         is technically infeasible to support persistent UIDs.  This
-         should be avoided when designing new mail stores.
-
-
-
-
-
-
-Crispin                     Standards Track                     [Page 4]
-
-RFC 4315                IMAP - UIDPLUS Extension           December 2005
-
-
-   Example:    C: A003 APPEND saved-messages (\Seen) {297}
-               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
-               C: From: Fred Foobar <foobar@example.com>
-               C: Subject: afternoon meeting
-               C: To: mooch@example.com
-               C: Message-Id: <B27397-0100000@example.com>
-               C: MIME-Version: 1.0
-               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
-               C:
-               C: Hello Joe, do you think we can meet at 3:30 tomorrow?
-               C:
-               S: A003 OK [APPENDUID 38505 3955] APPEND completed
-               C: A004 COPY 2:4 meeting
-               S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done
-               C: A005 UID COPY 305:310 meeting
-               S: A005 OK No matching messages, so nothing copied
-               C: A006 COPY 2 funny
-               S: A006 OK Done
-               C: A007 SELECT funny
-               S: * 1 EXISTS
-               S: * 1 RECENT
-               S: * OK [UNSEEN 1] Message 1 is first unseen
-               S: * OK [UIDVALIDITY 3857529045] Validity session-only
-               S: * OK [UIDNEXT 2] Predicted next UID
-               S: * NO [UIDNOTSTICKY] Non-persistent UIDs
-               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-               S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited
-               S: A007 OK [READ-WRITE] SELECT completed
-
-   In this example, A003 and A004 demonstrate successful appending and
-   copying to a mailbox that returns the UIDs assigned to the messages.
-   A005 is an example in which no messages were copied; this is because
-   in A003, we see that message 2 had UID 304, and message 3 had UID
-   319; therefore, UIDs 305 through 310 do not exist (refer to section
-   2.3.1.1 of [IMAP] for further explanation).  A006 is an example of a
-   message being copied that did not return a COPYUID; and, as expected,
-   A007 shows that the mail store containing that mailbox does not
-   support persistent UIDs.
-
-4.  Formal Syntax
-
-   Formal syntax is defined using ABNF [ABNF], which extends the ABNF
-   rules defined in [IMAP].  The IMAP4 ABNF should be imported before
-   attempting to validate these rules.
-
-   append-uid      = uniqueid
-
-   capability      =/ "UIDPLUS"
-
-
-
-Crispin                     Standards Track                     [Page 5]
-
-RFC 4315                IMAP - UIDPLUS Extension           December 2005
-
-
-   command-select  =/ uid-expunge
-
-   resp-code-apnd  = "APPENDUID" SP nz-number SP append-uid
-
-   resp-code-copy  = "COPYUID" SP nz-number SP uid-set SP uid-set
-
-   resp-text-code  =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY"
-                     ; incorporated before the expansion rule of
-                     ;  atom [SP 1*<any TEXT-CHAR except "]">]
-                     ; that appears in [IMAP]
-
-   uid-expunge     = "UID" SP "EXPUNGE" SP sequence-set
-
-   uid-set         = (uniqueid / uid-range) *("," uid-set)
-
-   uid-range       = (uniqueid ":" uniqueid)
-                     ; two uniqueid values and all values
-                     ; between these two regards of order.
-                     ; Example: 2:4 and 4:2 are equivalent.
-
-   Servers that support [MULTIAPPEND] will have the following extension
-   to the above rules:
-
-   append-uid      =/ uid-set
-                     ; only permitted if client uses [MULTIAPPEND]
-                     ; to append multiple messages.
-
-5.  Security Considerations
-
-   The COPYUID and APPENDUID response codes return information about the
-   mailbox, which may be considered sensitive if the mailbox has
-   permissions set that permit the client to COPY or APPEND to the
-   mailbox, but not SELECT or EXAMINE it.
-
-   Consequently, these response codes SHOULD NOT be issued if the client
-   does not have access to SELECT or EXAMINE the mailbox.
-
-6.  IANA Considerations
-
-   This document constitutes registration of the UIDPLUS capability in
-   the imap4-capabilities registry, replacing [RFC2359].
-
-7.  Normative References
-
-   [ABNF]        Crocker, D. and P. Overell, "Augmented BNF for Syntax
-                 Specifications: ABNF", RFC 4234, October 2005.
-
-
-
-
-
-Crispin                     Standards Track                     [Page 6]
-
-RFC 4315                IMAP - UIDPLUS Extension           December 2005
-
-
-   [IMAP]        Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
-                 VERSION 4rev1", RFC 3501, March 2003.
-
-   [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
-                 Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
-                 MULTIAPPEND Extension", RFC 3502, March 2003.
-
-8.  Informative References
-
-   [RFC2359]     Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June
-                 1998.
-
-9.  Changes from RFC 2359
-
-   This document obsoletes [RFC2359].  However, it is based upon that
-   document, and takes substantial text from it (albeit with numerous
-   clarifications in wording).
-
-   [RFC2359] implied that a server must always return COPYUID/APPENDUID
-   data; thus suggesting that in such cases the server should return
-   arbitrary data if the destination mailbox did not support persistent
-   UIDs.  This document adds the UIDNOTSTICKY response code to indicate
-   that a mailbox does not support persistent UIDs, and stipulates that
-   a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY
-   (or APPEND) destination mailbox has UIDNOTSTICKY status.
-
-Author's Address
-
-   Mark R. Crispin
-   Networks and Distributed Computing
-   University of Washington
-   4545 15th Avenue NE
-   Seattle, WA  98105-4527
-
-   Phone: (206) 543-5762
-   EMail: MRC@CAC.Washington.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                     [Page 7]
-
-RFC 4315                IMAP - UIDPLUS Extension           December 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   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.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM 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.
-
-Intellectual Property
-
-   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.
-
-   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.
-
-   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-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Crispin                     Standards Track                     [Page 8]
-