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

diff --git a/imap/docs/rfc/rfc4469.txt b/imap/docs/rfc/rfc4469.txt
deleted file mode 100644
index da365514..00000000
--- a/imap/docs/rfc/rfc4469.txt
+++ /dev/null
@@ -1,731 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         P. Resnick
-Request for Comments: 4469                         QUALCOMM Incorporated
-Updates: 3501, 3502                                           April 2006
-Category: Standards Track
-
-
-       Internet Message Access Protocol (IMAP) CATENATE 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 (2006).
-
-Abstract
-
-   The CATENATE extension to the Internet Message Access Protocol (IMAP)
-   extends the APPEND command to allow clients to create messages on the
-   IMAP server that may contain a combination of new data along with
-   parts of (or entire) messages already on the server.  Using this
-   extension, the client can catenate parts of an already existing
-   message onto a new message without having to first download the data
-   and then upload it back to the server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick                     Standards Track                     [Page 1]
-
-RFC 4469                IMAP CATENATE Extension               April 2006
-
-
-1.  Introduction
-
-   The CATENATE extension to the Internet Message Access Protocol (IMAP)
-   [1] allows the client to create a message on the server that can
-   include the text of messages (or parts of messages) that already
-   exist on the server without having to FETCH them and APPEND them back
-   to the server.  The CATENATE extension extends the APPEND command so
-   that, instead of a single message literal, the command can take as
-   arguments any combination of message literals (as described in IMAP
-   [1]) and message URLs (as described in the IMAP URL Scheme [2]
-   specification).  The server takes all the pieces and catenates them
-   into the output message.  The CATENATE extension can also coexist
-   with the MULTIAPPEND extension [3] to APPEND multiple messages in a
-   single command.
-
-   There are some obvious uses for the CATENATE extension.  The
-   motivating use case was to provide a way for a resource-constrained
-   client to compose a message for subsequent submission that contains
-   data that already exists in that client's IMAP store.  Because the
-   client does not have to download and re-upload potentially large
-   message parts, bandwidth and processing limitations do not have as
-   much impact.  In addition, since the client can create a message in
-   its own IMAP store, the command also addresses the desire of the
-   client to archive a copy of a sent message without having to upload
-   the message twice.  (Mechanisms for sending the message are outside
-   the scope of this document.)
-
-   The extended APPEND command can also be used to copy parts of a
-   message to another mailbox for archival purposes while getting rid of
-   undesired parts.  In environments where server storage is limited, a
-   client could get rid of large message parts by copying over only the
-   necessary parts and then deleting the original message.  The
-   mechanism could also be used to add data to a message (such as
-   prepending message header fields) or to include other data by making
-   a copy of the original and catenating the new data.
-
-2.  The CATENATE Capability
-
-   A server that supports this extension returns "CATENATE" as one of
-   the responses to the CAPABILITY command.
-
-
-
-
-
-
-
-
-
-
-
-Resnick                     Standards Track                     [Page 2]
-
-RFC 4469                IMAP CATENATE Extension               April 2006
-
-
-3.  The APPEND Command
-
-   Arguments:  mailbox name
-               (The following can be repeated in the presence of the
-               MULTIAPPEND extension [3])
-               OPTIONAL flag parenthesized list
-               OPTIONAL date/time string
-               a single message literal or one or more message parts to
-               catenate, specified as:
-                           message literal
-                           or
-                           message (or message part) URL
-
-   Responses:  OPTIONAL NO responses: BADURL, TOOBIG
-
-   Result:     OK -  append completed
-               NO -  append error: can't append to that mailbox, error
-                     in flags or date/time or message text, or can't
-                     fetch that data
-               BAD - command unknown or arguments invalid
-
-   The APPEND command concatenates all the message parts and appends
-   them as a new message to the end of the specified mailbox.  The
-   parenthesized flag list and date/time string set the flags and the
-   internal date, respectively, as described in IMAP [1].  The
-   subsequent command parameters specify the message parts that are
-   appended sequentially to the output message.
-
-   If the original form of APPEND is used, a message literal follows the
-   optional flag list and date/time string, which is appended as
-   described in IMAP [1].  If the extended form is used, "CATENATE" and
-   a parenthesized list of message literals and message URLs follows,
-   each of which is appended to the new message.  If a message literal
-   is specified (indicated by "TEXT"), the octets following the count
-   are appended.  If a message URL is specified (indicated by "URL"),
-   the octets of the body part pointed to by that URL are appended, as
-   if the literal returned in a FETCH BODY response were put in place of
-   the message part specifier.  The APPEND command does not cause the
-   \Seen flag to be set for any catenated body part.  The APPEND command
-   does not change the selected mailbox.
-
-   In the extended APPEND command, the string following "URL" is an IMAP
-   URL [2] and is interpreted according to the rules of [2].  The
-   present document only describes the behavior of the command using
-   IMAP URLs that refer to specific messages or message parts on the
-   current IMAP server from the current authenticated IMAP session.
-   Because of that, only relative IMAP message or message part URLs
-   (i.e., those having no scheme or <iserver>) are used.  The base URL
-
-
-
-Resnick                     Standards Track                     [Page 3]
-
-RFC 4469                IMAP CATENATE Extension               April 2006
-
-
-   for evaluating the relative URL is considered "imap://user@server/",
-   where "user" is the user name of the currently authenticated user and
-   "server" is the domain name of the current server.  When in the
-   selected state, the base URL is considered
-   "imap://user@server/mailbox", where "mailbox" is the encoded name of
-   the currently selected mailbox.  Additionally, since the APPEND
-   command is valid in the authenticated state of an IMAP session, no
-   further LOGIN or AUTHENTICATE command is performed for URLs specified
-   in the extended APPEND command.
-
-      Note: Use of an absolute IMAP URL or any URL that refers to
-      anything other than a message or message part from the current
-      authenticated IMAP session is outside the scope of this document
-      and would require an extension to this specification, and a server
-      implementing only this specification would return NO to such a
-      request.
-
-   The client is responsible for making sure that the catenated message
-   is in the format of an Internet Message Format (RFC 2822) [4] or
-   Multipurpose Internet Mail Extension (MIME) [5] message.  In
-   particular, when a URL is catenated, the server copies octets,
-   unchanged, from the indicated message or message part to the
-   catenated message.  It does no data conversion (e.g., MIME transfer
-   encodings) nor any verification that the data is appropriate for the
-   MIME part of the message into which it is inserted.  The client is
-   also responsible for inserting appropriate MIME boundaries between
-   body parts, and writing MIME Content-Type and Content-Transfer-
-   Encoding lines as needed in the appropriate places.
-
-   Responses behave just as the original APPEND command described in
-   IMAP [1].  If the server implements the IMAP UIDPLUS extension [6],
-   it will also return an APPENDUID response code in the tagged OK
-   response.  Two response codes are provided in Section 4 that can be
-   used in the tagged NO response if the APPEND command fails.
-
-4.  Response Codes
-
-   When a APPEND command fails, it may return a response code that
-   describes a reason for the failure.
-
-4.1.  BADURL Response
-
-   The BADURL response code is returned if the APPEND fails to process
-   one of the specified URLs.  Possible reasons for this are bad URL
-   syntax, unrecognized URL schema, invalid message UID, or invalid body
-   part.  The BADURL response code contains the first URL specified as a
-   parameter to the APPEND command that has caused the operation to
-   fail.
-
-
-
-Resnick                     Standards Track                     [Page 4]
-
-RFC 4469                IMAP CATENATE Extension               April 2006
-
-
-4.2.  TOOBIG Response
-
-   The TOOBIG response code is returned if the resulting message will
-   exceed the 4-GB IMAP message limit.  This might happen, for example,
-   if the client specifies 3 URLs for 2-GB messages.  Note that even if
-   the server doesn't return TOOBIG, it still has to be defensive
-   against misbehaving or malicious clients that try to construct a
-   message over the 4-GB limit.  The server may also wish to return the
-   TOOBIG response code if the resulting message exceeds a server-
-   specific message size limit.
-
-5.  Formal Syntax
-
-   The following syntax specification uses the Augmented Backus-Naur
-   Form (ABNF) [7] notation.  Elements not defined here can be found in
-   the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions
-   [8] specifications.  Note that capability and resp-text-code are
-   extended from the IMAP [1] specification and append-data is extended
-   from the IMAP ABNF extensions [8] specification.
-
-   append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")"
-
-   cat-part = text-literal / url
-
-   text-literal = "TEXT" SP literal
-
-   url = "URL" SP astring
-
-   resp-text-code =/ toobig-response-code / badurl-response-code
-
-   toobig-response-code = "TOOBIG"
-
-   badurl-response-code = "BADURL" SP url-resp-text
-
-   url-resp-text = 1*(%x01-09 /
-                      %x0B-0C /
-                      %x0E-5B /
-                      %x5D-FE) ; Any TEXT-CHAR except "]"
-
-   capability =/ "CATENATE"
-
-   The astring in the definition of url and the url-resp-text in the
-   definition of badurl-response-code each contain an imapurl as defined
-   by [2].
-
-
-
-
-
-
-
-Resnick                     Standards Track                     [Page 5]
-
-RFC 4469                IMAP CATENATE Extension               April 2006
-
-
-6.  Acknowledgements
-
-   Thanks to the members of the LEMONADE working group for their input.
-   Special thanks to Alexey Melnikov for the examples.
-
-7.  Security Considerations
-
-   The CATENATE extension does not raise any security considerations
-   that are not present for the base protocol or in the use of IMAP
-   URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2]
-   documents.
-
-8.  IANA Considerations
-
-   IMAP4 capabilities are registered by publishing a standards track or
-   IESG approved experimental RFC.  The registry is currently located at
-   <http://www.iana.org/assignments/imap4-capabilities>.  This document
-   defines the CATENATE IMAP capability.  The IANA has added this
-   capability to the registry.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick                     Standards Track                     [Page 6]
-
-RFC 4469                IMAP CATENATE Extension               April 2006
-
-
-Appendix A.  Examples
-
-   Lines not starting with "C: " or "S: " are continuations of the
-   previous lines.
-
-   The original message in examples 1 and 2 below (UID = 20) has the
-   following structure:
-
-
-      multipart/mixed MIME message with two body parts:
-
-      1.  text/plain
-
-      2.  application/x-zip-compressed
-
-   Example 1: The following example demonstrates how a CATENATE client
-   can replace an attachment in a draft message, without the need to
-   download it to the client and upload it back.
-
-   C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
-    (URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=HEADER"
-    TEXT {42}
-   S: + Ready for literal data
-   C:
-   C: --------------030308070208000400050907
-   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1.MIME"
-    URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1" TEXT {42}
-   S: + Ready for literal data
-   C:
-   C: --------------030308070208000400050907
-   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44}
-   S: + Ready for literal data
-   C:
-   C: --------------030308070208000400050907--
-   C: )
-   S: A003 OK catenate append completed
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick                     Standards Track                     [Page 7]
-
-RFC 4469                IMAP CATENATE Extension               April 2006
-
-
-   Example 2: The following example demonstrates how the CATENATE
-   extension can be used to replace edited text in a draft message, as
-   well as header fields for the top level message part (e.g., Subject
-   has changed).  The previous version of the draft is marked as
-   \Deleted.  Note that the server also supports the UIDPLUS extension,
-   so the APPENDUID response code is returned in the successful OK
-   response to the APPEND command.
-
-   C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738}
-   S: + Ready for literal data
-   C: Return-Path: <bar@example.org>
-   C: Received: from [127.0.0.2]
-   C:           by rufus.example.org via TCP (internal) with ESMTPA;
-   C:           Thu, 11 Nov 2004 16:57:07 +0000
-   C: Message-ID: <419399E1.6000505@example.org>
-   C: Date: Thu, 12 Nov 2004 16:57:05 +0000
-   C: From: Bob Ar <bar@example.org>
-   C: X-Accept-Language: en-us, en
-   C: MIME-Version: 1.0
-   C: To: foo@example.net
-   C: Subject: About our holiday trip
-   C: Content-Type: multipart/mixed;
-   C:               boundary="------------030308070208000400050907"
-   C:
-   C: --------------030308070208000400050907
-   C: Content-Type: text/plain; charset=us-ascii; format=flowed
-   C: Content-Transfer-Encoding: 7bit
-   C:
-   C: Our travel agent has sent the updated schedule.
-   C:
-   C: Cheers,
-   C: Bob
-   C: --------------030308070208000400050907
-   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2.MIME"
-    URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2" TEXT {44}
-   S: + Ready for literal data
-   C:
-   C: --------------030308070208000400050907--
-   C: )
-   S: A003 OK [APPENDUID 385759045 45] append Completed
-   C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted)
-   S: A004 OK STORE completed
-
-
-
-
-
-
-
-
-
-Resnick                     Standards Track                     [Page 8]
-
-RFC 4469                IMAP CATENATE Extension               April 2006
-
-
-   Example 3: The following example demonstrates how the CATENATE
-   extension can be used to strip attachments.  Below, a PowerPoint
-   attachment was replaced by a small text part explaining that the
-   attachment was stripped.
-
-   C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
-    (URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=HEADER"
-    TEXT {42}
-   S: + Ready for literal data
-   C:
-   C: --------------030308070208000400050903
-   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1.MIME"
-    URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1" TEXT {255}
-   S: + Ready for literal data
-   C:
-   C: --------------030308070208000400050903
-   C: Content-type: text/plain; charset="us-ascii"
-   C: Content-transfer-encoding: 7bit
-   C:
-   C: This body part contained a Power Point presentation that was
-   C: deleted upon your request.
-   C: --------------030308070208000400050903--
-   C: )
-   S: A003 OK append Completed
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick                     Standards Track                     [Page 9]
-
-RFC 4469                IMAP CATENATE Extension               April 2006
-
-
-   Example 4: The following example demonstrates a failed APPEND
-   command.  The server returns the BADURL response code to indicate
-   that one of the provided URLs is invalid.  This example also
-   demonstrates how the CATENATE extension can be used to construct a
-   digest of several messages.
-
-   C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541}
-   S: + Ready for literal data
-   C: Return-Path: <foo@example.org>
-   C: Received: from [127.0.0.2]
-   C:           by rufus.example.org via TCP (internal) with ESMTPA;
-   C:           Thu, 11 Nov 2004 16:57:07 +0000
-   C: Message-ID: <419399E1.6000505@example.org>
-   C: Date: Thu, 21 Nov 2004 16:57:05 +0000
-   C: From: Farren Oo <foo@example.org>
-   C: X-Accept-Language: en-us, en
-   C: MIME-Version: 1.0
-   C: To: bar@example.org
-   C: Subject: Digest of the mailing list for today
-   C: Content-Type: multipart/digest;
-   C:               boundary="------------030308070208000400050904"
-   C:
-   C: --------------030308070208000400050904
-   C:  URL "/INBOX;UIDVALIDITY=785799047/;UID=11467" TEXT {42}
-   S: + Ready for literal data
-   C:
-   C: --------------030308070208000400050904
-   C:  URL "/INBOX;UIDVALIDITY=785799047/;UID=113330/;section=1.5.9"
-    TEXT {42}
-   S: + Ready for literal data
-   C:
-   C: --------------030308070208000400050904
-   C:  URL "/INBOX;UIDVALIDITY=785799047/;UID=11916" TEXT {44}
-   S: + Ready for literal data
-   C:
-   C: --------------030308070208000400050904--
-   C: )
-   S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330;
-   section=1.5.9"] CATENATE append has failed, one message expunged
-
-   Note that the server could have validated the URLs as they were
-   received and therefore could have returned the tagged NO response
-   with BADURL response-code in place of any continuation request after
-   the URL was received.
-
-
-
-
-
-
-
-Resnick                     Standards Track                    [Page 10]
-
-RFC 4469                IMAP CATENATE Extension               April 2006
-
-
-9.  Normative References
-
-   [1]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
-        RFC 3501, March 2003.
-
-   [2]  Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
-
-   [3]  Crispin, M., "Internet Message Access Protocol (IMAP) -
-        MULTIAPPEND Extension", RFC 3502, March 2003.
-
-   [4]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
-   [5]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-        Extensions (MIME) Part One: Format of Internet Message Bodies",
-        RFC 2045, November 1996.
-
-   [6]  Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS
-        extension", RFC 4315, December 2005.
-
-   [7]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
-        Specifications: ABNF", RFC 4234, October 2005.
-
-   [8]  Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF",
-        RFC 4466, April 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick                     Standards Track                    [Page 11]
-
-RFC 4469                IMAP CATENATE Extension               April 2006
-
-
-Author's Address
-
-   Peter W. Resnick
-   QUALCOMM Incorporated
-   5775 Morehouse Drive
-   San Diego, CA  92121-1714
-   US
-
-   Phone: +1 858 651 4478
-   EMail: presnick@qualcomm.com
-   URI:   http://www.qualcomm.com/~presnick/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Resnick                     Standards Track                    [Page 12]
-
-RFC 4469                IMAP CATENATE Extension               April 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   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 provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Resnick                     Standards Track                    [Page 13]
-