IMAP URL Scheme
obsoletes
- rfc-2192 — IMAP URL Scheme
updated by
- rfc-5593 — Internet Message Access Protocol (IMAP) - URL Access Identifier Extension
updates
- rfc-4467 — Internet Message Access Protocol (IMAP) - URLAUTH Extension
Extracted elements (30)
The enc-user field serves two purposes: providing context for user-specific mailbox paths like INBOX, and restricting URL resolution to the named user. An obvious limitation is that the URL can only be resolved by the mailbox owner. The URLAUTH component overrides the second purpose and permits any user allowed by the <access> identifier to resolve the URL.
The <iauth> grammar element is considered part of the user name for relative URL resolution purposes, meaning the authentication mechanism is inherited from the base IMAP URL unless a new user name/server specification is included in the relative URL.
A widely deployed IMAP client, Netscape Mail (and possibly Mozilla/Thunderbird/SeaMonkey), uses a different imap: URI scheme internally, which may cause interoperability issues.
IMAP URLs always use '/' as the hierarchy delimiter for relative URL resolution. Because IMAP4 permits any hierarchy delimiter in mailbox names, relative mailbox paths will only work if the mailbox uses '/' as the delimiter. For other delimiters, the entire mailbox name MUST be specified or inherited as a whole.
Synchronizing literals are not allowed in enc-search content; only quoted strings and non-synchronizing literals (LITERAL+, if the server supports it) are permitted, because synchronizing literals would require the URL-interpreting agent to handle command continuation request handling.
A URLFETCH command containing an 'authuser' type URLAUTH URL issued in an anonymous IMAP session MUST return NIL in the URLFETCH response.
As described in RFC 3501, the LOGIN command MUST NOT be used when the IMAP server advertises the LOGINDISABLED capability.
If an IMAP server allows mailbox names starting with './' or '../', ending with '/.' or '/..' , or containing '/../' or '/./', then such mailbox names MUST be percent-encoded to avoid misinterpretation as dot-segments during relative path resolution.
If no user name and no authentication mechanism are supplied in the IMAP URL, the client MUST authenticate as anonymous. If the server advertises AUTH=ANONYMOUS, the client MUST use AUTHENTICATE with the ANONYMOUS SASL mechanism; otherwise, the user name 'anonymous' is used with LOGIN.
If <uidvalidity> is present in a mailbox or message URL, it MUST be the same as the IMAP4 UIDVALIDITY response code at the time the URL was created, and MUST be used by the interpreting program to detect stale URLs. A stale URL should be treated as if the mailbox does not exist.
IMAP's modified UTF-7 encoding for mailbox names MUST be converted to UTF-8. Since 8-bit octets are not permitted in URLs, the UTF-8 octets are then percent-encoded. IMAP user names (UTF-8 strings) and 8-bit octets in SEARCH criteria MUST also be percent-encoded.
Implementations MUST NOT generate or accept relative-path IMAP URL references (those that do not begin with a slash character). Only network-path, absolute-path, and empty-path relative references are permitted.
The string ';AUTH=*' indicates the client SHOULD select an appropriate authentication mechanism. The '*' character MUST NOT be percent-encoded in this usage, as ';AUTH=%2A' will not match this production.
Unsafe or reserved characters (such as space, ';', '?') present in <enc-mailbox> or <enc-search> MUST be percent-encoded as described in RFC 3986. Synchronizing literals are not allowed in enc-search content.
When an authentication mechanism is indicated via ';AUTH=<enc-auth-type>', the client SHOULD request appropriate credentials from that mechanism and use AUTHENTICATE instead of LOGIN. If no user name is specified, one MUST be obtained from the mechanism or requested from the user.
When ';EXPIRE=<datetime>' is present, server implementations MUST reject the URL after that date and time. The URLAUTH component MUST be at the end of the URL.
An absolute IMAP URL takes one of three forms: a server reference (imap://<iserver>[/]), a mailbox/search reference (imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]), or a specific message/part reference (imap://<iserver>/<enc-mailbox>[<uidvalidity>]<iuid>[<isection>][<ipartial>][<iurlauth>]). The default port is 143.
The <iuserinfo> component has the syntax 'enc-user [iauth] / [enc-user] iauth'. The enc-user field serves a dual purpose: it denotes the mailbox naming scope and specifies the authorization identity required to resolve the URL.
The mailbox access key is a per-user, per-mailbox unpredictable random string with at least 128 bits of entropy, generated by software or hardware. Two users sharing the same mailbox each have a different mailbox access key for that mailbox.
The URLAUTH component appended to a message URL conveys authorization to access the addressed data. It contains an authorized access identifier (<access>), an authorization mechanism name (<mech>), and an authorization token (<token>) of at least 128 bits, represented as at least 32 hex digits.
URLAUTH access identifiers: 'submit+<userid>' restricts use to an authorized message submission entity acting on behalf of that userid; 'user+<userid>' restricts to IMAP sessions logged in as that userid; 'authuser' restricts to any authenticated non-anonymous user; 'anonymous' permits any session including anonymous.
IANA has updated the 'imap' entry in the Uniform Resource Identifier scheme registry to point to RFC 5092. The imap: URI scheme is registered as permanent, with syntax defined in Section 11 and encoding considerations in Section 8.
New URLAUTH authorization mechanisms (uauth-mechanism values beyond 'INTERNAL') MUST be registered with IANA. The mechanism name syntax is 1*(ALPHA / DIGIT / '-' / '.').
Clients resolving IMAP URLs that require authentication must meet at least one of five criteria: the URL comes from a trusted/validated source; explicit site policy permits the connection; the user confirms supplying credentials to that domain; a mechanism validates the server before sending credentials (e.g., TLS with a site certificate, DIGEST-MD5); or a mechanism that reveals nothing reusable is used (e.g., ANONYMOUS, GSSAPI).
Clients resolving IMAP URLs that wish to achieve data confidentiality and/or integrity SHOULD use STARTTLS (if supported) before authentication, or use a SASL mechanism such as GSSAPI that provides a confidentiality security layer.
Email clients that store plaintext passwords MUST NOT use a stored password in response to an IMAP URL without explicit permission from the user to supply that password to the specified host name.
The 'authuser' and 'anonymous' URLAUTH access identifiers provide weaker protection than 'user+' or 'submit+'. The 'authuser' identifier should be limited to content that may be disclosed to any authorized user; 'anonymous' should be used with extreme caution and only for content that may be disclosed to anyone.
The iuserinfo ABNF is: enc-user [iauth] / [enc-user] iauth. The iauth field is ';AUTH=' ( '*' / enc-auth-type ). The uauth-mechanism is 'INTERNAL' / 1*(ALPHA / DIGIT / '-' / '.') and is case-insensitive.
The uidvalidity field has the syntax ';UIDVALIDITY=' nz-number. The iuid field has the syntax '/' ';UID=' nz-number. The partial-range field has the syntax number ['.' nz-number], where the first number is the byte offset and the second is the fragment length.
The URLAUTH wire component has the form ';URLAUTH=<access>:<mech>:<token>' where enc-urlauth is encoded as 32*HEXDIG (minimum 128 bits). The iurlauth-rump consists of an optional ';EXPIRE=<date-time>' followed by ';URLAUTH=<access>'.