imapext-2007

annotate docs/rfc/rfc5092.txt @ 0:ada5e610ab86

find changesets by author, revision, files, or words in the commit message
imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1
yuuji@0 2
yuuji@0 3
yuuji@0 4
yuuji@0 5
yuuji@0 6
yuuji@0 7 Network Working Group A. Melnikov, Ed.
yuuji@0 8 Request for Comments: 5092 Isode Ltd.
yuuji@0 9 Obsoletes: 2192 C. Newman
yuuji@0 10 Updates: 4467 Sun Microsystems
yuuji@0 11 Category: Standards Track November 2007
yuuji@0 12
yuuji@0 13
yuuji@0 14 IMAP URL Scheme
yuuji@0 15
yuuji@0 16 Status of This Memo
yuuji@0 17
yuuji@0 18 This document specifies an Internet standards track protocol for the
yuuji@0 19 Internet community, and requests discussion and suggestions for
yuuji@0 20 improvements. Please refer to the current edition of the "Internet
yuuji@0 21 Official Protocol Standards" (STD 1) for the standardization state
yuuji@0 22 and status of this protocol. Distribution of this memo is unlimited.
yuuji@0 23
yuuji@0 24 Abstract
yuuji@0 25
yuuji@0 26 IMAP (RFC 3501) is a rich protocol for accessing remote message
yuuji@0 27 stores. It provides an ideal mechanism for accessing public mailing
yuuji@0 28 list archives as well as private and shared message stores. This
yuuji@0 29 document defines a URL scheme for referencing objects on an IMAP
yuuji@0 30 server.
yuuji@0 31
yuuji@0 32 This document obsoletes RFC 2192. It also updates RFC 4467.
yuuji@0 33
yuuji@0 34
yuuji@0 35
yuuji@0 36
yuuji@0 37
yuuji@0 38
yuuji@0 39
yuuji@0 40
yuuji@0 41
yuuji@0 42
yuuji@0 43
yuuji@0 44
yuuji@0 45
yuuji@0 46
yuuji@0 47
yuuji@0 48
yuuji@0 49
yuuji@0 50
yuuji@0 51
yuuji@0 52
yuuji@0 53
yuuji@0 54
yuuji@0 55
yuuji@0 56
yuuji@0 57
yuuji@0 58 Melnikov & Newman Standards Track [Page 1]
yuuji@0 59
yuuji@0 60 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 61
yuuji@0 62
yuuji@0 63 Table of Contents
yuuji@0 64
yuuji@0 65 1. Introduction ....................................................2
yuuji@0 66 2. Conventions Used in This Document ...............................3
yuuji@0 67 3. IMAP userinfo Component (iuserinfo) .............................4
yuuji@0 68 3.1. IMAP Mailbox Naming Scope ..................................4
yuuji@0 69 3.2. IMAP User Name and Authentication Mechanism ................4
yuuji@0 70 3.3. Limitations of enc-user ....................................6
yuuji@0 71 4. IMAP Server .....................................................7
yuuji@0 72 5. Lists of Messages ...............................................7
yuuji@0 73 6. A Specific Message or Message Part ..............................8
yuuji@0 74 6.1. URLAUTH Authorized URL .....................................9
yuuji@0 75 6.1.1. Concepts ............................................9
yuuji@0 76 6.1.1.1. URLAUTH ....................................9
yuuji@0 77 6.1.1.2. Mailbox Access Key .........................9
yuuji@0 78 6.1.1.3. Authorized Access Identifier ...............9
yuuji@0 79 6.1.1.4. Authorization Mechanism ...................10
yuuji@0 80 6.1.1.5. Authorization Token .......................10
yuuji@0 81 6.1.2. URLAUTH Extensions to IMAP URL .....................10
yuuji@0 82 7. Relative IMAP URLs .............................................11
yuuji@0 83 7.1. absolute-path References ..................................12
yuuji@0 84 7.2. relative-path References ..................................12
yuuji@0 85 8. Internationalization Considerations ............................13
yuuji@0 86 9. Examples .......................................................13
yuuji@0 87 9.1. Examples of Relative URLs .................................16
yuuji@0 88 10. Security Considerations .......................................16
yuuji@0 89 10.1. Security Considerations Specific to URLAUTH Authorized
yuuji@0 90 URL ......................................................17
yuuji@0 91 11. ABNF for IMAP URL Scheme ......................................17
yuuji@0 92 12. IANA Considerations ...........................................21
yuuji@0 93 12.1. IANA Registration of imap: URI Scheme ....................21
yuuji@0 94 13. References ....................................................22
yuuji@0 95 13.1. Normative References .....................................22
yuuji@0 96 13.2. Informative References ...................................23
yuuji@0 97 Appendix A. Sample Code............................................24
yuuji@0 98 Appendix B. List of Changes since RFC 2192.........................30
yuuji@0 99 Appendix C. List of Changes since RFC 4467.........................31
yuuji@0 100 Appendix D. Acknowledgments........................................31
yuuji@0 101
yuuji@0 102 1. Introduction
yuuji@0 103
yuuji@0 104 The IMAP URL scheme is used to designate IMAP servers, mailboxes,
yuuji@0 105 messages, MIME bodies [MIME], and search programs on Internet hosts
yuuji@0 106 accessible using the IMAP protocol over TCP.
yuuji@0 107
yuuji@0 108 The IMAP URL follows the common Internet scheme syntax as defined in
yuuji@0 109 [URI-GEN]. If :<port> is omitted, the port defaults to 143 (as
yuuji@0 110 defined in Section 2.1 of [IMAP4]).
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Melnikov & Newman Standards Track [Page 2]
yuuji@0 115
yuuji@0 116 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 117
yuuji@0 118
yuuji@0 119 An absolute IMAP URL takes one of the following forms:
yuuji@0 120
yuuji@0 121 imap://<iserver>[/]
yuuji@0 122
yuuji@0 123 imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]
yuuji@0 124
yuuji@0 125 imap://<iserver>/<enc-mailbox>[<uidvalidity>]<iuid>
yuuji@0 126 [<isection>][<ipartial>][<iurlauth>]
yuuji@0 127
yuuji@0 128 The first form is used to refer to an IMAP server (see Section 4),
yuuji@0 129 the second form refers to the contents of a mailbox or a set of
yuuji@0 130 messages resulting from a search (see Section 5), and the final form
yuuji@0 131 refers to a specific message or message part, and possibly a byte
yuuji@0 132 range in that part (see Section 6). If [URLAUTH] extension is
yuuji@0 133 supported, then the final form can have the <iurlauth> component (see
yuuji@0 134 Section 6.1 for more details).
yuuji@0 135
yuuji@0 136 The <iserver> component common to all types of absolute IMAP URLs has
yuuji@0 137 the following syntax expressed in ABNF [ABNF]:
yuuji@0 138
yuuji@0 139 [iuserinfo "@"] host [ ":" port ]
yuuji@0 140
yuuji@0 141 The <iserver> component is the same as "authority" defined in
yuuji@0 142 [URI-GEN]. The syntax and uses of the <iuserinfo> ("IMAP userinfo
yuuji@0 143 component") are described in detail in Section 3. The syntax of
yuuji@0 144 <host> and <port> is described in [URI-GEN].
yuuji@0 145
yuuji@0 146 2. Conventions Used in This Document
yuuji@0 147
yuuji@0 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
yuuji@0 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
yuuji@0 150 document are to be interpreted as described in RFC 2119 [KEYWORDS].
yuuji@0 151
yuuji@0 152 This document references many productions from [URI-GEN]. When the
yuuji@0 153 document needs to emphasize IMAP URI-specific differences from [URI-
yuuji@0 154 GEN] (i.e., for parts of IMAP URIs that have more restricted syntax
yuuji@0 155 than generic URIs), it uses a non-terminal i<foo> to define an IMAP-
yuuji@0 156 specific version of the non-terminal <foo> from [URI-GEN].
yuuji@0 157
yuuji@0 158 Note that the ABNF syntax shown in Section 11 is normative. Sections
yuuji@0 159 2-6 may use a less formal syntax that does not necessarily match the
yuuji@0 160 normative ABNF shown in Section 11. If there are any differences
yuuji@0 161 between the syntax shown in Sections 2-6 and Section 11, then the
yuuji@0 162 syntax shown in Section 11 must be treated as authoritative. Non-
yuuji@0 163 syntax requirements included in Sections 2-6 are, of course,
yuuji@0 164 normative.
yuuji@0 165
yuuji@0 166
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Melnikov & Newman Standards Track [Page 3]
yuuji@0 171
yuuji@0 172 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 173
yuuji@0 174
yuuji@0 175 3. IMAP userinfo Component (iuserinfo)
yuuji@0 176
yuuji@0 177 The <iuserinfo> component conforms to the generic syntax of
yuuji@0 178 <userinfo> defined in [URI-GEN]. It has the following syntax
yuuji@0 179 expressed in ABNF [ABNF]:
yuuji@0 180
yuuji@0 181 enc-user [iauth] / [enc-user] iauth
yuuji@0 182
yuuji@0 183 The meaning of the different parts is described in subsections of
yuuji@0 184 this section.
yuuji@0 185
yuuji@0 186 3.1. IMAP Mailbox Naming Scope
yuuji@0 187
yuuji@0 188 The "enc-user" part of the "iuserinfo" component, if present, denotes
yuuji@0 189 mailbox naming scope. If it is absent, the IMAP URL can only
yuuji@0 190 reference mailboxes with globally unique names, i.e., mailboxes with
yuuji@0 191 names that don't change depending on the user the client
yuuji@0 192 authenticated as to the IMAP server. Note that not all IMAP
yuuji@0 193 implementations support globally unique names.
yuuji@0 194
yuuji@0 195 For example, a personal mailbox described by the following URL
yuuji@0 196 <imap://michael@example.org/INBOX> is most likely different from a
yuuji@0 197 personal mailbox described by <imap://bester@example.org/INBOX>, even
yuuji@0 198 though both URLs use the same mailbox name.
yuuji@0 199
yuuji@0 200 3.2. IMAP User Name and Authentication Mechanism
yuuji@0 201
yuuji@0 202 The userinfo component (see [URI-GEN]) of an IMAP URI may contain an
yuuji@0 203 IMAP user name (a.k.a. authorization identity [SASL], "enc-user")
yuuji@0 204 and/or an authentication mechanism. (Note that the "enc-user" also
yuuji@0 205 defines a mailbox naming scope as described in Section 3.1). The
yuuji@0 206 IMAP user name and the authentication mechanism are used in the
yuuji@0 207 "LOGIN" or "AUTHENTICATE" commands after making the connection to the
yuuji@0 208 IMAP server.
yuuji@0 209
yuuji@0 210 If no user name and no authentication mechanism are supplied, the
yuuji@0 211 client MUST authenticate as anonymous to the server. If the server
yuuji@0 212 advertises AUTH=ANONYMOUS IMAP capability, the client MUST use the
yuuji@0 213 AUTHENTICATE command with ANONYMOUS [ANONYMOUS] SASL mechanism. If
yuuji@0 214 SASL ANONYMOUS is not available, the (case-insensitive) user name
yuuji@0 215 "anonymous" is used with the "LOGIN" command and the Internet email
yuuji@0 216 address of the end user accessing the resource is supplied as the
yuuji@0 217 password. The latter option is given in order to provide for
yuuji@0 218 interoperability with deployed servers.
yuuji@0 219
yuuji@0 220 Note that, as described in RFC 3501, the "LOGIN" command MUST NOT be
yuuji@0 221 used when the IMAP server advertises the LOGINDISABLED capability.
yuuji@0 222
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Melnikov & Newman Standards Track [Page 4]
yuuji@0 227
yuuji@0 228 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 229
yuuji@0 230
yuuji@0 231 An authentication mechanism (as used by the IMAP AUTHENTICATE
yuuji@0 232 command) can be expressed by adding ";AUTH=<enc-auth-type>" to the
yuuji@0 233 end of the user name in an IMAP URL. When such an <enc-auth-type> is
yuuji@0 234 indicated, the client SHOULD request appropriate credentials from
yuuji@0 235 that mechanism and use the "AUTHENTICATE" command instead of the
yuuji@0 236 "LOGIN" command. If no user name is specified, one MUST be obtained
yuuji@0 237 from the mechanism or requested from the user/configuration as
yuuji@0 238 appropriate.
yuuji@0 239
yuuji@0 240 The string ";AUTH=*" indicates that the client SHOULD select an
yuuji@0 241 appropriate authentication mechanism. (Though the '*' character in
yuuji@0 242 this usage is not strictly a delimiter, it is being treated like a
yuuji@0 243 sub-delim [URI-GEN] in this instance. It MUST NOT be percent-encoded
yuuji@0 244 in this usage, as ";AUTH=%2A" will not match this production.) It
yuuji@0 245 MAY use any mechanism listed in the response to the CAPABILITY
yuuji@0 246 command (or CAPABILITY response code) or use an out-of-band security
yuuji@0 247 service resulting in a PREAUTH connection. If no user name is
yuuji@0 248 specified and no appropriate authentication mechanisms are available,
yuuji@0 249 the client SHOULD fall back to anonymous login as described above.
yuuji@0 250 The behavior prescribed in this section allows a URL that grants
yuuji@0 251 read-write access to authorized users and read-only anonymous access
yuuji@0 252 to other users.
yuuji@0 253
yuuji@0 254 If a user name is included with no authentication mechanism, then
yuuji@0 255 ";AUTH=*" is assumed.
yuuji@0 256
yuuji@0 257 Clients must take care when resolving a URL that requires or requests
yuuji@0 258 any sort of authentication, since URLs can easily come from untrusted
yuuji@0 259 sources. Supplying authentication credentials to the wrong server
yuuji@0 260 may compromise the security of the user's account; therefore, the
yuuji@0 261 program resolving the URL should meet at least one of the following
yuuji@0 262 criteria in this case:
yuuji@0 263
yuuji@0 264 1) The URL comes from a trusted source, such as a referral server
yuuji@0 265 that the client has validated and trusts according to site policy.
yuuji@0 266 Note that user entry of the URL may or may not count as a trusted
yuuji@0 267 source, depending on the experience level of the user and site
yuuji@0 268 policy.
yuuji@0 269
yuuji@0 270 2) Explicit local site policy permits the client to connect to the
yuuji@0 271 server in the URL. For example, a company example.com may have a
yuuji@0 272 site policy to trust all IMAP server names ending in example.com,
yuuji@0 273 whereas such a policy would be unwise for example.edu where random
yuuji@0 274 students can set up IMAP servers.
yuuji@0 275
yuuji@0 276 3) The user confirms that connecting to that domain name with the
yuuji@0 277 specified credentials and/or mechanism is permitted. For example,
yuuji@0 278 when using "LOGIN" or SASL PLAIN with Transport Layer Security
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Melnikov & Newman Standards Track [Page 5]
yuuji@0 283
yuuji@0 284 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 285
yuuji@0 286
yuuji@0 287 (TLS), the IMAP URL client presents a dialog box "Is it OK to send
yuuji@0 288 your password to server "example.com"? Please be aware the owners
yuuji@0 289 of example.com will be able to reuse your password to connect to
yuuji@0 290 other servers on your behalf".
yuuji@0 291
yuuji@0 292 4) A mechanism is used that validates the server before passing
yuuji@0 293 potentially compromising client credentials. For example, a site
yuuji@0 294 has a designated TLS certificate used to certify site-trusted IMAP
yuuji@0 295 server certificates, and this has been configured explicitly into
yuuji@0 296 the IMAP URL client. Another example is use of a Simple
yuuji@0 297 Authentication and Security Layer (SASL) mechanism such as
yuuji@0 298 DIGEST-MD5 [DIGEST-MD5], which supports mutual authentication.
yuuji@0 299
yuuji@0 300 5) An authentication mechanism is used that will not reveal any
yuuji@0 301 information to the server that could be used to compromise future
yuuji@0 302 connections. Examples are SASL ANONYMOUS [ANONYMOUS] or GSSAPI
yuuji@0 303 [GSSAPI].
yuuji@0 304
yuuji@0 305 URLs that do not include a user name but include an authentication
yuuji@0 306 mechanism (";AUTH=<mech>") must be treated with extra care, since for
yuuji@0 307 some <mech>s they are more likely to compromise the user's primary
yuuji@0 308 account. A URL containing ";AUTH=*" must also be treated with extra
yuuji@0 309 care since it might fall back on a weaker security mechanism.
yuuji@0 310 Finally, clients are discouraged from using a plaintext password as a
yuuji@0 311 fallback with ";AUTH=*" unless the connection has strong encryption.
yuuji@0 312
yuuji@0 313 A program interpreting IMAP URLs MAY cache open connections to an
yuuji@0 314 IMAP server for later reuse. If a URL contains a user name, only
yuuji@0 315 connections authenticated as that user may be reused. If a URL does
yuuji@0 316 not contain a user name or authentication mechanism, then only an
yuuji@0 317 anonymous connection may be reused.
yuuji@0 318
yuuji@0 319 Note that if unsafe or reserved characters such as " " (space) or ";"
yuuji@0 320 are present in the user name or authentication mechanism, they MUST
yuuji@0 321 be percent-encoded as described in [URI-GEN].
yuuji@0 322
yuuji@0 323 3.3. Limitations of enc-user
yuuji@0 324
yuuji@0 325 As per Sections 3.1 and 3.2 of this document, the IMAP URI enc-user
yuuji@0 326 has two purposes:
yuuji@0 327
yuuji@0 328 1) It provides context for user-specific mailbox paths such as
yuuji@0 329 "INBOX" (Section 3.1).
yuuji@0 330
yuuji@0 331 2) It specifies that resolution of the URL requires logging in as
yuuji@0 332 that user and limits use of that URL to only that user (Section
yuuji@0 333 3.2).
yuuji@0 334
yuuji@0 335
yuuji@0 336
yuuji@0 337
yuuji@0 338 Melnikov & Newman Standards Track [Page 6]
yuuji@0 339
yuuji@0 340 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 341
yuuji@0 342
yuuji@0 343 An obvious limitation of using the same field for both purposes is
yuuji@0 344 that the URL can be resolved only by the mailbox owner. In order to
yuuji@0 345 avoid this restriction, implementations should use globally unique
yuuji@0 346 mailbox names (see Section 3.1) whenever possible.
yuuji@0 347
yuuji@0 348 Note: There is currently no general way in IMAP of learning a
yuuji@0 349 globally unique name for a mailbox. However, by looking at the
yuuji@0 350 NAMESPACE [NAMESPACE] command result, it is possible to determine
yuuji@0 351 whether or not a mailbox name is globally unique.
yuuji@0 352
yuuji@0 353 The URLAUTH component overrides the second purpose of the enc-user in
yuuji@0 354 the IMAP URI and by default permits the URI to be resolved by any
yuuji@0 355 user permitted by the <access> identifier. URLAUTH and <access>
yuuji@0 356 identifier are described in Section 6.1.
yuuji@0 357
yuuji@0 358 4. IMAP Server
yuuji@0 359
yuuji@0 360 An IMAP URL referring to an IMAP server has the following form:
yuuji@0 361
yuuji@0 362 imap://<iserver>[/]
yuuji@0 363
yuuji@0 364 This URL type is frequently used to describe a location of an IMAP
yuuji@0 365 server, both in referrals and in configuration. It may optionally
yuuji@0 366 contain the <iuserinfo> component (see Sections 3 and 11). A program
yuuji@0 367 interpreting this URL would issue the standard set of commands it
yuuji@0 368 uses to present a view of the content of the IMAP server, as visible
yuuji@0 369 to the user described by the "enc-user" part of the <iuserinfo>
yuuji@0 370 component, if the "enc-user" part is specified.
yuuji@0 371
yuuji@0 372 5. Lists of Messages
yuuji@0 373
yuuji@0 374 An IMAP URL referring to a list of messages has the following form:
yuuji@0 375
yuuji@0 376 imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]
yuuji@0 377
yuuji@0 378 The <enc-mailbox> field is used as the argument to the IMAP4 "SELECT"
yuuji@0 379 or "EXAMINE" command. Note that if unsafe or reserved characters
yuuji@0 380 such as " " (space), ";", or "?" are present in <enc-mailbox>, they
yuuji@0 381 MUST be percent-encoded as described in [URI-GEN].
yuuji@0 382
yuuji@0 383 The <uidvalidity> field is optional. If it is present, it MUST be
yuuji@0 384 the same as the value of IMAP4 UIDVALIDITY response code at the time
yuuji@0 385 the URL was created. This MUST be used by the program interpreting
yuuji@0 386 the IMAP URL to determine if the URL is stale. If the IMAP URL is
yuuji@0 387 stale, then the program should behave as if the corresponding mailbox
yuuji@0 388 doesn't exist.
yuuji@0 389
yuuji@0 390
yuuji@0 391
yuuji@0 392
yuuji@0 393
yuuji@0 394 Melnikov & Newman Standards Track [Page 7]
yuuji@0 395
yuuji@0 396 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 397
yuuji@0 398
yuuji@0 399 Note that the <uidvalidity> field is a modifier to the <enc-mailbox>,
yuuji@0 400 i.e., it is considered a part of the last "component" (as used in
yuuji@0 401 [URI-GEN]) of the <enc-mailbox>. This is significant during relative
yuuji@0 402 URI resolution.
yuuji@0 403
yuuji@0 404 The "?<enc-search>" field is optional. If it is not present, the
yuuji@0 405 program interpreting the URL will present the entire content of the
yuuji@0 406 mailbox.
yuuji@0 407
yuuji@0 408 If the "?<enc-search>" field is present, the program interpreting the
yuuji@0 409 URL should use the contents of this field as arguments following an
yuuji@0 410 IMAP4 SEARCH command. These arguments are likely to contain unsafe
yuuji@0 411 characters such as " " (space) (which are likely to be present in the
yuuji@0 412 <enc-search>). If unsafe characters are present, they MUST be
yuuji@0 413 percent-encoded as described in [URI-GEN].
yuuji@0 414
yuuji@0 415 Note that quoted strings and non-synchronizing literals [LITERAL+]
yuuji@0 416 are allowed in the <enc-search> content; however, synchronizing
yuuji@0 417 literals are not allowed, as their presence would effectively mean
yuuji@0 418 that the agent interpreting IMAP URLs needs to parse an <enc-search>
yuuji@0 419 content, find all synchronizing literals, and perform proper command
yuuji@0 420 continuation request handling (see Sections 4.3 and 7 of [IMAP4]).
yuuji@0 421
yuuji@0 422 6. A Specific Message or Message Part
yuuji@0 423
yuuji@0 424 An IMAP URL referring to a specific message or message part has the
yuuji@0 425 following form:
yuuji@0 426
yuuji@0 427 imap://<iserver>/<enc-mailbox>[<uidvalidity>]<iuid>
yuuji@0 428 [<isection>][<ipartial>][<iurlauth>]
yuuji@0 429
yuuji@0 430 The <enc-mailbox> and [uidvalidity] are as defined in Section 5
yuuji@0 431 above.
yuuji@0 432
yuuji@0 433 If <uidvalidity> is present in this form, it SHOULD be used by the
yuuji@0 434 program interpreting the URL to determine if the URL is stale.
yuuji@0 435
yuuji@0 436 The <iuid> refers to an IMAP4 message Unique Identifier (UID), and it
yuuji@0 437 SHOULD be used as the <set> argument to the IMAP4 "UID FETCH"
yuuji@0 438 command.
yuuji@0 439
yuuji@0 440 The <isection> field is optional. If not present, the URL refers to
yuuji@0 441 the entire Internet message as returned by the IMAP command "UID
yuuji@0 442 FETCH <uid> BODY.PEEK[]". If present, the URL refers to the object
yuuji@0 443 returned by a "UID FETCH <uid> BODY.PEEK[<section>]" command. The
yuuji@0 444 type of the object may be determined by using a "UID FETCH <uid>
yuuji@0 445 BODYSTRUCTURE" command and locating the appropriate part in the
yuuji@0 446
yuuji@0 447
yuuji@0 448
yuuji@0 449
yuuji@0 450 Melnikov & Newman Standards Track [Page 8]
yuuji@0 451
yuuji@0 452 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 453
yuuji@0 454
yuuji@0 455 resulting BODYSTRUCTURE. Note that unsafe characters in [isection]
yuuji@0 456 MUST be percent-encoded as described in [URI-GEN].
yuuji@0 457
yuuji@0 458 The <ipartial> field is optional. If present, it effectively appends
yuuji@0 459 "<<partial-range>>" to the end of the UID FETCH BODY.PEEK[<section>]
yuuji@0 460 command constructed as described in the previous paragraph. In other
yuuji@0 461 words, it allows the client to request a byte range of the
yuuji@0 462 message/message part.
yuuji@0 463
yuuji@0 464 The <iurlauth> field is described in detail in Section 6.1.
yuuji@0 465
yuuji@0 466 6.1. URLAUTH Authorized URL
yuuji@0 467
yuuji@0 468 URLAUTH authorized URLs are only supported by an IMAP server
yuuji@0 469 advertising the URLAUTH IMAP capability [URLAUTH].
yuuji@0 470
yuuji@0 471 6.1.1. Concepts
yuuji@0 472
yuuji@0 473 6.1.1.1. URLAUTH
yuuji@0 474
yuuji@0 475 URLAUTH is a component, appended at the end of a URL, that conveys
yuuji@0 476 authorization to access the data addressed by that URL. It contains
yuuji@0 477 an authorized access identifier, an authorization mechanism name, and
yuuji@0 478 an authorization token. The authorization token is generated from
yuuji@0 479 the URL, the authorized access identifier, authorization mechanism
yuuji@0 480 name, and a mailbox access key.
yuuji@0 481
yuuji@0 482 Note: This specification only allows for the URLAUTH component in
yuuji@0 483 IMAP URLs describing a message or its part.
yuuji@0 484
yuuji@0 485 6.1.1.2. Mailbox Access Key
yuuji@0 486
yuuji@0 487 The mailbox access key is an unpredictable, random string. To ensure
yuuji@0 488 unpredictability, the random string with at least 128 bits of entropy
yuuji@0 489 is generated by software or hardware (not by the human user).
yuuji@0 490
yuuji@0 491 Each user has a table of mailboxes and an associated mailbox access
yuuji@0 492 key for each mailbox. Consequently, the mailbox access key is per-
yuuji@0 493 user and per-mailbox. In other words, two users sharing the same
yuuji@0 494 mailbox each have a different mailbox access key for that mailbox,
yuuji@0 495 and each mailbox accessed by a single user also has a different
yuuji@0 496 mailbox access key.
yuuji@0 497
yuuji@0 498 6.1.1.3. Authorized Access Identifier
yuuji@0 499
yuuji@0 500 The authorized <access> identifier restricts use of the URLAUTH
yuuji@0 501 authorized URL to certain users authorized on the server, as
yuuji@0 502 described in Section 6.1.2.
yuuji@0 503
yuuji@0 504
yuuji@0 505
yuuji@0 506 Melnikov & Newman Standards Track [Page 9]
yuuji@0 507
yuuji@0 508 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 509
yuuji@0 510
yuuji@0 511 6.1.1.4. Authorization Mechanism
yuuji@0 512
yuuji@0 513 The authorization mechanism is the algorithm by which the URLAUTH is
yuuji@0 514 generated and subsequently verified, using the mailbox access key.
yuuji@0 515
yuuji@0 516 6.1.1.5. Authorization Token
yuuji@0 517
yuuji@0 518 The authorization token is a deterministic string of at least 128
yuuji@0 519 bits that an entity with knowledge of the secret mailbox access key
yuuji@0 520 and URL authorization mechanism can use to verify the URL.
yuuji@0 521
yuuji@0 522 6.1.2. URLAUTH Extensions to IMAP URL
yuuji@0 523
yuuji@0 524 A specific message or message part IMAP URL can optionally contain
yuuji@0 525 ";EXPIRE=<datetime>" and/or ";URLAUTH=<access>:<mech>:<token>".
yuuji@0 526
yuuji@0 527 When ";EXPIRE=<datetime>" is used, this indicates the latest date and
yuuji@0 528 time that the URL is valid. After that date and time, the URL has
yuuji@0 529 expired and server implementations MUST reject the URL. If
yuuji@0 530 ";EXPIRE=<datetime>" is not used, the URL has no expiration, but can
yuuji@0 531 still be revoked using the RESETKEY command [URLAUTH].
yuuji@0 532
yuuji@0 533 The URLAUTH takes the form ";URLAUTH=<access>:<mech>:<token>", and it
yuuji@0 534 MUST be at the end of the URL. It is composed of three parts. The
yuuji@0 535 <access> portion provides the authorized access identifiers that may
yuuji@0 536 constrain the operations and users that are permitted to use this
yuuji@0 537 URL. The <mech> portion provides the authorization mechanism used by
yuuji@0 538 the IMAP server to generate the authorization token that follows.
yuuji@0 539 The <token> portion provides the authorization token, which can be
yuuji@0 540 generated using the GENURLAUTH command [URLAUTH].
yuuji@0 541
yuuji@0 542 The "submit+" <access> identifier prefix, followed by a userid,
yuuji@0 543 indicates that only a userid authorized as a message submission
yuuji@0 544 entity on behalf of the specified userid is permitted to use this
yuuji@0 545 URL. The IMAP server does not validate the specified userid but does
yuuji@0 546 validate that the IMAP session has an authorization identity that is
yuuji@0 547 authorized as a message submission entity. The authorized message
yuuji@0 548 submission entity MUST validate the userid prior to contacting the
yuuji@0 549 IMAP server.
yuuji@0 550
yuuji@0 551 The "user+" <access> identifier prefix, followed by a userid,
yuuji@0 552 indicates that use of this URL is limited to IMAP sessions that are
yuuji@0 553 logged in as the specified userid (that is, have authorization
yuuji@0 554 identity as that userid).
yuuji@0 555
yuuji@0 556 Note: If a SASL mechanism that provides both authorization and
yuuji@0 557 authentication identifiers is used to authenticate to the IMAP
yuuji@0 558 server, the "user+" <access> identifier MUST match the
yuuji@0 559
yuuji@0 560
yuuji@0 561
yuuji@0 562 Melnikov & Newman Standards Track [Page 10]
yuuji@0 563
yuuji@0 564 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 565
yuuji@0 566
yuuji@0 567 authorization identifier. If the SASL mechanism can't transport
yuuji@0 568 the authorization identifier, the "user+" <access> identifier MUST
yuuji@0 569 match the authorization identifier derived from the authentication
yuuji@0 570 identifier (see [SASL]).
yuuji@0 571
yuuji@0 572 The "authuser" <access> identifier indicates that use of this URL is
yuuji@0 573 limited to authenticated IMAP sessions that are logged in as any
yuuji@0 574 non-anonymous user (that is, have authorization identity as a non-
yuuji@0 575 anonymous user) of that IMAP server. To restate this: use of this
yuuji@0 576 type of URL is prohibited to anonymous IMAP sessions, i.e., any
yuuji@0 577 URLFETCH command containing this type of URL issued in an anonymous
yuuji@0 578 session MUST return NIL in the URLFETCH response.
yuuji@0 579
yuuji@0 580 The "anonymous" <access> identifier indicates that use of this URL is
yuuji@0 581 not restricted by session authorization identity; that is, any IMAP
yuuji@0 582 session in authenticated or selected state (as defined in [IMAP4]),
yuuji@0 583 including anonymous sessions, may issue a URLFETCH [URLAUTH] using
yuuji@0 584 this URL.
yuuji@0 585
yuuji@0 586 The authorization token is represented as an ASCII-encoded
yuuji@0 587 hexadecimal string, which is used to authorize the URL. The length
yuuji@0 588 and the calculation of the authorization token depend upon the
yuuji@0 589 mechanism used, but in all cases, the authorization token is at least
yuuji@0 590 128 bits (and therefore at least 32 hexadecimal digits).
yuuji@0 591
yuuji@0 592 Example:
yuuji@0 593
yuuji@0 594 <imap://joe@example.com/INBOX/;uid=20/;section=1.2;urlauth=
yuuji@0 595 submit+fred:internal:91354a473744909de610943775f92038>
yuuji@0 596
yuuji@0 597 7. Relative IMAP URLs
yuuji@0 598
yuuji@0 599 Relative IMAP URLs are permitted and are resolved according to the
yuuji@0 600 rules defined in [URI-GEN]. In particular, in IMAP URLs parameters
yuuji@0 601 (such as ";uid=" or ";section=") are treated as part of the normal
yuuji@0 602 path with respect to relative URL resolution.
yuuji@0 603
yuuji@0 604 [URI-GEN] defines four forms of relative URLs: <inetwork-path>,
yuuji@0 605 <iabsolute-path>, <irelative-path>, and <ipath-empty>. Their syntax
yuuji@0 606 is defined in Section 11.
yuuji@0 607
yuuji@0 608 A relative reference that begins with two slash characters is termed
yuuji@0 609 a network-path reference (<inetwork-path>); such references are
yuuji@0 610 rarely used, because in most cases they can be replaced with an
yuuji@0 611 equivalent absolute URL. A relative reference that begins with a
yuuji@0 612 single slash character is termed an absolute-path reference
yuuji@0 613 (<iabsolute-path>; see also Section 7.1). A relative reference that
yuuji@0 614 does not begin with a slash character is termed a relative-path
yuuji@0 615
yuuji@0 616
yuuji@0 617
yuuji@0 618 Melnikov & Newman Standards Track [Page 11]
yuuji@0 619
yuuji@0 620 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 621
yuuji@0 622
yuuji@0 623 reference (<irelative-path>; see also Section 7.2). The final form
yuuji@0 624 is <ipath-empty>, which is "same-document reference" (see Section 4.4
yuuji@0 625 of [URI-GEN]).
yuuji@0 626
yuuji@0 627 The following observations about relative URLs are important:
yuuji@0 628
yuuji@0 629 The <iauth> grammar element (which is a part of <iuserinfo>, which
yuuji@0 630 is, in turn, a part of <iserver>; see Section 3) is considered part
yuuji@0 631 of the user name for purposes of resolving relative IMAP URLs. This
yuuji@0 632 means that unless a new user name/server specification is included in
yuuji@0 633 the relative URL, the authentication mechanism is inherited from the
yuuji@0 634 base IMAP URL.
yuuji@0 635
yuuji@0 636 URLs always use "/" as the hierarchy delimiter for the purpose of
yuuji@0 637 resolving paths in relative URLs. IMAP4 permits the use of any
yuuji@0 638 hierarchy delimiter in mailbox names. For this reason, relative
yuuji@0 639 mailbox paths will only work if the mailbox uses "/" as the hierarchy
yuuji@0 640 delimiter. Relative URLs may be used on mailboxes that use other
yuuji@0 641 delimiters, but in that case, the entire mailbox name MUST be
yuuji@0 642 specified in the relative URL or inherited as a whole from the base
yuuji@0 643 URL.
yuuji@0 644
yuuji@0 645 If an IMAP server allows for mailbox names starting with "./" or
yuuji@0 646 "../", ending with "/." or "/..", or containing sequences "/../" or
yuuji@0 647 "/./", then such mailbox names MUST be percent-encoded as described
yuuji@0 648 in [URI-GEN]. Otherwise, they would be misinterpreted as dot-
yuuji@0 649 segments (see Section 3.3 of [URI-GEN]), which are processed
yuuji@0 650 specially during the relative path resolution process.
yuuji@0 651
yuuji@0 652 7.1. absolute-path References
yuuji@0 653
yuuji@0 654 A relative reference that begins with a single slash character is
yuuji@0 655 termed an absolute-path reference (see Section 4.2 of [URI-GEN]). If
yuuji@0 656 an IMAP server permits mailbox names with a leading "/", then the
yuuji@0 657 leading "/" MUST be percent-encoded as described in [URI-GEN].
yuuji@0 658 Otherwise, the produced absolute-path reference URI will be
yuuji@0 659 misinterpreted as a network-path reference [URI-GEN] described by the
yuuji@0 660 <inetwork-path> non-terminal.
yuuji@0 661
yuuji@0 662 7.2. relative-path References
yuuji@0 663
yuuji@0 664 A relative reference that does not begin with a slash character is
yuuji@0 665 termed a relative-path reference [URI-GEN]. Implementations MUST NOT
yuuji@0 666 generate or accept relative-path IMAP references.
yuuji@0 667
yuuji@0 668 See also Section 4.2 of [URI-GEN] for restrictions on relative-path
yuuji@0 669 references.
yuuji@0 670
yuuji@0 671
yuuji@0 672
yuuji@0 673
yuuji@0 674 Melnikov & Newman Standards Track [Page 12]
yuuji@0 675
yuuji@0 676 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 677
yuuji@0 678
yuuji@0 679 8. Internationalization Considerations
yuuji@0 680
yuuji@0 681 IMAP4, Section 5.1.3 [IMAP4] includes a convention for encoding non-
yuuji@0 682 US-ASCII characters in IMAP mailbox names. Because this convention
yuuji@0 683 is private to IMAP, it is necessary to convert IMAP's encoding to one
yuuji@0 684 that can be more easily interpreted by a URL display program. For
yuuji@0 685 this reason, IMAP's modified UTF-7 encoding for mailboxes MUST be
yuuji@0 686 converted to UTF-8 [UTF-8]. Since 8-bit octets are not permitted in
yuuji@0 687 URLs, the UTF-8 octets are percent-encoded as required by the URL
yuuji@0 688 specification [URI-GEN], Section 2.1. Sample code is included in
yuuji@0 689 Appendix A to demonstrate this conversion.
yuuji@0 690
yuuji@0 691 IMAP user names are UTF-8 strings and MUST be percent-encoded as
yuuji@0 692 required by the URL specification [URI-GEN], Section 2.1.
yuuji@0 693
yuuji@0 694 Also note that IMAP SEARCH criteria can contain non-US-ASCII
yuuji@0 695 characters. 8-bit octets in those strings MUST be percent-encoded as
yuuji@0 696 required by the URL specification [URI-GEN], Section 2.1.
yuuji@0 697
yuuji@0 698 9. Examples
yuuji@0 699
yuuji@0 700 The following examples demonstrate how an IMAP4 client program might
yuuji@0 701 translate various IMAP4 URLs into a series of IMAP4 commands.
yuuji@0 702 Commands sent from the client to the server are prefixed with "C:",
yuuji@0 703 and responses sent from the server to the client are prefixed with
yuuji@0 704 "S:".
yuuji@0 705
yuuji@0 706 The URL:
yuuji@0 707
yuuji@0 708 <imap://minbari.example.org/gray-council;UIDVALIDITY=385759045/;
yuuji@0 709 UID=20/;PARTIAL=0.1024>
yuuji@0 710
yuuji@0 711 may result in the following client commands and server responses:
yuuji@0 712
yuuji@0 713 <connect to minbari.example.org, port 143>
yuuji@0 714 S: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=ANONYMOUS] Welcome
yuuji@0 715 C: A001 AUTHENTICATE ANONYMOUS
yuuji@0 716 S: +
yuuji@0 717 C: c2hlcmlkYW5AYmFieWxvbjUuZXhhbXBsZS5vcmc=
yuuji@0 718 S: A001 OK Welcome sheridan@babylon5.example.org
yuuji@0 719 C: A002 SELECT gray-council
yuuji@0 720 <client verifies the UIDVALIDITY matches>
yuuji@0 721 C: A003 UID FETCH 20 BODY.PEEK[]<0.1024>
yuuji@0 722
yuuji@0 723 The URL:
yuuji@0 724
yuuji@0 725 <imap://psicorp.example.org/~peter/%E6%97%A5%E6%9C%AC%E8%AA%9E/
yuuji@0 726 %E5%8F%B0%E5%8C%97>
yuuji@0 727
yuuji@0 728
yuuji@0 729
yuuji@0 730 Melnikov & Newman Standards Track [Page 13]
yuuji@0 731
yuuji@0 732 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 733
yuuji@0 734
yuuji@0 735 may result in the following client commands:
yuuji@0 736
yuuji@0 737 <connect to psicorp.example.org, port 143>
yuuji@0 738 S: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=CRAM-MD5] Welcome
yuuji@0 739 C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.example.org
yuuji@0 740 C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw-
yuuji@0 741 <commands the client uses for viewing the contents of
yuuji@0 742 the mailbox>
yuuji@0 743
yuuji@0 744 The URL:
yuuji@0 745
yuuji@0 746 <imap://;AUTH=GSSAPI@minbari.example.org/gray-council/;uid=20/
yuuji@0 747 ;section=1.2>
yuuji@0 748
yuuji@0 749 may result in the following client commands:
yuuji@0 750
yuuji@0 751 <connect to minbari.example.org, port 143>
yuuji@0 752 S: * OK Greetings
yuuji@0 753 C: A000 CAPABILITY
yuuji@0 754 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
yuuji@0 755 S: A000 OK
yuuji@0 756 C: A001 AUTHENTICATE GSSAPI
yuuji@0 757 <authentication exchange>
yuuji@0 758 C: A002 SELECT gray-council
yuuji@0 759 C: A003 UID FETCH 20 BODY.PEEK[1.2]
yuuji@0 760
yuuji@0 761 If the following relative URL is located in that body part:
yuuji@0 762
yuuji@0 763 <;section=1.4>
yuuji@0 764
yuuji@0 765 this could result in the following client commands:
yuuji@0 766
yuuji@0 767 C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME]
yuuji@0 768 BODY.PEEK[1.MIME]
yuuji@0 769 BODY.PEEK[HEADER.FIELDS (Content-Location)])
yuuji@0 770 <Client looks for Content-Location headers in
yuuji@0 771 result. If no such headers, then it does the following>
yuuji@0 772 C: A005 UID FETCH 20 BODY.PEEK[1.4]
yuuji@0 773
yuuji@0 774 The URL:
yuuji@0 775
yuuji@0 776 <imap://;AUTH=*@minbari.example.org/gray%20council?
yuuji@0 777 SUBJECT%20shadows>
yuuji@0 778
yuuji@0 779
yuuji@0 780
yuuji@0 781
yuuji@0 782
yuuji@0 783
yuuji@0 784
yuuji@0 785
yuuji@0 786 Melnikov & Newman Standards Track [Page 14]
yuuji@0 787
yuuji@0 788 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 789
yuuji@0 790
yuuji@0 791 could result in the following:
yuuji@0 792
yuuji@0 793 <connect to minbari.example.org, port 143>
yuuji@0 794 S: * OK Welcome
yuuji@0 795 C: A001 CAPABILITY
yuuji@0 796 S: * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5
yuuji@0 797 S: A001 OK
yuuji@0 798 C: A002 AUTHENTICATE DIGEST-MD5
yuuji@0 799 <authentication exchange>
yuuji@0 800 S: A002 OK user lennier authenticated
yuuji@0 801 C: A003 SELECT "gray council"
yuuji@0 802 ...
yuuji@0 803 C: A004 SEARCH SUBJECT shadows
yuuji@0 804 S: * SEARCH 8 10 13 14 15 16
yuuji@0 805 S: A004 OK SEARCH completed
yuuji@0 806 C: A005 FETCH 8,10,13:16 ALL
yuuji@0 807 ...
yuuji@0 808
yuuji@0 809 In the example above, the client has implementation-dependent
yuuji@0 810 choices. The authentication mechanism could be anything, including
yuuji@0 811 PREAUTH. The final FETCH command could fetch more or less
yuuji@0 812 information about the messages, depending on what it wishes to
yuuji@0 813 display to the user.
yuuji@0 814
yuuji@0 815 The URL:
yuuji@0 816
yuuji@0 817 <imap://john;AUTH=*@minbari.example.org/babylon5/personel?
yuuji@0 818 charset%20UTF-8%20SUBJECT%20%7B14+%7D%0D%0A%D0%98%D0%B2%
yuuji@0 819 D0%B0%D0%BD%D0%BE%D0%B2%D0%B0>
yuuji@0 820
yuuji@0 821 shows that 8-bit data can be sent using non-synchronizing literals
yuuji@0 822 [LITERAL+]. This could result in the following:
yuuji@0 823
yuuji@0 824 <connect to minbari.example.org, port 143>
yuuji@0 825 S: * OK Hi there
yuuji@0 826 C: A001 CAPABILITY
yuuji@0 827 S: * CAPABILITY IMAP4rev1 LITERAL+ AUTH=DIGEST-MD5
yuuji@0 828 S: A001 OK
yuuji@0 829 C: A002 AUTHENTICATE DIGEST-MD5
yuuji@0 830 <authentication exchange>
yuuji@0 831 S: A002 OK user john authenticated
yuuji@0 832 C: A003 SELECT babylon5/personel
yuuji@0 833 ...
yuuji@0 834 C: A004 SEARCH CHARSET UTF-8 SUBJECT {14+}
yuuji@0 835 C: XXXXXXXXXXXXXX
yuuji@0 836 S: * SEARCH 7 10 12
yuuji@0 837 S: A004 OK SEARCH completed
yuuji@0 838 C: A005 FETCH 7,10,12 ALL
yuuji@0 839
yuuji@0 840
yuuji@0 841
yuuji@0 842 Melnikov & Newman Standards Track [Page 15]
yuuji@0 843
yuuji@0 844 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 845
yuuji@0 846
yuuji@0 847 ...
yuuji@0 848
yuuji@0 849 where XXXXXXXXXXXXXX is 14 bytes of UTF-8 encoded data as specified
yuuji@0 850 in the URL above.
yuuji@0 851
yuuji@0 852 9.1. Examples of Relative URLs
yuuji@0 853
yuuji@0 854 The following absolute-path reference
yuuji@0 855
yuuji@0 856 </foo/;UID=20/..>
yuuji@0 857
yuuji@0 858 is the same as
yuuji@0 859
yuuji@0 860 </foo>
yuuji@0 861
yuuji@0 862 That is, both of them reference the mailbox "foo" located on the IMAP
yuuji@0 863 server described by the corresponding Base URI.
yuuji@0 864
yuuji@0 865 The following relative-path reference
yuuji@0 866
yuuji@0 867 <;UID=20>
yuuji@0 868
yuuji@0 869 references a message with UID in the mailbox specified by the Base
yuuji@0 870 URI.
yuuji@0 871
yuuji@0 872 The following edge case example demonstrates that the ;UIDVALIDITY=
yuuji@0 873 modifier is a part of the mailbox name as far as relative URI
yuuji@0 874 resolution is concerned:
yuuji@0 875
yuuji@0 876 <..;UIDVALIDITY=385759045/;UID=20>
yuuji@0 877
yuuji@0 878 In this example, ".." is not a dot-segment [URI-GEN].
yuuji@0 879
yuuji@0 880 10. Security Considerations
yuuji@0 881
yuuji@0 882 Security considerations discussed in the IMAP specification [IMAP4]
yuuji@0 883 and the URI specification [URI-GEN] are relevant. Security
yuuji@0 884 considerations related to authenticated URLs are discussed in Section
yuuji@0 885 3.2 of this document.
yuuji@0 886
yuuji@0 887 Many email clients store the plaintext password for later use after
yuuji@0 888 logging into an IMAP server. Such clients MUST NOT use a stored
yuuji@0 889 password in response to an IMAP URL without explicit permission from
yuuji@0 890 the user to supply that password to the specified host name.
yuuji@0 891
yuuji@0 892 Clients resolving IMAP URLs that wish to achieve data confidentiality
yuuji@0 893 and/or integrity SHOULD use the STARTTLS command (if supported by the
yuuji@0 894
yuuji@0 895
yuuji@0 896
yuuji@0 897
yuuji@0 898 Melnikov & Newman Standards Track [Page 16]
yuuji@0 899
yuuji@0 900 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 901
yuuji@0 902
yuuji@0 903 server) before starting authentication, or use a SASL mechanism, such
yuuji@0 904 as GSSAPI, that provides a confidentiality security layer.
yuuji@0 905
yuuji@0 906 10.1. Security Consideration Specific to URLAUTH Authorized URL
yuuji@0 907
yuuji@0 908 The "user+<userid>" <access> identifier limits resolution of that URL
yuuji@0 909 to a particular userid, whereas the "submit+<userid>" <access>
yuuji@0 910 identifier is more general and simply requires that the session be
yuuji@0 911 authorized by a user that has been granted a "submit" role within the
yuuji@0 912 authentication system. Use of either of these mechanisms limits the
yuuji@0 913 scope of the URL. An attacker who cannot authenticate using the
yuuji@0 914 appropriate credentials cannot make use of the URL.
yuuji@0 915
yuuji@0 916 The "authuser" and "anonymous" <access> identifiers do not have this
yuuji@0 917 level of protection. These access identifiers are primarily useful
yuuji@0 918 for public export of data from an IMAP server, without requiring that
yuuji@0 919 it be copied to a web or anonymous FTP server.
yuuji@0 920
yuuji@0 921 The decision to use the "authuser" <access> identifier should be made
yuuji@0 922 with caution. An "authuser" <access> identifier can be used by any
yuuji@0 923 authorized user of the IMAP server; therefore, use of this access
yuuji@0 924 identifier should be limited to content that may be disclosed to any
yuuji@0 925 authorized user of the IMAP server.
yuuji@0 926
yuuji@0 927 The decision to use the "anonymous" <access> identifier should be
yuuji@0 928 made with extreme caution. An "anonymous" <access> identifier can be
yuuji@0 929 used by anyone; therefore, use of this access identifier should be
yuuji@0 930 limited to content that may be disclosed to anyone.
yuuji@0 931
yuuji@0 932 11. ABNF for IMAP URL Scheme
yuuji@0 933
yuuji@0 934 Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
yuuji@0 935 in Section 9 of [IMAP4]. Elements not defined here can be found in
yuuji@0 936 [ABNF], [IMAP4], [IMAPABNF], or [URI-GEN]. Strings are not case
yuuji@0 937 sensitive, and free insertion of linear white space is not permitted.
yuuji@0 938
yuuji@0 939 sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
yuuji@0 940 "*" / "+" / ","
yuuji@0 941 ;; Same as [URI-GEN] sub-delims,
yuuji@0 942 ;; but without ";", "&" and "=".
yuuji@0 943
yuuji@0 944 uchar = unreserved / sub-delims-sh / pct-encoded
yuuji@0 945
yuuji@0 946 achar = uchar / "&" / "="
yuuji@0 947 ;; Same as [URI-GEN] 'unreserved / sub-delims /
yuuji@0 948 ;; pct-encoded', but ";" is disallowed.
yuuji@0 949
yuuji@0 950 bchar = achar / ":" / "@" / "/"
yuuji@0 951
yuuji@0 952
yuuji@0 953
yuuji@0 954 Melnikov & Newman Standards Track [Page 17]
yuuji@0 955
yuuji@0 956 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 957
yuuji@0 958
yuuji@0 959 enc-auth-type = 1*achar
yuuji@0 960 ; %-encoded version of [IMAP4] "auth-type"
yuuji@0 961
yuuji@0 962 enc-mailbox = 1*bchar
yuuji@0 963 ; %-encoded version of [IMAP4] "mailbox"
yuuji@0 964
yuuji@0 965 enc-search = 1*bchar
yuuji@0 966 ; %-encoded version of [IMAPABNF]
yuuji@0 967 ; "search-program". Note that IMAP4
yuuji@0 968 ; literals may not be used in
yuuji@0 969 ; a "search-program", i.e., only
yuuji@0 970 ; quoted or non-synchronizing
yuuji@0 971 ; literals (if the server supports
yuuji@0 972 ; LITERAL+ [LITERAL+]) are allowed.
yuuji@0 973
yuuji@0 974 enc-section = 1*bchar
yuuji@0 975 ; %-encoded version of [IMAP4] "section-spec"
yuuji@0 976
yuuji@0 977 enc-user = 1*achar
yuuji@0 978 ; %-encoded version of [IMAP4] authorization
yuuji@0 979 ; identity or "userid".
yuuji@0 980
yuuji@0 981 imapurl = "imap://" iserver ipath-query
yuuji@0 982 ; Defines an absolute IMAP URL
yuuji@0 983
yuuji@0 984 ipath-query = ["/" [ icommand ]]
yuuji@0 985 ; Corresponds to "path-abempty [ "?" query ]"
yuuji@0 986 ; in [URI-GEN]
yuuji@0 987
yuuji@0 988 Generic syntax for relative URLs is defined in Section 4.2 of
yuuji@0 989 [URI-GEN]. For ease of implementation, the relative IMAP URL syntax
yuuji@0 990 is defined below:
yuuji@0 991
yuuji@0 992 imapurl-rel = inetwork-path
yuuji@0 993
yuuji@0 994 / iabsolute-path
yuuji@0 995 / irelative-path
yuuji@0 996 / ipath-empty
yuuji@0 997
yuuji@0 998 inetwork-path = "//" iserver ipath-query
yuuji@0 999 ; Corresponds to '"//" authority path-abempty
yuuji@0 1000 ; [ "?" query ]' in [URI-GEN]
yuuji@0 1001
yuuji@0 1002 iabsolute-path = "/" [ icommand ]
yuuji@0 1003 ; icommand, if present, MUST NOT start with '/'.
yuuji@0 1004 ;
yuuji@0 1005 ; Corresponds to 'path-absolute [ "?" query ]'
yuuji@0 1006 ; in [URI-GEN]
yuuji@0 1007
yuuji@0 1008
yuuji@0 1009
yuuji@0 1010 Melnikov & Newman Standards Track [Page 18]
yuuji@0 1011
yuuji@0 1012 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1013
yuuji@0 1014
yuuji@0 1015 irelative-path = imessagelist /
yuuji@0 1016 imsg-or-part
yuuji@0 1017 ; Corresponds to 'path-noscheme [ "?" query ]'
yuuji@0 1018 ; in [URI-GEN]
yuuji@0 1019
yuuji@0 1020 imsg-or-part = ( imailbox-ref "/" iuid-only ["/" isection-only]
yuuji@0 1021 ["/" ipartial-only] ) /
yuuji@0 1022 ( iuid-only ["/" isection-only]
yuuji@0 1023 ["/" ipartial-only] ) /
yuuji@0 1024 ( isection-only ["/" ipartial-only] ) /
yuuji@0 1025 ipartial-only
yuuji@0 1026
yuuji@0 1027 ipath-empty = 0<pchar>
yuuji@0 1028 ; Zero characters.
yuuji@0 1029 ; The same-document reference.
yuuji@0 1030
yuuji@0 1031 The following three rules are only used in the presence of the IMAP
yuuji@0 1032 [URLAUTH] extension:
yuuji@0 1033
yuuji@0 1034 authimapurl = "imap://" iserver "/" imessagepart
yuuji@0 1035 ; Same as "imapurl" when "[icommand]" is
yuuji@0 1036 ; "imessagepart"
yuuji@0 1037
yuuji@0 1038 authimapurlfull = authimapurl iurlauth
yuuji@0 1039 ; Same as "imapurl" when "[icommand]" is
yuuji@0 1040 ; "imessagepart iurlauth"
yuuji@0 1041
yuuji@0 1042 authimapurlrump = authimapurl iurlauth-rump
yuuji@0 1043
yuuji@0 1044
yuuji@0 1045 enc-urlauth = 32*HEXDIG
yuuji@0 1046
yuuji@0 1047 iurlauth = iurlauth-rump iua-verifier
yuuji@0 1048
yuuji@0 1049 iua-verifier = ":" uauth-mechanism ":" enc-urlauth
yuuji@0 1050
yuuji@0 1051 iurlauth-rump = [expire] ";URLAUTH=" access
yuuji@0 1052
yuuji@0 1053 access = ("submit+" enc-user) / ("user+" enc-user) /
yuuji@0 1054 "authuser" / "anonymous"
yuuji@0 1055
yuuji@0 1056 expire = ";EXPIRE=" date-time
yuuji@0 1057 ; date-time is defined in [DATETIME]
yuuji@0 1058
yuuji@0 1059 uauth-mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
yuuji@0 1060 ; Case-insensitive.
yuuji@0 1061 ; New mechanisms MUST be registered with IANA.
yuuji@0 1062
yuuji@0 1063
yuuji@0 1064
yuuji@0 1065
yuuji@0 1066 Melnikov & Newman Standards Track [Page 19]
yuuji@0 1067
yuuji@0 1068 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1069
yuuji@0 1070
yuuji@0 1071 iauth = ";AUTH=" ( "*" / enc-auth-type )
yuuji@0 1072
yuuji@0 1073 icommand = imessagelist /
yuuji@0 1074 imessagepart [iurlauth]
yuuji@0 1075
yuuji@0 1076 imailbox-ref = enc-mailbox [uidvalidity]
yuuji@0 1077
yuuji@0 1078 imessagelist = imailbox-ref [ "?" enc-search ]
yuuji@0 1079 ; "enc-search" is [URI-GEN] "query".
yuuji@0 1080
yuuji@0 1081 imessagepart = imailbox-ref iuid [isection] [ipartial]
yuuji@0 1082
yuuji@0 1083 ipartial = "/" ipartial-only
yuuji@0 1084
yuuji@0 1085 ipartial-only = ";PARTIAL=" partial-range
yuuji@0 1086
yuuji@0 1087 isection = "/" isection-only
yuuji@0 1088
yuuji@0 1089 isection-only = ";SECTION=" enc-section
yuuji@0 1090
yuuji@0 1091 iserver = [iuserinfo "@"] host [ ":" port ]
yuuji@0 1092 ; This is the same as "authority" defined
yuuji@0 1093 ; in [URI-GEN]. See [URI-GEN] for "host"
yuuji@0 1094 ; and "port" definitions.
yuuji@0 1095
yuuji@0 1096 iuid = "/" iuid-only
yuuji@0 1097
yuuji@0 1098 iuid-only = ";UID=" nz-number
yuuji@0 1099 ; See [IMAP4] for "nz-number" definition
yuuji@0 1100
yuuji@0 1101 iuserinfo = enc-user [iauth] / [enc-user] iauth
yuuji@0 1102 ; conforms to the generic syntax of
yuuji@0 1103 ; "userinfo" as defined in [URI-GEN].
yuuji@0 1104
yuuji@0 1105 partial-range = number ["." nz-number]
yuuji@0 1106 ; partial FETCH. The first number is
yuuji@0 1107 ; the offset of the first byte,
yuuji@0 1108 ; the second number is the length of
yuuji@0 1109 ; the fragment.
yuuji@0 1110
yuuji@0 1111 uidvalidity = ";UIDVALIDITY=" nz-number
yuuji@0 1112 ; See [IMAP4] for "nz-number" definition
yuuji@0 1113
yuuji@0 1114
yuuji@0 1115
yuuji@0 1116
yuuji@0 1117
yuuji@0 1118
yuuji@0 1119
yuuji@0 1120
yuuji@0 1121
yuuji@0 1122 Melnikov & Newman Standards Track [Page 20]
yuuji@0 1123
yuuji@0 1124 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1125
yuuji@0 1126
yuuji@0 1127 12. IANA Considerations
yuuji@0 1128
yuuji@0 1129 IANA has updated the "imap" definition in the "Uniform Resource
yuuji@0 1130 Identifier scheme registry" to point to this document.
yuuji@0 1131
yuuji@0 1132 The registration template (as per [URI-REG]) is specified in Section
yuuji@0 1133 12.1 of this document.
yuuji@0 1134
yuuji@0 1135 12.1. IANA Registration of imap: URI Scheme
yuuji@0 1136
yuuji@0 1137 This section provides the information required to register the imap:
yuuji@0 1138 URI scheme.
yuuji@0 1139
yuuji@0 1140 URI scheme name: imap
yuuji@0 1141
yuuji@0 1142 Status: permanent
yuuji@0 1143
yuuji@0 1144 URI scheme syntax:
yuuji@0 1145
yuuji@0 1146 See Section 11 of [RFC5092].
yuuji@0 1147
yuuji@0 1148 URI scheme semantics:
yuuji@0 1149
yuuji@0 1150 The imap: URI scheme is used to designate IMAP servers, mailboxes,
yuuji@0 1151 messages, MIME bodies [MIME] and their parts, and search programs
yuuji@0 1152 on Internet hosts accessible using the IMAP protocol.
yuuji@0 1153
yuuji@0 1154 There is no MIME type associated with this URI.
yuuji@0 1155
yuuji@0 1156 Encoding considerations:
yuuji@0 1157
yuuji@0 1158 See Section 8 of [RFC5092].
yuuji@0 1159
yuuji@0 1160 Applications/protocols that use this URI scheme name:
yuuji@0 1161
yuuji@0 1162 The imap: URI is intended to be used by applications that might
yuuji@0 1163 need access to an IMAP mailstore. Such applications may include
yuuji@0 1164 (but are not limited to) IMAP-capable web browsers; IMAP clients
yuuji@0 1165 that wish to access a mailbox, message, or edit a message on the
yuuji@0 1166 server using [CATENATE]; [SUBMIT] clients and servers that are
yuuji@0 1167 requested to assemble a complete message on submission using
yuuji@0 1168 [BURL].
yuuji@0 1169
yuuji@0 1170 Interoperability considerations:
yuuji@0 1171
yuuji@0 1172 A widely deployed IMAP client Netscape Mail (and possibly
yuuji@0 1173 Mozilla/Thunderbird/Seamonkey) uses a different imap: scheme
yuuji@0 1174 internally.
yuuji@0 1175
yuuji@0 1176
yuuji@0 1177
yuuji@0 1178 Melnikov & Newman Standards Track [Page 21]
yuuji@0 1179
yuuji@0 1180 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1181
yuuji@0 1182
yuuji@0 1183 Security considerations:
yuuji@0 1184
yuuji@0 1185 See Security Considerations (Section 10) of [RFC5092].
yuuji@0 1186
yuuji@0 1187 Contact:
yuuji@0 1188
yuuji@0 1189 Alexey Melnikov <alexey.melnikov@isode.com>
yuuji@0 1190
yuuji@0 1191 Author/Change controller:
yuuji@0 1192
yuuji@0 1193 IESG
yuuji@0 1194
yuuji@0 1195 References:
yuuji@0 1196
yuuji@0 1197 [RFC5092] and [IMAP4].
yuuji@0 1198
yuuji@0 1199 13. References
yuuji@0 1200
yuuji@0 1201 13.1. Normative References
yuuji@0 1202
yuuji@0 1203 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
yuuji@0 1204 Requirement Levels", BCP 14, RFC 2119, March 1997.
yuuji@0 1205
yuuji@0 1206 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
yuuji@0 1207 4rev1", RFC 3501, March 2003.
yuuji@0 1208
yuuji@0 1209 [IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to
yuuji@0 1210 IMAP4 ABNF", RFC 4466, April 2006.
yuuji@0 1211
yuuji@0 1212 [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
yuuji@0 1213 Syntax Specifications: ABNF", RFC 4234, October 2005.
yuuji@0 1214
yuuji@0 1215 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
yuuji@0 1216 Extensions (MIME) Part One: Format of Internet Message
yuuji@0 1217 Bodies", RFC 2045, November 1996.
yuuji@0 1218
yuuji@0 1219 [URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
yuuji@0 1220 Resource Identifier (URI): Generic Syntax", STD 66, RFC
yuuji@0 1221 3986, January 2005.
yuuji@0 1222
yuuji@0 1223 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
yuuji@0 1224 10646", STD 63, RFC 3629, November 2003.
yuuji@0 1225
yuuji@0 1226 [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
yuuji@0 1227 May 1998.
yuuji@0 1228
yuuji@0 1229 [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
yuuji@0 1230 January 1997.
yuuji@0 1231
yuuji@0 1232
yuuji@0 1233
yuuji@0 1234 Melnikov & Newman Standards Track [Page 22]
yuuji@0 1235
yuuji@0 1236 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1237
yuuji@0 1238
yuuji@0 1239 [ANONYMOUS] Zeilenga, K., "Anonymous Simple Authentication and
yuuji@0 1240 Security Layer (SASL) Mechanism", RFC 4505, June 2006.
yuuji@0 1241
yuuji@0 1242 [DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet:
yuuji@0 1243 Timestamps", RFC 3339, July 2002.
yuuji@0 1244
yuuji@0 1245 [URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) -
yuuji@0 1246 URLAUTH Extension", RFC 4467, May 2006.
yuuji@0 1247
yuuji@0 1248 13.2. Informative References
yuuji@0 1249
yuuji@0 1250 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for
yuuji@0 1251 Mail", RFC 4409, April 2006.
yuuji@0 1252
yuuji@0 1253 [BURL] Newman, C., "Message Submission BURL Extension", RFC
yuuji@0 1254 4468, May 2006.
yuuji@0 1255
yuuji@0 1256 [CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP)
yuuji@0 1257 CATENATE Extension", RFC 4469, April 2006.
yuuji@0 1258
yuuji@0 1259 [SASL] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
yuuji@0 1260 Authentication and Security Layer (SASL)", RFC 4422,
yuuji@0 1261 June 2006.
yuuji@0 1262
yuuji@0 1263 [GSSAPI] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple
yuuji@0 1264 Authentication and Security Layer (SASL) Mechanism", RFC
yuuji@0 1265 4752, November 2006.
yuuji@0 1266
yuuji@0 1267 [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as
yuuji@0 1268 a SASL Mechanism", RFC 2831, May 2000.
yuuji@0 1269
yuuji@0 1270 [URI-REG] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
yuuji@0 1271 Registration Procedures for New URI Schemes", BCP 115,
yuuji@0 1272 RFC 4395, February 2006.
yuuji@0 1273
yuuji@0 1274
yuuji@0 1275
yuuji@0 1276
yuuji@0 1277
yuuji@0 1278
yuuji@0 1279
yuuji@0 1280
yuuji@0 1281
yuuji@0 1282
yuuji@0 1283
yuuji@0 1284
yuuji@0 1285
yuuji@0 1286
yuuji@0 1287
yuuji@0 1288
yuuji@0 1289
yuuji@0 1290 Melnikov & Newman Standards Track [Page 23]
yuuji@0 1291
yuuji@0 1292 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1293
yuuji@0 1294
yuuji@0 1295 Appendix A. Sample Code
yuuji@0 1296
yuuji@0 1297 Here is sample C source code to convert between URL paths and IMAP
yuuji@0 1298 mailbox names, taking into account mapping between IMAP's modified
yuuji@0 1299 UTF-7 [IMAP4] and hex-encoded UTF-8, which is more appropriate for
yuuji@0 1300 URLs. This code has not been rigorously tested nor does it
yuuji@0 1301 necessarily behave reasonably with invalid input, but it should serve
yuuji@0 1302 as a useful example. This code just converts the mailbox portion of
yuuji@0 1303 the URL and does not deal with parameters, query, or server
yuuji@0 1304 components of the URL.
yuuji@0 1305
yuuji@0 1306 /* Copyright (C) The IETF Trust (2007). This version of
yuuji@0 1307 sample C code is part of RFC XXXX; see the RFC itself
yuuji@0 1308 for full legal notices.
yuuji@0 1309
yuuji@0 1310 Regarding this sample C code (or any portion of it), the authors
yuuji@0 1311 make no guarantees and are not responsible for any damage
yuuji@0 1312 resulting from its use. The authors grant irrevocable permission
yuuji@0 1313 to anyone to use, modify, and distribute it in any way that does
yuuji@0 1314 not diminish the rights of anyone else to use, modify, and
yuuji@0 1315 distribute it, provided that redistributed derivative works do
yuuji@0 1316 not contain misleading author or version information.
yuuji@0 1317
yuuji@0 1318 Derivative works need not be licensed under similar terms.
yuuji@0 1319 */
yuuji@0 1320
yuuji@0 1321 #include <stdio.h>
yuuji@0 1322 #include <string.h>
yuuji@0 1323
yuuji@0 1324 /* hexadecimal lookup table */
yuuji@0 1325 static const char hex[] = "0123456789ABCDEF";
yuuji@0 1326
yuuji@0 1327 #define XX 127
yuuji@0 1328 /*
yuuji@0 1329 * Table for decoding hexadecimal in %encoding
yuuji@0 1330 */
yuuji@0 1331 static const char index_hex[256] = {
yuuji@0 1332 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1333 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1334 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1335 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,XX,XX, XX,XX,XX,XX,
yuuji@0 1336 XX,10,11,12, 13,14,15,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1337 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1338 XX,10,11,12, 13,14,15,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1339 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1340 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1341 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1342 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1343
yuuji@0 1344
yuuji@0 1345
yuuji@0 1346 Melnikov & Newman Standards Track [Page 24]
yuuji@0 1347
yuuji@0 1348 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1349
yuuji@0 1350
yuuji@0 1351 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1352 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1353 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1354 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1355 XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
yuuji@0 1356 };
yuuji@0 1357 #define HEXCHAR(c) (index_hex[(unsigned char)(c)])
yuuji@0 1358
yuuji@0 1359 /* "gen-delims" excluding "/" but including "%" */
yuuji@0 1360 #define GENERAL_DELIMS_NO_SLASH ":?#[]@" "%"
yuuji@0 1361
yuuji@0 1362 /* "gen-delims" (excluding "/", but including "%")
yuuji@0 1363 plus subset of "sub-delims" */
yuuji@0 1364 #define GENERAL_UNSAFE_NO_SLASH GENERAL_DELIMS_NO_SLASH ";&=+"
yuuji@0 1365 #define OTHER_UNSAFE " \"<>\\^`{|}"
yuuji@0 1366
yuuji@0 1367 /* URL unsafe printable characters */
yuuji@0 1368 static const char mailbox_url_unsafe[] = GENERAL_UNSAFE_NO_SLASH
yuuji@0 1369 OTHER_UNSAFE;
yuuji@0 1370
yuuji@0 1371 /* UTF7 modified base64 alphabet */
yuuji@0 1372 static const char base64chars[] =
yuuji@0 1373 "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,";
yuuji@0 1374
yuuji@0 1375 #define UNDEFINED 64
yuuji@0 1376
yuuji@0 1377 /* UTF16 definitions */
yuuji@0 1378 #define UTF16MASK 0x03FFUL
yuuji@0 1379 #define UTF16SHIFT 10
yuuji@0 1380 #define UTF16BASE 0x10000UL
yuuji@0 1381 #define UTF16HIGHSTART 0xD800UL
yuuji@0 1382 #define UTF16HIGHEND 0xDBFFUL
yuuji@0 1383 #define UTF16LOSTART 0xDC00UL
yuuji@0 1384 #define UTF16LOEND 0xDFFFUL
yuuji@0 1385
yuuji@0 1386 /* Convert an IMAP mailbox to a URL path
yuuji@0 1387 * dst needs to have roughly 4 times the storage space of src
yuuji@0 1388 * Hex encoding can triple the size of the input
yuuji@0 1389 * UTF-7 can be slightly denser than UTF-8
yuuji@0 1390 * (worst case: 8 octets UTF-7 becomes 9 octets UTF-8)
yuuji@0 1391 */
yuuji@0 1392 void MailboxToURL(char *dst, char *src)
yuuji@0 1393 {
yuuji@0 1394 unsigned char c, i, bitcount;
yuuji@0 1395 unsigned long ucs4, utf16, bitbuf;
yuuji@0 1396 unsigned char base64[256], utf8[6];
yuuji@0 1397
yuuji@0 1398 /* initialize modified base64 decoding table */
yuuji@0 1399
yuuji@0 1400
yuuji@0 1401
yuuji@0 1402 Melnikov & Newman Standards Track [Page 25]
yuuji@0 1403
yuuji@0 1404 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1405
yuuji@0 1406
yuuji@0 1407 memset(base64, UNDEFINED, sizeof (base64));
yuuji@0 1408 for (i = 0; i < sizeof (base64chars); ++i) {
yuuji@0 1409 base64[(int) base64chars[i]] = i;
yuuji@0 1410 }
yuuji@0 1411
yuuji@0 1412 /* loop until end of string */
yuuji@0 1413 while (*src != '\0') {
yuuji@0 1414 c = *src++;
yuuji@0 1415 /* deal with literal characters and &- */
yuuji@0 1416 if (c != '&' || *src == '-') {
yuuji@0 1417 /* NB: There are no "URL safe" characters after the '~' */
yuuji@0 1418 if (c < ' ' || c > '~' ||
yuuji@0 1419 strchr(mailbox_url_unsafe, c) != NULL) {
yuuji@0 1420 /* hex encode if necessary */
yuuji@0 1421 dst[0] = '%';
yuuji@0 1422 dst[1] = hex[c >> 4];
yuuji@0 1423 dst[2] = hex[c & 0x0f];
yuuji@0 1424 dst += 3;
yuuji@0 1425 } else {
yuuji@0 1426 /* encode literally */
yuuji@0 1427 *dst++ = c;
yuuji@0 1428 }
yuuji@0 1429 /* skip over the '-' if this is an &- sequence */
yuuji@0 1430 if (c == '&') ++src;
yuuji@0 1431
yuuji@0 1432 } else {
yuuji@0 1433 /* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */
yuuji@0 1434 bitbuf = 0;
yuuji@0 1435 bitcount = 0;
yuuji@0 1436 ucs4 = 0;
yuuji@0 1437 while ((c = base64[(unsigned char) *src]) != UNDEFINED) {
yuuji@0 1438 ++src;
yuuji@0 1439 bitbuf = (bitbuf << 6) | c;
yuuji@0 1440 bitcount += 6;
yuuji@0 1441 /* enough bits for a UTF-16 character? */
yuuji@0 1442 if (bitcount >= 16) {
yuuji@0 1443 bitcount -= 16;
yuuji@0 1444 utf16 = (bitcount ? bitbuf >> bitcount
yuuji@0 1445 : bitbuf) & 0xffff;
yuuji@0 1446 /* convert UTF16 to UCS4 */
yuuji@0 1447 if
yuuji@0 1448 (utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) {
yuuji@0 1449 ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT;
yuuji@0 1450 continue;
yuuji@0 1451 } else if
yuuji@0 1452 (utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) {
yuuji@0 1453 ucs4 += utf16 - UTF16LOSTART + UTF16BASE;
yuuji@0 1454 } else {
yuuji@0 1455
yuuji@0 1456
yuuji@0 1457
yuuji@0 1458 Melnikov & Newman Standards Track [Page 26]
yuuji@0 1459
yuuji@0 1460 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1461
yuuji@0 1462
yuuji@0 1463 ucs4 = utf16;
yuuji@0 1464 }
yuuji@0 1465 /* convert UTF-16 range of UCS4 to UTF-8 */
yuuji@0 1466 if (ucs4 <= 0x7fUL) {
yuuji@0 1467 utf8[0] = (unsigned char) ucs4;
yuuji@0 1468 i = 1;
yuuji@0 1469 } else if (ucs4 <= 0x7ffUL) {
yuuji@0 1470 utf8[0] = 0xc0 | (unsigned char) (ucs4 >> 6);
yuuji@0 1471 utf8[1] = 0x80 | (unsigned char) (ucs4 & 0x3f);
yuuji@0 1472 i = 2;
yuuji@0 1473 } else if (ucs4 <= 0xffffUL) {
yuuji@0 1474 utf8[0] = 0xe0 | (unsigned char) (ucs4 >> 12);
yuuji@0 1475 utf8[1] = 0x80 | (unsigned char) ((ucs4 >> 6) & 0x3f);
yuuji@0 1476 utf8[2] = 0x80 | (unsigned char) (ucs4 & 0x3f);
yuuji@0 1477 i = 3;
yuuji@0 1478 } else {
yuuji@0 1479 utf8[0] = 0xf0 | (unsigned char) (ucs4 >> 18);
yuuji@0 1480 utf8[1] = 0x80 | (unsigned char) ((ucs4 >> 12) & 0x3f);
yuuji@0 1481 utf8[2] = 0x80 | (unsigned char) ((ucs4 >> 6) & 0x3f);
yuuji@0 1482 utf8[3] = 0x80 | (unsigned char) (ucs4 & 0x3f);
yuuji@0 1483 i = 4;
yuuji@0 1484 }
yuuji@0 1485 /* convert utf8 to hex */
yuuji@0 1486 for (c = 0; c < i; ++c) {
yuuji@0 1487 dst[0] = '%';
yuuji@0 1488 dst[1] = hex[utf8[c] >> 4];
yuuji@0 1489 dst[2] = hex[utf8[c] & 0x0f];
yuuji@0 1490 dst += 3;
yuuji@0 1491 }
yuuji@0 1492 }
yuuji@0 1493 }
yuuji@0 1494 /* skip over trailing '-' in modified UTF-7 encoding */
yuuji@0 1495 if (*src == '-') ++src;
yuuji@0 1496 }
yuuji@0 1497 }
yuuji@0 1498 /* terminate destination string */
yuuji@0 1499 *dst = '\0';
yuuji@0 1500 }
yuuji@0 1501
yuuji@0 1502 /* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox
yuuji@0 1503 * dst should be about twice the length of src to deal with non-hex
yuuji@0 1504 * coded URLs
yuuji@0 1505 */
yuuji@0 1506 int URLtoMailbox(char *dst, char *src)
yuuji@0 1507 {
yuuji@0 1508 unsigned int utf8pos = 0;
yuuji@0 1509 unsigned int utf8total, i, c, utf7mode, bitstogo, utf16flag;
yuuji@0 1510 unsigned long ucs4 = 0, bitbuf = 0;
yuuji@0 1511
yuuji@0 1512
yuuji@0 1513
yuuji@0 1514 Melnikov & Newman Standards Track [Page 27]
yuuji@0 1515
yuuji@0 1516 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1517
yuuji@0 1518
yuuji@0 1519 utf7mode = 0; /* is the output UTF7 currently in base64 mode? */
yuuji@0 1520 utf8total = 0; /* how many octets is the current input UTF-8 char;
yuuji@0 1521 0 == between characters */
yuuji@0 1522 bitstogo = 0; /* bits that need to be encoded into base64; if
yuuji@0 1523 bitstogo != 0 then utf7mode == 1 */
yuuji@0 1524 while ((c = (unsigned char)*src) != '\0') {
yuuji@0 1525 ++src;
yuuji@0 1526 /* undo hex-encoding */
yuuji@0 1527 if (c == '%' && src[0] != '\0' && src[1] != '\0') {
yuuji@0 1528 c = HEXCHAR(src[0]);
yuuji@0 1529 i = HEXCHAR(src[1]);
yuuji@0 1530 if (c == XX || i == XX) {
yuuji@0 1531 return 0;
yuuji@0 1532 } else {
yuuji@0 1533 c = (char)((c << 4) | i);
yuuji@0 1534 }
yuuji@0 1535 src += 2;
yuuji@0 1536 }
yuuji@0 1537 /* normal character? */
yuuji@0 1538 if (c >= ' ' && c <= '~') {
yuuji@0 1539 /* switch out of UTF-7 mode */
yuuji@0 1540 if (utf7mode) {
yuuji@0 1541 if (bitstogo) {
yuuji@0 1542 *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
yuuji@0 1543 }
yuuji@0 1544 *dst++ = '-';
yuuji@0 1545 utf7mode = 0;
yuuji@0 1546 bitstogo = bitbuf = 0;
yuuji@0 1547 }
yuuji@0 1548 *dst++ = c;
yuuji@0 1549 /* encode '&' as '&-' */
yuuji@0 1550 if (c == '&') {
yuuji@0 1551 *dst++ = '-';
yuuji@0 1552 }
yuuji@0 1553 continue;
yuuji@0 1554 }
yuuji@0 1555 /* switch to UTF-7 mode */
yuuji@0 1556 if (!utf7mode) {
yuuji@0 1557 *dst++ = '&';
yuuji@0 1558 utf7mode = 1;
yuuji@0 1559 }
yuuji@0 1560 /* Encode US-ASCII characters as themselves */
yuuji@0 1561 if (c < 0x80) {
yuuji@0 1562 ucs4 = c;
yuuji@0 1563 utf8total = 1;
yuuji@0 1564 } else if (utf8total) {
yuuji@0 1565 /* this is a subsequent octet of a multi-octet character */
yuuji@0 1566 /* save UTF8 bits into UCS4 */
yuuji@0 1567
yuuji@0 1568
yuuji@0 1569
yuuji@0 1570 Melnikov & Newman Standards Track [Page 28]
yuuji@0 1571
yuuji@0 1572 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1573
yuuji@0 1574
yuuji@0 1575 ucs4 = (ucs4 << 6) | (c & 0x3FUL);
yuuji@0 1576 if (++utf8pos < utf8total) {
yuuji@0 1577 continue;
yuuji@0 1578 }
yuuji@0 1579 } else {
yuuji@0 1580 /* this is the first octet of a multi-octet character */
yuuji@0 1581 utf8pos = 1;
yuuji@0 1582 if (c < 0xE0) {
yuuji@0 1583 utf8total = 2;
yuuji@0 1584 ucs4 = c & 0x1F;
yuuji@0 1585 } else if (c < 0xF0) {
yuuji@0 1586 utf8total = 3;
yuuji@0 1587 ucs4 = c & 0x0F;
yuuji@0 1588 } else {
yuuji@0 1589 /* NOTE: can't convert UTF8 sequences longer than 4 */
yuuji@0 1590 utf8total = 4;
yuuji@0 1591 ucs4 = c & 0x03;
yuuji@0 1592 }
yuuji@0 1593 continue;
yuuji@0 1594 }
yuuji@0 1595 /* Finished with UTF-8 character. Make sure it isn't an
yuuji@0 1596 overlong sequence. If it is, return failure. */
yuuji@0 1597 if ((ucs4 < 0x80 && utf8total > 1) ||
yuuji@0 1598 (ucs4 < 0x0800 && utf8total > 2) ||
yuuji@0 1599 (ucs4 < 0x00010000 && utf8total > 3) ||
yuuji@0 1600 (ucs4 < 0x00200000 && utf8total > 4) ||
yuuji@0 1601 (ucs4 < 0x04000000 && utf8total > 5) ||
yuuji@0 1602 (ucs4 < 0x80000000 && utf8total > 6)) {
yuuji@0 1603 return 0;
yuuji@0 1604 }
yuuji@0 1605 /* loop to split ucs4 into two utf16 chars if necessary */
yuuji@0 1606 utf8total = 0;
yuuji@0 1607 do {
yuuji@0 1608 if (ucs4 >= UTF16BASE) {
yuuji@0 1609 ucs4 -= UTF16BASE;
yuuji@0 1610 bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT)
yuuji@0 1611 + UTF16HIGHSTART);
yuuji@0 1612 ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART;
yuuji@0 1613 utf16flag = 1;
yuuji@0 1614 } else {
yuuji@0 1615 bitbuf = (bitbuf << 16) | ucs4;
yuuji@0 1616 utf16flag = 0;
yuuji@0 1617 }
yuuji@0 1618 bitstogo += 16;
yuuji@0 1619 /* spew out base64 */
yuuji@0 1620 while (bitstogo >= 6) {
yuuji@0 1621 bitstogo -= 6;
yuuji@0 1622 *dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo)
yuuji@0 1623
yuuji@0 1624
yuuji@0 1625
yuuji@0 1626 Melnikov & Newman Standards Track [Page 29]
yuuji@0 1627
yuuji@0 1628 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1629
yuuji@0 1630
yuuji@0 1631 : bitbuf)
yuuji@0 1632 & 0x3F];
yuuji@0 1633 }
yuuji@0 1634 } while (utf16flag);
yuuji@0 1635 }
yuuji@0 1636 /* if in UTF-7 mode, finish in ASCII */
yuuji@0 1637 if (utf7mode) {
yuuji@0 1638 if (bitstogo) {
yuuji@0 1639 *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
yuuji@0 1640 }
yuuji@0 1641 *dst++ = '-';
yuuji@0 1642 }
yuuji@0 1643 /* tie off string */
yuuji@0 1644 *dst = '\0';
yuuji@0 1645 return 1;
yuuji@0 1646 }
yuuji@0 1647
yuuji@0 1648 Appendix B. List of Changes since RFC 2192
yuuji@0 1649
yuuji@0 1650 Updated boilerplate, list of editor's, etc.
yuuji@0 1651 Updated references.
yuuji@0 1652 Updated ABNF not to use _, to use SP instead of SPACE, etc.
yuuji@0 1653 Updated example domains to use example.org.
yuuji@0 1654 Fixed ABNF error in "imessagelist" non-terminal.
yuuji@0 1655 Updated ABNF, due to changes in RFC 3501, RFC 4466, and RFC 3986.
yuuji@0 1656 Renamed "iuserauth" non-terminal to <iuserinfo>.
yuuji@0 1657 Clarified that the userinfo component describes both authorization
yuuji@0 1658 identity and mailbox naming scope.
yuuji@0 1659 Allow for non-synchronizing literals in "enc-search".
yuuji@0 1660 Added "ipartial" specifier that denotes a partial FETCH.
yuuji@0 1661 Moved URLAUTH text from RFC 4467 to this document.
yuuji@0 1662 Updated ABNF for the whole server to allow missing trailing "/"
yuuji@0 1663 (e.g., "imap://imap.example.com" is now valid and is the same as
yuuji@0 1664 "imap://imap.example.com/").
yuuji@0 1665 Clarified how relative-path references are constructed.
yuuji@0 1666 Added more examples demonstrating relative-path references.
yuuji@0 1667 Added rules for relative URLs and restructured ABNF as the result.
yuuji@0 1668 Removed text on use of relative URLs in MHTML.
yuuji@0 1669 Added examples demonstrating security considerations when resolving
yuuji@0 1670 URLs.
yuuji@0 1671 Recommend usage of STARTTLS/SASL security layer to protect
yuuji@0 1672 confidential data.
yuuji@0 1673 Removed some advices about connection reuse that were incorrect.
yuuji@0 1674 Removed URLs referencing a list of mailboxes, as this feature
yuuji@0 1675 hasn't seen any deployments.
yuuji@0 1676 Clarified that user name "anonymous" is case-insensitive.
yuuji@0 1677
yuuji@0 1678
yuuji@0 1679
yuuji@0 1680
yuuji@0 1681
yuuji@0 1682 Melnikov & Newman Standards Track [Page 30]
yuuji@0 1683
yuuji@0 1684 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1685
yuuji@0 1686
yuuji@0 1687 Appendix C. List of Changes since RFC 4467
yuuji@0 1688
yuuji@0 1689 Renamed <mechanism> to <uauth-mechanism>. Restructured ABNF.
yuuji@0 1690
yuuji@0 1691 Appendix D. Acknowledgments
yuuji@0 1692
yuuji@0 1693 Text describing URLAUTH was lifted from [URLAUTH] by Mark Crispin.
yuuji@0 1694
yuuji@0 1695 Stephane H. Maes contributed some ideas to this document; he also
yuuji@0 1696 co-edited early versions of this document.
yuuji@0 1697
yuuji@0 1698 The editors would like to thank Mark Crispin, Ken Murchison, Ted
yuuji@0 1699 Hardie, Zoltan Ordogh, Dave Cridland, Kjetil Torgrim Homme, Lisa
yuuji@0 1700 Dusseault, Spencer Dawkins, Filip Navara, Shawn M. Emery, Sam
yuuji@0 1701 Hartman, Russ Housley, and Lars Eggert for the time they devoted to
yuuji@0 1702 reviewing this document and/or for the comments received.
yuuji@0 1703
yuuji@0 1704 Authors' Addresses
yuuji@0 1705
yuuji@0 1706 Chris Newman (Author/Editor)
yuuji@0 1707 Sun Microsystems
yuuji@0 1708 3401 Centrelake Dr., Suite 410
yuuji@0 1709 Ontario, CA 91761
yuuji@0 1710 EMail: chris.newman@sun.com
yuuji@0 1711
yuuji@0 1712 Alexey Melnikov (Editor)
yuuji@0 1713 Isode Limited
yuuji@0 1714 5 Castle Business Village
yuuji@0 1715 36 Station Road
yuuji@0 1716 Hampton, Middlesex
yuuji@0 1717 TW12 2BX, UK
yuuji@0 1718 EMail: Alexey.Melnikov@isode.com
yuuji@0 1719 URI: http://www.melnikov.ca/
yuuji@0 1720
yuuji@0 1721
yuuji@0 1722
yuuji@0 1723
yuuji@0 1724
yuuji@0 1725
yuuji@0 1726
yuuji@0 1727
yuuji@0 1728
yuuji@0 1729
yuuji@0 1730
yuuji@0 1731
yuuji@0 1732
yuuji@0 1733
yuuji@0 1734
yuuji@0 1735
yuuji@0 1736
yuuji@0 1737
yuuji@0 1738 Melnikov & Newman Standards Track [Page 31]
yuuji@0 1739
yuuji@0 1740 RFC 5092 IMAP URL Scheme November 2007
yuuji@0 1741
yuuji@0 1742
yuuji@0 1743 Full Copyright Statement
yuuji@0 1744
yuuji@0 1745 Copyright (C) The IETF Trust (2007).
yuuji@0 1746
yuuji@0 1747 This document is subject to the rights, licenses and restrictions
yuuji@0 1748 contained in BCP 78, and except as set forth therein, the authors
yuuji@0 1749 retain all their rights.
yuuji@0 1750
yuuji@0 1751 This document and the information contained herein are provided on an
yuuji@0 1752 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
yuuji@0 1753 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
yuuji@0 1754 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
yuuji@0 1755 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
yuuji@0 1756 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
yuuji@0 1757 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0 1758
yuuji@0 1759 Intellectual Property
yuuji@0 1760
yuuji@0 1761 The IETF takes no position regarding the validity or scope of any
yuuji@0 1762 Intellectual Property Rights or other rights that might be claimed to
yuuji@0 1763 pertain to the implementation or use of the technology described in
yuuji@0 1764 this document or the extent to which any license under such rights
yuuji@0 1765 might or might not be available; nor does it represent that it has
yuuji@0 1766 made any independent effort to identify any such rights. Information
yuuji@0 1767 on the procedures with respect to rights in RFC documents can be
yuuji@0 1768 found in BCP 78 and BCP 79.
yuuji@0 1769
yuuji@0 1770 Copies of IPR disclosures made to the IETF Secretariat and any
yuuji@0 1771 assurances of licenses to be made available, or the result of an
yuuji@0 1772 attempt made to obtain a general license or permission for the use of
yuuji@0 1773 such proprietary rights by implementers or users of this
yuuji@0 1774 specification can be obtained from the IETF on-line IPR repository at
yuuji@0 1775 http://www.ietf.org/ipr.
yuuji@0 1776
yuuji@0 1777 The IETF invites any interested party to bring to its attention any
yuuji@0 1778 copyrights, patents or patent applications, or other proprietary
yuuji@0 1779 rights that may cover technology that may be required to implement
yuuji@0 1780 this standard. Please address the information to the IETF at
yuuji@0 1781 ietf-ipr@ietf.org.
yuuji@0 1782
yuuji@0 1783
yuuji@0 1784
yuuji@0 1785
yuuji@0 1786
yuuji@0 1787
yuuji@0 1788
yuuji@0 1789
yuuji@0 1790
yuuji@0 1791
yuuji@0 1792
yuuji@0 1793
yuuji@0 1794 Melnikov & Newman Standards Track [Page 32]
yuuji@0 1795

UW-IMAP'd extensions by yuuji