rfc1732.txt (9276B)
1 2 3 4 5 6 7 Network Working Group M. Crispin 8 Request for Comments: 1732 University of Washington 9 Category: Informational December 1994 10 11 12 IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS 13 14 15 Status of this Memo 16 17 This memo provides information for the Internet community. This memo 18 does not specify an Internet standard of any kind. Distribution of 19 this memo is unlimited. 20 21 Introduction 22 23 This is a summary of hints and recommendations to enable an IMAP4 24 implementation to interoperate with implementations that conform to 25 earlier specifications. None of these hints and recommendations are 26 required by the IMAP4 specification; implementors must decide for 27 themselves whether they want their implementation to fail if it 28 encounters old software. 29 30 IMAP4 has been designed to be upwards compatible with earlier 31 specifications. For the most part, IMAP4 facilities that were not in 32 earlier specifications should be invisible to clients unless the 33 client asks for the facility. 34 35 In some cases, older servers may support some of the capabilities 36 listed as being "new in IMAP4" as experimental extensions to the 37 IMAP2 protocol described in RFC 1176. 38 39 This information may not be complete; it reflects current knowledge 40 of server and client implementations as well as "folklore" acquired 41 in the evolution of the protocol. 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 Crispin [Page 1] 59 60 RFC 1732 IMAP4 - Compatibility December 1994 61 62 63 IMAP4 client interoperability with old servers 64 65 In general, a client should be able to discover whether an IMAP2 66 server supports a facility by trial-and-error; if an attempt to use a 67 facility generates a BAD response, the client can assume that the 68 server does not support the facility. 69 70 A quick way to check whether a server implementation supports the 71 IMAP4 specification is to try the CAPABILITY command. An OK response 72 that includes the IMAP4 capability value indicates a server that 73 supports IMAP4; a BAD response or one without the IMAP4 capability 74 value indicates an older server. 75 76 The following is a list of facilities that are only in IMAP4, and 77 suggestions for how new clients might interoperate with old servers: 78 79 CAPABILITY command 80 A BAD response to this command indicates that the server 81 implements IMAP2 (or IMAP2bis) and not IMAP4. 82 83 AUTHENTICATE command. 84 Use the LOGIN command. 85 86 LSUB and LIST commands 87 Try the RFC 1176 FIND command. 88 89 * in a sequence 90 Use the number of messages in the mailbox from the EXISTS 91 unsolicited response. 92 93 SEARCH extensions (character set, additional criteria) 94 Reformulate the search request using only the searching 95 options listed in search_old in the IMAP4 grammar. This may 96 entail doing multiple searches to achieve the desired 97 results. 98 99 BODYSTRUCTURE fetch data item 100 Try to fetch the non-extensible BODY data item. 101 102 body section number 0 103 Fetch the entire message and extract the header. 104 105 RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data items 106 Use RFC822.HEADER and remove the unwanted information. 107 108 BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch data 109 items Use the corresponding non-PEEK versions and manually 110 clear the \Seen flag as necessary. 111 112 113 114 Crispin [Page 2] 115 116 RFC 1732 IMAP4 - Compatibility December 1994 117 118 119 UID fetch data item and the UID commands 120 No equivalent capabilitity exists in older servers. 121 122 FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items 123 Use the corresponding non-SILENT versions and ignore the 124 untagged FETCH responses which com eback. 125 126 127 The following IMAP4 facilities were introduced in the experimental 128 IMAP2bis revisions to RFC-1176, and may be present in a server that 129 does not support the CAPABILITY command: 130 131 CREATE, DELETE, and RENAME commands 132 To test whether these commands are present, try a CREATE 133 INBOX command. If the response is NO, these commands are 134 supported by the server. If the response is BAD, they are 135 not. Older servers without the CREATE capability may sup- 136 port implicit creation of a mailbox by a COPY command with a 137 non-existant name as the destination. 138 139 APPEND command 140 To test whether this command is present, try to append a 141 zero-length stream to a mailbox name that is known not to 142 exist (or at least, highly unlikely to exist) on the remote 143 system. 144 145 SUBSCRIBE and UNSUBSCRIBE commands 146 Try the form of these commands with the optional MAILBOX 147 keyword. 148 149 EXAMINE command 150 Use the SELECT command instead. 151 152 flags and internal date argument to APPEND command 153 Try the APPEND without any flag list and internal date argu- 154 ments. 155 156 BODY, BODY[section], and FULL fetch data items 157 Use RFC822.TEXT and ALL instead. Server does not support 158 MIME. 159 160 PARTIAL command 161 Use the appropriate FETCH command and ignore the unwanted 162 data. 163 164 165 IMAP4 client implementations must accept all responses and data for- 166 mats documented in the IMAP4 specification, including those labeled 167 168 169 170 Crispin [Page 3] 171 172 RFC 1732 IMAP4 - Compatibility December 1994 173 174 175 as obsolete. This includes the COPY and STORE unsolicited responses 176 and the old format of dates and times. In particular, client imple- 177 mentations must not treat a date/time as a fixed format string; nor 178 may they assume that the time begins at a particular octet. 179 180 IMAP4 client implementations must not depend upon the presence of any 181 server extensions that are not in the base IMAP4 specification. 182 183 The experimental IMAP2bis version specified that the TRYCREATE spe- 184 cial information token is sent as a separate unsolicited OK response 185 instead of inside the NO response. 186 187 The FIND BBOARDS, FIND ALL.BBOARDS, and BBOARD commands of RFC 1176 188 are removed from IMAP4. There is no equivalent to the bboard com- 189 mands, which provided a separate namespace with implicit restrictions 190 on what may be done in that namespace. 191 192 Older server implementations may automatically create the destination 193 mailbox on COPY if that mailbox does not already exist. This was how 194 a new mailbox was created in older specifications. If the server 195 does not support the CREATE command (see above for how to test for 196 this), it will probably create a mailbox on COPY. 197 198 Older server implementations may not preserve flags or internal dates 199 on COPY. Some server implementations may not permit the preservation 200 of certain flags on COPY or their setting with APPEND as site policy. 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 Crispin [Page 4] 227 228 RFC 1732 IMAP4 - Compatibility December 1994 229 230 231 IMAP4 server interoperability with old clients 232 233 In general, there should be no interoperation problem between a 234 server conforming to the IMAP4 specification and a well-written 235 client that conforms to an earlier specification. Known problems are 236 noted below: 237 238 Poor wording in the description of the CHECK command in earlier 239 specifications implied that a CHECK command is the way to get the 240 current number of messages in the mailbox. This is incorrect. A 241 CHECK command does not necessarily result in an EXISTS response. 242 Clients must remember the most recent EXISTS value sent from the 243 server, and should not generate unnecessary CHECK commands. 244 245 An incompatibility exists with COPY in IMAP4. COPY in IMAP4 246 servers does not automatically create the destination mailbox if 247 that mailbox does not already exist. This may cause problems with 248 old clients that expect automatic mailbox creation in COPY. 249 250 The PREAUTH unsolicited response is new in IMAP4. It is highly 251 unlikely that an old client would ever see this response. 252 253 The format of dates and times has changed due to the impending end 254 of the century. Clients that fail to accept a four-digit year or 255 a signed four-digit timezone value will not work properly with 256 IMAP4. 257 258 An incompatibility exists with the use of "\" in quoted strings. 259 This is best avoided by using literals instead of quoted strings 260 if "\" or <"> is embedded in the string. 261 262 Security Considerations 263 264 Security issues are not discussed in this memo. 265 266 Author's Address: 267 268 Mark R. Crispin 269 Networks and Distributed Computing, JE-30 270 University of Washington 271 Seattle, WA 98195 272 273 Phone: (206) 543-5762 274 275 EMail: MRC@CAC.Washington.EDU 276 277 278 279 280 281 282 Crispin [Page 5] 283