These RFCs are relevant to mailutils, and many (all?) are referenced

in the mailutils documentation.

+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 2088                               Carnegie Mellon
+Cateogry: Standards Track                                   January 1997
+
+
+                    IMAP4 non-synchronizing literals
+
+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.
+
+1.   Abstract
+
+   The Internet Message Access Protocol [IMAP4] contains the "literal"
+   syntactic construct for communicating strings.  When sending a
+   literal from client to server, IMAP4 requires the client to wait for
+   the server to send a command continuation request between sending the
+   octet count and the string data.  This document specifies an
+   alternate form of literal which does not require this network round
+   trip.
+
+2.   Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+3.   Specification
+
+   The non-synchronizing literal is added an alternate form of literal,
+   and may appear in communication from client to server instead of the
+   IMAP4 form of literal.  The IMAP4 form of literal, used in
+   communication from client to server, is referred to as a
+   synchronizing literal.
+
+   Non-synchronizing literals may be used with any IMAP4 server
+   implementation which returns "LITERAL+" as one of the supported
+   capabilities to the CAPABILITY command.  If the server does not
+   advertise the LITERAL+ capability, the client must use synchronizing
+   literals instead.
+
+   The non-synchronizing literal is distinguished from the original
+   synchronizing literal by having a plus ('+') between the octet count
+   and the closing brace ('}').  The server does not generate a command
+   continuation request in response to a non-synchronizing literal, and
+
+
+
+Myers                       Standards Track                     [Page 1]
+
+RFC 2088                        LITERAL                     January 1997
+
+
+   clients are not required to wait before sending the octets of a non-
+   synchronizing literal.
+
+   The protocol receiver of an IMAP4 server must check the end of every
+   received line for an open brace ('{') followed by an octet count, a
+   plus ('+'), and a close brace ('}') immediately preceeding the CRLF.
+   If it finds this sequence, it is the octet count of a non-
+   synchronizing literal and the server MUST treat the specified number
+   of following octets and the following line as part of the same
+   command.  A server MAY still process commands and reject errors on a
+   line-by-line basis, as long as it checks for non-synchronizing
+   literals at the end of each line.
+
+   Example:    C: A001 LOGIN {11+}
+               C: FRED FOOBAR {7+}
+               C: fat man
+               S: A001 OK LOGIN completed
+
+4.   Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
+   Non-terminals referenced but not defined below are as defined by
+   [IMAP4].
+
+   literal         ::= "{" number ["+"] "}" CRLF *CHAR8
+                       ;; Number represents the number of CHAR8 octets
+
+6.   References
+
+   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
+   draft-crispin-imap-base-XX.txt, University of Washington, April 1996.
+
+   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+   Messages", STD 11, RFC 822.
+
+7.   Security Considerations
+
+   There are no known security issues with this extension.
+
+8.   Author's Address
+
+   John G. Myers
+   Carnegie-Mellon University
+   5000 Forbes Ave.
+   Pittsburgh PA, 15213-3890
+
+   Email: jgm+@cmu.edu
+
+
+
+Myers                       Standards Track                     [Page 2]
+

+
+
+
+
+
+
+Network Working Group                                        E. Levinson
+Request for Comments: 2111                                   XIson, Inc.
+Category: Standards Track                                     March 1997
+
+
+          Content-ID and Message-ID Uniform Resource Locators
+
+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.
+
+Abstract
+
+   The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow
+   references to messages and the body parts of messages.  For example,
+   within a single multipart message, one HTML body part might include
+   embedded references to other parts of the same message.
+
+1. Introduction
+
+   The use of [MIME] within email to convey Web pages and their
+   associated images requires a URL scheme to permit the HTML to refer
+   to the images or other data included in the message.  The Content-ID
+   Uniform Resource Locator, "cid:", serves that purpose.
+
+   Similarly Net News readers use Message-IDs to link related messages
+   together.  The Message-ID URL provides a scheme, "mid:", to refer to
+   such messages as a "resource".
+
+   The "mid" (Message-ID) and "cid" (Content-ID) URL schemes provide
+   identifiers for messages and their body parts.  The "mid" scheme uses
+   (a part of) the message-id of an email message to refer to a specific
+   message.  The "cid" scheme refers to a specific body part of a
+   message; its use is generally limited to references to other body
+   parts in the same message as the referring body part.  The "mid"
+   scheme may also refer to a specific body part within a designated
+   message, by including the content-ID's address.
+
+   A note on terminology.  The terms "body part" and "MIME entity" are
+   used interchangeably.  They refer to the headers and body of a MIME
+   message, either the message itself or one of the body parts contained
+   in a Multipart message.
+
+
+
+
+
+Levinson                    Standards Track                     [Page 1]
+
+RFC 2111                    CID and MID URLs                  March 1997
+
+
+2. The MID and CID URL Schemes
+
+   RFC1738 [URL] reserves the "mid" and "cid" schemes for Message-ID and
+   Content-ID respectively.  This memorandum defines the syntax for
+   those URLs.  Because they use the same syntactic elements they are
+   presented together.
+
+   The URLs take the form
+
+        content-id    = url-addr-spec
+
+        message-id    = url-addr-spec
+
+        url-addr-spec = addr-spec  ; URL encoding of RFC 822 addr-spec
+
+        cid-url       = "cid" ":" content-id
+
+        mid-url       = "mid" ":" message-id [ "/" content-id ]
+
+      Note: in Internet mail messages, the addr-spec in a Content-ID
+      [MIME] or Message-ID [822] header are enclosed in angle brackets
+      (<>).  Since addr-spec in a Message-ID or Content-ID might contain
+      characters not allowed within a URL; any such character (including
+      "/", which is reserved within the "mid" scheme) must be hex-
+      encoded using the %hh escape mechanism in [URL].
+
+   A "mid" URL with only a "message-id" refers to an entire message.
+   With the appended "content-id", it refers to a body part within a
+   message, as does a "cid" URL.  The Content-ID of a MIME body part is
+   required to be globally unique.  However, in many systems that store
+   messages, body parts are not indexed independently their context
+   (message).  The "mid" URL long form was designed to supply the
+   context needed to support interoperability with such systems.
+
+   A implementation conforming to this specification is required to
+   support the "mid" URL long form (message-id/content-id).  Conforming
+   implementations can choose to, but are not required to, take
+   advantage of the content-id's uniqueness and interpret a "cid" URL to
+   refer to any body part within the message store.
+
+   In limited circumstances (e.g., within multipart/alternate), a single
+   message may contain several body parts that have the same Content-ID.
+   That occurs, for example, when identical data can be accessed through
+   different methods [MIME, sect. 7.2.3].  In those cases, conforming
+   implementations are required to use the rules of the containing MIME
+   entity (e.g., multi-part/alternate) to select the body part to which
+   the Content-ID refers.
+
+
+
+
+Levinson                    Standards Track                     [Page 2]
+
+RFC 2111                    CID and MID URLs                  March 1997
+
+
+   A "cid" URL is converted to the corresponding Content-ID message
+   header [MIME] by removing the "cid:" prefix, converting %hh hex-
+   escaped characters to their ASCII equivalents and enclosing the
+   remaining parts with an angle bracket pair, "<" and ">".  For
+   example, "mid:foo4%25foo1@bar.net" corresponds to
+
+        Message-ID: <foo4%foo1@bar.net>
+
+   A "mid" URL is converted to a Message-ID or Message-ID/Content-ID
+   pair in a similar fashion.
+
+   Both message-id and content-id are required to be globally unique.
+   That is, no two different messages will ever have the same Message-ID
+   addr-spec; no different body parts will ever have the same Content-ID
+   addr-spec.  A common technique used by many message systems is to use
+   a time and date stamp along with the local host's domain name, e.g.,
+   950124.162336@XIson.com.
+
+Some Examples
+
+   The following message contains an HTML body part that refers to an
+   image contained in another body part.  Both body parts are contained
+   in a Multipart/Related MIME entity.  The HTML IMG tag contains a
+   cidurl which points to the image.
+
+     From: foo1@bar.net
+     To: foo2@bar.net
+     Subject: A simple example
+     Mime-Version: 1.0
+     Content-Type: multipart/related; boundary="boundary-example-1";
+                   type=Text/HTML
+
+     --boundary-example 1
+     Content-Type: Text/HTML; charset=US-ASCII
+
+     ... text of the HTML document, which might contain a hyperlink
+     to the other body part, for example through a statement such as:
+     <IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">
+
+     --boundary-example-1
+     Content-ID: foo4*foo1@bar.net
+     Content-Type: IMAGE/GIF
+     Content-Transfer-Encoding: BASE64
+
+
+
+
+
+
+
+
+Levinson                    Standards Track                     [Page 3]
+
+RFC 2111                    CID and MID URLs                  March 1997
+
+
+     R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
+     NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
+     etc...
+
+     --boundary-example-1--
+
+   The following message points to another message (hopefully still in
+   the recipient's message store).
+
+     From: bar@none.com
+     To: phooey@all.com
+     Subject: Here's how to do it
+     Content-type: text/html; charset=usascii
+
+     ...  The items in my
+     <A HREF= "mid:960830.1639@XIson.com/partA.960830.1639@XIson.com">
+     previous message</A>, shows how the approach you propose can be
+     used to accomplish ...
+
+3. Security Considerations
+
+   The URLs defined here provide an addressing or referencing mechanism.
+   The values of these URLs disclose no more about the originators
+   environment than the corresponding Message-ID and Content-ID values.
+   Where concern exists about such disclosures the originator of a
+   message using mid and cid URLs must take precautions to insure that
+   confidential information is not disclosed.  Those precautions should
+   already be in place to handle existing mail use of the Message-ID and
+   Content-ID.
+
+4. References
+
+[822]     Crocker, D., "Standard for the Format of ARPA Internet Text
+          Messages," August 1982, University of Delaware, STD 11, RFC
+          822.
+
+[MIME]    N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
+          Extensions) Part One:  Mechanisms for Specifying and
+          Describing the Format of Internet Message Bodies,"
+          September 1993, RFC 1521.
+
+[URL]     Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform
+          Resource Locators (URL)," December 1994.
+
+[MULREL]  E. Levinson, "The MIME Multipart/Related Content-type,"
+          December 1995, RFC 1874.
+
+
+
+
+
+Levinson                    Standards Track                     [Page 4]
+
+RFC 2111                    CID and MID URLs                  March 1997
+
+
+5. Acknowledgments
+
+   The original concept of "mid" and "cid" URLs were part of the Tim
+   Berners-Lee's original vision of the World Wide Web. The ideas and
+   design have benefited greatly by discussions with Harald Alvestrand,
+   Dan Connolly, Roy Fielding, Larry Masinter, Jacob Palme, and others
+   in the MHTML working group.
+
+6. Author's Address
+
+   Edward Levinson
+   47 Clive Street
+   Metuchen, NJ  08840-1060
+   USA
+   +1 908 549 3716
+   <XIson@cnj.digex.net>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levinson                    Standards Track                     [Page 5]
+

+
+
+
+
+
+
+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]
+