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

diff --git a/imap/docs/rfc/rfc2221.txt b/imap/docs/rfc/rfc2221.txt
deleted file mode 100644
index 81d00620..00000000
--- a/imap/docs/rfc/rfc2221.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           M. Gahrns
-Request for Comments: 2221                                      Microsoft
-Category: Standards Track                                    October 1997
-
-
-                         IMAP4 Login Referrals
-
-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 (1997).  All Rights Reserved.
-
-1. Abstract
-
-   When dealing with large amounts of users and many IMAP4 [RFC-2060]
-   servers, it is often necessary to move users from one IMAP4 server to
-   another.  For example, hardware failures or organizational changes
-   may dictate such a move.
-
-   Login referrals allow clients to transparently connect to an
-   alternate IMAP4 server, if their home IMAP4 server has changed.
-
-   A referral mechanism can provide efficiencies over the alternative
-   'proxy method', in which the local IMAP4 server contacts the remote
-   server on behalf of the client, and then transfers the data from the
-   remote server to itself, and then on to the client.  The referral
-   mechanism's direct client connection to the remote server is often a
-   more efficient use of bandwidth, and does not require the local
-   server to impersonate the client when authenticating to the remote
-   server.
-
-2. Conventions used in this document
-
-   In examples, "C:" and "S:" indicate lines sent by the client and
-   server respectively.
-
-   A home server, is an IMAP4 server that contains the user's inbox.
-
-   A remote server is a server that contains remote mailboxes.
-
-
-
-
-
-Gahrns                      Standards Track                     [Page 1]
-
-RFC 2221                 IMAP4 Login Referrals              October 1997
-
-
-   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
-
-   IMAP4 servers that support this extension MUST list the keyword
-   LOGIN-REFERRALS in their CAPABILITY response.  No client action is
-   needed to invoke the LOGIN-REFERRALS capability in a server.
-
-   A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral
-   to a server that will return a referral. A client MUST NOT follow
-   more than 10 levels of referral without consulting the user.
-
-   A LOGIN-REFERRALS response code MUST contain as an argument a valid
-   IMAP server URL as defined in [IMAP-URL].
-
-   A home server referral consists of either a tagged NO or OK, or an
-   untagged BYE response that contains a LOGIN-REFERRALS response code.
-
-   Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server
-
-   NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a
-   client falling back to anonymous login.
-
-4. Home Server Referrals
-
-   A home server referral may be returned in response to an AUTHENTICATE
-   or LOGIN command, or it may appear in the connection startup banner.
-   If a server returns a home server referral in a tagged NO response,
-   that server does not contain any mailboxes that are accessible to the
-   user.  If a server returns a home server referral in a tagged OK
-   response, it indicates that the user's personal mailboxes are
-   elsewhere, but the server contains public mailboxes which are
-   readable by the user.  After receiving a home server referral, the
-   client can not make any assumptions as to whether this was a
-   permanent or temporary move of the user.
-
-4.1.  LOGIN and AUTHENTICATE Referrals
-
-   An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a
-   home server referral if it wishes to direct the user to another IMAP4
-   server.
-
-   Example:  C: A001 LOGIN MIKE PASSWORD
-             S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user
-                     is invalid on this server. Try SERVER2.
-
-
-
-
-Gahrns                      Standards Track                     [Page 2]
-
-RFC 2221                 IMAP4 Login Referrals              October 1997
-
-
-   Example:  C: A001 LOGIN MATTHEW PASSWORD
-             S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified
-                     user's personal mailboxes located on Server2, but
-                     public mailboxes are available.
-
-   Example:  C: A001 AUTHENTICATE GSSAPI
-             <authentication exchange>
-             S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/]
-                     Specified user is invalid on this server. Try
-                     SERVER2.
-
-4.2. BYE at connection startup referral
-
-   An IMAP4 server MAY respond with an untagged BYE and a REFERRAL
-   response code that contains an IMAP URL to a home server if it is not
-   willing to accept connections and wishes to direct the client to
-   another IMAP4 server.
-
-   Example:  S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not
-                  accepting connections.  Try SERVER2
-
-5. Formal Syntax
-
-   The following syntax specification uses the augmented Backus-Naur
-   Form (BNF) as described in [ABNF].
-
-   This amends the "resp_text_code" element of the IMAP4 grammar
-   described in [RFC-2060]
-
-   resp_text_code =/ "REFERRAL" SPACE <imapurl>
-      ; See [IMAP-URL] for definition of <imapurl>
-      ; See [RFC-2060] for base definition of resp_text_code
-
-6. Security Considerations
-
-   The IMAP4 login referral mechanism makes use of IMAP URLs, and as
-   such, have the same security considerations as general internet URLs
-   [RFC-1738], and in particular IMAP URLs [IMAP-URL].
-
-   A server MUST NOT give a login referral if authentication for that
-   user fails. This is to avoid revealing information about the user's
-   account to an unauthorized user.
-
-   With the LOGIN-REFERRALS capability, it is potentially easier to
-   write a rogue 'password catching' server that collects login data and
-   then refers the client to their actual IMAP4 server.  Although
-   referrals reduce the effort to write such a server, the referral
-   response makes detection of the intrusion easier.
-
-
-
-Gahrns                      Standards Track                     [Page 3]
-
-RFC 2221                 IMAP4 Login Referrals              October 1997
-
-
-7. References
-
-   [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
-   4rev1", RFC 2060, December 1996.
-
-   [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
-   September 1997.
-
-   [RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
-   Resource Locators  (URL)", RFC 1738, December 1994.
-
-   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
-   Requirement Levels", RFC 2119, March 1997.
-
-   [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
-   Syntax Specifications: ABNF", Work in Progress.
-
-8.  Acknowledgments
-
-   Many valuable suggestions were received from private discussions and
-   the IMAP4 mailing list.  In particular, Raymond Cheng, Mark Crispin,
-   Mark Keasling Chris Newman and Larry Osterman made significant
-   contributions to this document.
-
-9. Author's Address
-
-   Mike Gahrns
-   Microsoft
-   One Microsoft Way
-   Redmond, WA, 98072
-
-   Phone: (206) 936-9833
-   EMail: mikega@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gahrns                      Standards Track                     [Page 4]
-
-RFC 2221                 IMAP4 Login Referrals              October 1997
-
-
-10.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1997).  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 implmentation may be prepared, copied, published
-   andand 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                      Standards Track                     [Page 5]
-