RFC 4467

Internet Message Access Protocol (IMAP) - URLAUTH Extension 💌

Okay bestie, this is RFC 4467 💖 It was written by M. Crispin from the University of Washington in May 2006 🌸 It's a Standards Track doc, so it's a real protocol spec people actually implement 👑 It updates RFC 3501 (the base IMAP spec) 🎀 The header doesn't list anything it obsoletes.

Status of This Memo ✨

This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For where this protocol stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🦋

Copyright Notice 🌈

Copyright (C) The Internet Society (2006). 💜

Abstract 🍓

Okay so this doc describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192) 🧚 URLAUTH gives an IMAP client a way to use URLs that carry authorization, so it can get at limited message data on the IMAP server 🔥

An IMAP server that supports this extension says so with a capability name of "URLAUTH" 💅

1. Introduction ✨

So in [IMAPURL], a URL like imap://fred@example.com/INBOX/;uid=20 needs authorization as userid "fred" 🌸 The tea is that [IMAPURL] kind of implies it only does authentication, and it mixes up authentication and authorization 🙈

URLAUTH fixes that. It defines an authorization mechanism for IMAP URLs that replaces the authentication-only mechanism in [IMAPURL] ✨ It puts the authorization right in the URL string, and it borrows a piece of the [IMAPURL] authentication syntax to carry the authorization identity. That identity also sets the default namespace in [IMAP] 💖

An authorized user of an IMAP server can use the URLAUTH extension to make URLAUTH-authorized IMAP URLs 🦋 A URLAUTH-authorized URL gives authorization (not authentication) to the data it points at 💜 Another IMAP session can use that URL to grab specific content on the server, and it doesn't hand over authorization to anything else the authorizing user owns, like other stuff in the mailbox named in the URL 🫶

It's giving pawn ticket energy 🎟️ A URLAUTH-authorized URL carries no authentication info, and whoever shows up with it can redeem it. BUT unlike a real pawn ticket, URLAUTH has optional mechanisms to restrict how the URL gets used 👑 With those, a URLAUTH-authorized URL can be usable by:

• anonymous (the "pawn ticket" model)
• authenticated users only
• a specific authenticated user only
• message submission acting on behalf of a specific user only

There's also a mechanism for expiration ⏳

A URLAUTH-authorized URL can go in the argument to the BURL command when you're composing a message, as described in [BURL] 💌 This is super useful for a client with limited memory or other resources. It can submit a message forward or resend one from an IMAP mailbox without having to fetch that message data first 🧚

The URLAUTH is made from an authorization mechanism name and an authorization token. The token is generated using a secret mailbox access key 🔐 An IMAP client can ask the server to generate and assign a new mailbox access key. That effectively revokes all current URLs using URLAUTH with the old key 💀 What it can't do is set the mailbox access key to a key of its own choosing 🙅‍♀️

1.1. Conventions Used in this Document 🎀

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS] 💅

The formal syntax uses the Augmented Backus-Naur Form (ABNF) notation, including the core rules defined in Appendix A of [ABNF] 📝

In examples, "C:" and "S:" show lines sent by the client and the server, respectively 🦋 If one "C:" or "S:" label covers multiple lines, the line breaks between those lines are just for editorial clarity. They're not part of the actual protocol exchange 🫶

2. Concepts 🌸

2.1. URLAUTH 🔗

URLAUTH is a component that gets appended at the end of a URL, and it gives authorization to access the data that URL points at ✨ It has an authorized access identifier, an authorization mechanism name, and an authorization token. The authorization token is generated from the URL, the authorized access identifier, the authorization mechanism name, and a mailbox access key 🔥

2.2. Mailbox Access Key 🔑

The mailbox access key is a random string with at least 128 bits of entropy 🎲 Software generates it (not the human user), and it MUST be unpredictable 💀

Each user has a table of mailboxes, with an associated mailbox access key for each mailbox 💖 So the mailbox access key is per-user and per-mailbox. Two users sharing the same mailbox each have a different mailbox access key for that mailbox 👯‍♀️ And each mailbox a single user accesses also has its own different mailbox access key 🌈

2.3. Authorized Access Identifier 🪪

The authorized access identifier restricts use of the URLAUTH-authorized URL to certain users who are authorized on the server, as described in section 3 🧚

2.4. Authorization Mechanism ⚙️

The authorization mechanism is the algorithm used to generate the URLAUTH and then verify it, using the mailbox access key 🫶

2.4.1. INTERNAL Authorization Mechanism 🕵️‍♀️

This spec defines the INTERNAL mechanism. It uses a token generation algorithm that the server picks, and it doesn't involve disclosing the mailbox access key to the client 🦋

Note: The token generation algorithm the server implementation chooses should be modern and reasonably secure. When this doc was written, an [HMAC] such as HMAC-SHA1 is recommended. 🙈

If the token generation algorithm of the INTERNAL mechanism ever has to change (say, because someone discovered an attack against the current algorithm), then every URLAUTH-authorized URL that already exists gets invalidated by the switch 💀 That's an unpleasant surprise for apps that depend on a URLAUTH-authorized URL staying valid. There's also no good way to bulk update the URLs that are already deployed out there. So it's best to avoid this whole situation by using a secure algorithm, not one that's just "good enough" 😭

Server implementations SHOULD consider the possibility of changing the algorithm 🔄 Sometimes it makes sense to set things up so newly generated tokens use the new algorithm, while for a limited period of time, tokens using either the new or the old algorithm can still be validated 🌉 So the server SHOULD incorporate some means of identifying the token generation algorithm within the token 🏷️

Even though this spec is extensible for other mechanisms, none are defined in this document 🧩 Besides the mechanism name itself, other mechanisms may have mechanism-specific data, which gets interpreted according to the definition of that mechanism ✨

2.5. Authorization Token 🎟️

The authorization token is a deterministic string of at least 128 bits. An entity that knows the secret mailbox access key and the URL authorization mechanism can use it to verify the URL 💜

3. IMAP URL Extensions 🌈

[IMAPURL] gets extended so you can add ;EXPIRE=<datetime> and ;URLAUTH=<access>:<mech>:<token> to IMAP URLs that refer to a specific message or message parts 💅

The URLAUTH is made of ;URLAUTH=<access>:<mech>:<token>, and it MUST be at the end of the URL 🔚

URLAUTH does not apply to, and MUST NOT be used with, any IMAP URL that refers to an entire IMAP server, a list of mailboxes, an entire IMAP mailbox, or IMAP search results 🚫 Not it, bestie 🙅‍♀️

When ;EXPIRE=<datetime> is used, it shows the latest date and time the URL is valid. After that moment, the URL has expired, and server implementations MUST reject the URL ⏳💀 If ;EXPIRE=<datetime> isn't used, the URL has no expiration. It can still be revoked, though, as discussed below 🔁

The URLAUTH takes the form ;URLAUTH=<access>:<mech>:<token>, and it has three parts 🧩 The <access> portion gives the authorized access identifiers, which can limit the operations and users allowed to use this URL 🪪 The <mech> portion names the authorization mechanism the IMAP server uses to generate the authorization token that follows. The <token> portion is the authorization token itself 🔐

The submit+ access identifier prefix, followed by a userid, means only a userid authorized as a message submission entity on behalf of the specified userid can use this URL 📮 The IMAP server doesn't validate the specified userid. It does validate that the IMAP session has an authorization identity that's authorized as a message submission entity. And the authorized message submission entity MUST validate the userid before it contacts the IMAP server 🫶

The user+ access identifier prefix, followed by a userid, means use of this URL is limited to IMAP sessions logged in as that userid (in other words, sessions whose authorization identity is that userid) 👤

Note: If a SASL mechanism that provides both authorization and authentication identifiers is used to authenticate to the IMAP server, the user+ access identifier MUST match the authorization identifier. 🧐

The authuser access identifier means use of this URL is limited to IMAP sessions logged in as an authorized user of that IMAP server (sessions whose authorization identity is an authorized user). Anonymous IMAP sessions are not allowed to use it 🙅‍♀️

The anonymous access identifier means use of this URL isn't restricted by session authorization identity. Any IMAP session in the authenticated or selected state (as defined in [IMAP]), including anonymous sessions, can issue a URLFETCH using this URL 🌍

The authorization token is written as an ASCII-encoded hexadecimal string, and it's what authorizes the URL 🔡 How long it is and how it's calculated depends on the mechanism used. In every case, though, the authorization token is at least 128 bits, which means at least 32 hexadecimal digits 💯

4. Discussion of URLAUTH Authorization Issues ✨

okay so let's talk about the userid before the "@" in an IMAP URL 🎀 In [IMAPURL], that userid has two jobs:

1. It gives context for user-specific mailbox paths like "INBOX".
2. It says that resolving the URL requires logging in as that user, and it limits use of that URL to only that user.

ngl the problem is that when one field does both jobs, only the mailbox owner can ever resolve the URL 🙈

URLAUTH takes over the second job, so by default it lets any user the access identifier permits resolve the URL 💅

The "user+<userid>" access identifier limits resolution to one particular userid 🦋. The "submit+<userid>" access identifier is more general. It just needs the session to be authorized by a user who has been granted a "submit" role within the authentication system 👑. Using either one means an attacker who is spying on the session can't reuse that same URL, whether directly or by submitting it to a message submission entity 🔒.

The "authuser" and "anonymous" access identifiers do not have this level of protection, so they should be used with caution ⚠️ They're mainly useful for public export of data from an IMAP server, without having to copy it to a web or anonymous FTP server. Refer to the Security Considerations for more details 💀

5. Generation of URLAUTH-Authorized URLs 🧚

here's how you make a URLAUTH-authorized URL from an initial URL 🍓

First, build an initial URL that ends with ;URLAUTH=<access> but doesn't include the :<mech>:<token> components. Then select an authorization mechanism and use it to calculate the authorization token, with the initial URL as the data and a secret known to the IMAP server as the key. To generate the URLAUTH-authorized URL, take the initial URL and append ":", the URL authorization mechanism name, ":", and the ASCII-encoded hexadecimal representation of the authorization token.

Note: ASCII-encoded hexadecimal is used instead of BASE64 because a BASE64 representation may have "=" padding characters, which would be problematic in a URL.

For the INTERNAL mechanism, the mailbox access key for that mailbox is the secret known to the IMAP server, and a server-selected algorithm is used as described in section 2.4.1.

6. Validation of URLAUTH-authorized URLs 🔍

here's the validation flow, step by step 🫶

The URL is split at the ":" that separates "<access>" from "<mech>:<token>" in the ;URLAUTH=<access>:<mech>:<token> portion of the URL. The "<mech>:<token>" portion is parsed first and saved as the authorization mechanism and the authorization token. Then the URL is truncated, discarding the ":" described above, to create a "rump URL" (the URL minus the ":" and the "<mech>:<token>" portion). The rump URL is then analyzed to identify the mailbox.

If the mailbox can't be identified, an authorization token is calculated on the rump URL, using random "plausible" keys (selected by the server) as needed, before a validation failure is returned. This prevents timing attacks aimed at identifying mailbox names ⏱️

If the mailbox can be identified, the authorization token is calculated on the rump URL and a secret known to the IMAP server, using the given URL authorization mechanism. Validation is successful if, and only if, the calculated authorization token for that mechanism matches the authorization token supplied in ;URLAUTH=<access>:<mech>:<token>.

Removal of the ":<mech>:<token>" portion of the URL MUST be the only operation applied to the URLAUTH-authorized URL to get the rump URL. In particular, URL percent escape decoding and case-folding (including to the domain part of the URL) MUST NOT occur. 🚫

For the INTERNAL mechanism, the mailbox access key for that mailbox is used as the secret known to the IMAP server, and the same server-selected algorithm used for generating URLs is used to calculate the authorization token for verification.

7. Additional Commands 🎀

these commands are extensions to the [IMAP] base protocol 🧁 The section headings below are meant to match where they'd live in the base protocol document if they were part of it.

BASE.6.3.RESETKEY. RESETKEY Command 🔑

Arguments:  optional mailbox name
            optional mechanism name(s)

Responses:  none other than in result

Result:     OK - RESETKEY completed, URLMECH containing new data
            NO - RESETKEY error: can't change key of that mailbox
            BAD - command unknown or arguments invalid

the RESETKEY command has two forms ✨

The first form takes a mailbox name and generates a new mailbox access key for that mailbox in the user's mailbox access key table. It replaces any previous mailbox access key in that table, and that also revokes any URLs that were authorized with a URLAUTH using the old key 💔 By default, the new key is generated for the INTERNAL mechanism, but other mechanisms can be picked with the optional mechanism argument.

The second form has no arguments. It removes all mailbox access keys in the user's mailbox access key table, which revokes every URL the user has currently authorized using URLAUTH 🙈

Any current IMAP session logged in as the user that has the mailbox selected will get an untagged OK response with the URLMECH status response code. (See section BASE.7.1.URLMECH for more details about the URLMECH status response code.) 📣

Example:

C: a31 RESETKEY
S: a31 OK All keys removed
C: a32 RESETKEY INBOX
S: a32 OK [URLMECH INTERNAL] mechs
C: a33 RESETKEY INBOX XSAMPLE
S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done

BASE.6.3.GENURLAUTH. GENURLAUTH Command 🦋

Argument:   one or more URL/mechanism pairs

Response:   untagged response: GENURLAUTH

Result:     OK - GENURLAUTH completed
            NO - GENURLAUTH error: can't generate a URLAUTH
            BAD - command unknown or arguments invalid

the GENURLAUTH command asks the server to generate a URLAUTH-authorized URL for each of the given URLs, using the given URL authorization mechanism 💫

The server MUST validate each supplied URL as follows:

1. The mailbox component of the URL MUST refer to an existing mailbox.
2. The server component of the URL MUST contain a valid userid that identifies the owner of the mailbox access key table that will be used to generate the URLAUTH-authorized URL. Because of this, the iserver rule of [IMAPURL] is modified so that iuserauth is mandatory.
3. There is a valid access identifier that, in the case of "submit+" and "user+", will contain a valid userid. This userid is not necessarily the same as the owner userid described in (2).
4. The server MAY also verify that the iuid and/or isection components (if present) are valid.

Note: the server component of the URL is generally the logged in userid and server. If not, then the logged in userid and server MUST have owner-type access to the mailbox access key table owned by the userid and server indicated by the server component of the URL.

If any of the above checks fail, the server MUST return a tagged BAD response, with the following exception. If an invalid userid is supplied as the mailbox access key owner and/or as part of the access identifier, the server MAY issue a tagged OK response with a generated mailbox key that always fails validation when used with a URLFETCH command. This exception stops an attacker from validating userids 🕵️‍♀️

If there is currently no mailbox access key for the given mailbox in the owner's mailbox access key table, one is generated automatically. In other words, you don't need to use RESETKEY before first-time use of GENURLAUTH 🎉

If the command succeeds, a GENURLAUTH response code is returned listing the requested URLs as URLAUTH-authorized URLs.

Examples:

C: a775 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
   ;section=1.2" INTERNAL
S: a775 BAD missing access identifier in supplied URL
C: a776 GENURLAUTH "imap://example.com/Shared/;uid=20/
   ;section=1.2;urlauth=submit+fred" INTERNAL
S: a776 BAD missing owner username in supplied URL
C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
   ;section=1.2;urlauth=submit+fred" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
   ;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
S: a777 OK GENURLAUTH completed

BASE.6.3.URLFETCH. URLFETCH Command 🍓

Argument:   one or more URLs

Response:   untagged response: URLFETCH

Result:     OK - urlfetch completed
            NO - urlfetch failed due to server internal error
            BAD - command unknown or arguments invalid

the URLFETCH command asks the server to return the text data associated with the specified IMAP URLs, as described in [IMAPURL] and extended by this document 📥 The data is returned for all validated URLs, regardless of whether or not the session would otherwise be able to access the mailbox containing that data via SELECT or EXAMINE.

Note: This command does not require that the URL refer to the selected mailbox, and it does not require that any mailbox be selected. It also does not in any way interfere with any selected mailbox.

the URLFETCH command effectively runs with the access of the userid in the server component of the URL (which is generally the userid that issued the GENURLAUTH). By itself, the URLAUTH does NOT grant access to the data. Once validated, it grants whatever access to the data the userid in the server component of the URL holds. That access may have changed since the GENURLAUTH was done 🤷‍♀️

The URLFETCH command MUST return an untagged URLFETCH response and a tagged OK response to any URLFETCH command that is syntactically valid. A NO response indicates a server internal failure that may be resolved on a later retry.

Note: The possibility of a NO response is there to accommodate implementations that would otherwise have to issue an untagged BYE with a fatal error because they can't respond to a valid request. In an ideal world, a server SHOULD NOT issue a NO response.

The server MUST return NIL for any IMAP URL that references an entire IMAP server, a list of mailboxes, an entire IMAP mailbox, or IMAP search results.

Example:

Note: For clarity, this example uses the LOGIN command, which SHOULD NOT be used over a non-encrypted communication path.

this example shows a submit server obtaining a message segment for a message it has already validated was submitted by "fred" 💌

S: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP server
C: a001 LOGIN submitserver secret
S: a001 OK submitserver logged in
C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
   ;section=1.2;urlauth=submit+fred:internal
   :91354a473744909de610943775f92038"
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
   ;urlauth=submit+fred:internal
   :91354a473744909de610943775f92038" {28}
S: Si vis pacem, para bellum.
S:
S: a002 OK URLFETCH completed

8. Additional Responses 💖

okay so these responses are extensions to the [IMAP] base protocol 🦋 The section headings are named so they line up with where they'd sit if they were part of the base protocol document 🧚

BASE.7.1.URLMECH. URLMECH Status Response Code

okay so the URLMECH status response code is followed by a list of URL authorization mechanism names 📋 Mechanism names other than INTERNAL may be appended with an "=" and a BASE64-encoded form of mechanism-specific data 🔐

this status response code gets returned in an untagged OK response to a RESETKEY, SELECT, or EXAMINE command ✨ for RESETKEY specifically, it can ride along in the tagged OK response instead, so you don't need a separate untagged OK response 💅

Example:

C: a33 RESETKEY INBOX XSAMPLE
S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done

in this example, the server supports the INTERNAL mechanism and an experimental mechanism called XSAMPLE 🧪 XSAMPLE also has some mechanism-specific data attached (the name "XSAMPLE" is just for illustrative purposes, bestie 🌸)

BASE.7.4.GENURLAUTH. GENURLAUTH Response

Contents: One or more URLs 🎀

the GENURLAUTH response hands back the URLAUTH-authorized URL(s) that a GENURLAUTH command asked for 💜

Example:

C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
   ;section=1.2;urlauth=submit+fred" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
   ;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
S: a777 OK GENURLAUTH completed

BASE.7.4.URLFETCH. URLFETCH Response

Contents: One or more URL/nstring pairs 🍓

the URLFETCH response returns the message text data for one or more IMAP URLs, as described in [IMAPURL] and extended by this document 📨 it shows up as the result of a URLFETCH command 🧚

the returned data string is NIL if the URL is invalid for any reason, validation failure included 🙈 if the URL is valid but the IMAP fetch of the body part came back NIL (this should not happen), the returned data string should be the empty string ("") and not NIL 💀

Note: This command does not require that the URL refer to the selected mailbox; nor does it require that any mailbox be selected. It also does not in any way interfere with any selected mailbox.

Example:

C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
   ;section=1.2;urlauth=submit+fred:internal
   :91354a473744909de610943775f92038"
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
   ;urlauth=submit+fred:internal
   :91354a473744909de610943775f92038" {28}
S: Si vis pacem, para bellum.
S:
S: a002 OK URLFETCH completed

---

9. Formal Syntax 🧩

okay the syntax here is written in Augmented Backus-Naur Form (ABNF) notation, as specified in [ABNF] 🤓

these are the modifications made to the Formal Syntax in [IMAP]:

resetkey        = "RESETKEY" [SP mailbox *(SP mechanism)]

capability      =/ "URLAUTH"

command-auth    =/ resetkey / genurlauth / urlfetch

resp-text-code  =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64])

genurlauth      = "GENURLAUTH" 1*(SP url-rump SP mechanism)

genurlauth-data = "*" SP "GENURLAUTH" 1*(SP url-full)
url-full        = astring
                     ; contains authimapurlfull as defined below

url-rump        = astring
                     ; contains authimapurlrump as defined below

urlfetch        = "URLFETCH" 1*(SP url-full)

urlfetch-data   = "*" SP "URLFETCH" 1*(SP url-full SP nstring)

and these are the extensions made to the Formal Syntax in [IMAPURL] 🎀

authimapurl     = "imap://" enc-user [iauth] "@" hostport "/"
                     imessagepart
                     ; replaces "imapurl" and "iserver" rules for
                     ; URLAUTH authorized URLs

authimapurlfull = authimapurl iurlauth

authimapurlrump = authimapurl iurlauth-rump

enc-urlauth     = 32*HEXDIG

enc-user        = 1*achar
                     ; same as "enc_user" in RFC 2192

iurlauth        = iurlauth-rump ":" mechanism ":" enc-urlauth

iurlauth-rump   = [expire] ";URLAUTH=" access

access          = ("submit+" enc-user) / ("user+" enc-user) /
                    "authuser" / "anonymous"

expire          = ";EXPIRE=" date-time
                      ; date-time defined in [DATETIME]

mechanism       = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
                     ; case-insensitive
                     ; new mechanisms MUST be registered with IANA

---

10. Security Considerations 🔐

okay this part is SERIOUS bestie 😭 security is discussed throughout this memo, so keep your eyes open 👀

the mailbox access key SHOULD have at least 128 bits of entropy (see [RANDOM] for the deets) and it MUST be unpredictable 🔑 no guessable keys, no cap

the server implementation of the INTERNAL mechanism SHOULD consider that it might need to change the token generation algorithm 🔄 it SHOULD also incorporate some way of identifying the token generation algorithm within the token, so future-you isn't lost 🧭

heads up: the URLMECH status response code may expose sensitive data in the mechanism-specific data for mechanisms other than INTERNAL 🚨 a server implementation MUST implement a configuration that will not return a URLMECH status response code unless some mechanism is provided that protects the session from snooping, such as a TLS or SASL security layer that provides confidentiality protection 🛡️ no leaking secrets in the open, periodt 💀

the calculation of an authorization token with a "plausible" key if the mailbox can not be identified is necessary to avoid attacks in which the server is probed to see if a particular mailbox exists on the server, by measuring the amount of time taken to reject a known bad name versus some other name ⏱️ sneaky attackers gonna be sneaky, so the timing has to look the same 🕵️

to protect against a computational denial-of-service attack, a server MAY impose progressively longer delays on multiple URL requests that fail validation 🐢 slow down, hacker 🙅

the decision to use the "authuser" access identifier should be made with caution ⚠️ an "authuser" access identifier can be used by any authorized user of the IMAP server, so this should be limited to content that may be disclosed to any authorized user of the IMAP server 👥

the decision to use the "anonymous" access identifier should be made with extreme caution 😱 an "anonymous" access identifier can be used by anyone, so this should be limited to content that may be disclosed to anyone 🌍 many IMAP servers do not permit anonymous access; in that case, the "anonymous" access identifier is equivalent to "authuser", but this MUST NOT be relied upon 🚫

although this specification does not prohibit the theoretical capability to generate a URL with a server component other than the logged in userid and server, this capability should only be provided when the logged in userid/server has been authorized as equivalent to the server component userid/server, or otherwise has access to that userid/server mailbox access key table 🗝️ it's giving "only the right people get the keys" energy 👑

---

11. IANA Considerations 🌸

this document registers the URLAUTH capability in the imap4-capabilities registry 🎀

URLAUTH authorization mechanisms get registered by publishing a standards track or IESG-approved experimental RFC 📜 the registry currently lives at http://www.iana.org/assignments/urlauth-authorization-mechanism-registry 🔗

this registry is case-insensitive 🔤

this document also registers the INTERNAL URLAUTH authorization mechanism ✨ here's the registry entry:

IMAP URLAUTH Authorization Mechanism Registry

   Mechanism Name           Reference
   --------------           ---------
   INTERNAL                 [RFC4467]

---

12. Normative References 📚

• [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
• [BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
• [DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
• [IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
• [IMAPURL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
• [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

13. Informative References 📖

• [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
• [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.

Author's Address 🎀

Mark R. Crispin
Networks and Distributed Computing
University of Washington
4545 15th Avenue NE
Seattle, WA  98105-4527

Phone: (206) 543-5762
EMail: MRC@CAC.Washington.EDU

Full Copyright Statement ©️

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🫶

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 💜