RFC 3656

The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol

📅 published December 2003, from ietf

RFC 3656: The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol 🎀

  • Network Working Group, written by R. Siemborski of Carnegie Mellon University 🎓
  • Category: Experimental 🧪
  • Date: December 2003 📅
  • Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🌸

Status of this Memo ✨

okay so this memo is an Experimental Protocol for the Internet community 🧪. it is NOT an Internet standard of any kind, so don't treat it like one. the authors actually want feedback and suggestions for improvement, so bring your thoughts 💬. distribution of this memo is unlimited, so share it with your friends 💖

Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒

Abstract 🦋

okay so picture this: as mail delivery needs get bigger, one single machine just isn't going to cut it anymore 😭. it's not just about capacity limits either. if that one machine dies, EVERYONE loses mail delivery 💀. so it's way better to let lots of machines share the job of delivering mail 🫶

the Mailbox Update (MUPDATE) protocol lets a group of Internet Message Access Protocol (IMAP) or Post Office Protocol - Version 3 (POP3) servers act like they have one unified mailbox namespace ✨. this document is meant to be the reference guide for that protocol 📖

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   3
    2.1.  Atoms . . . . . . . . . . . . . . . . . . . . . . . . .   4
    2.2.  Strings . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Server Responses  . . . . . . . . . . . . . . . . . . . . . .   4
    3.1.  Response: OK  . . . . . . . . . . . . . . . . . . . . .   5
    3.2.  Response: NO  . . . . . . . . . . . . . . . . . . . . .   5
    3.3.  Response: BAD . . . . . . . . . . . . . . . . . . . . .   5
    3.4.  Response: BYE . . . . . . . . . . . . . . . . . . . . .   6
    3.5.  Response: RESERVE . . . . . . . . . . . . . . . . . . .   6
    3.6.  Response: MAILBOX . . . . . . . . . . . . . . . . . . .   6
    3.7.  Response: DELETE  . . . . . . . . . . . . . . . . . . .   7
    3.8.  Server Capability Response. . . . . . . . . . . . . . .   7
4.  Client Commands . . . . . . . . . . . . . . . . . . . . . . .   8
    4.1.  Command: ACTIVATE . . . . . . . . . . . . . . . . . . .   8
    4.2.  Command: AUTHENTICATE . . . . . . . . . . . . . . . . .   8
    4.3.  Command: DEACTIVATE . . . . . . . . . . . . . . . . . .   9
    4.4.  Command: DELETE . . . . . . . . . . . . . . . . . . . .   9
    4.5.  Command: FIND . . . . . . . . . . . . . . . . . . . . .   9
    4.6.  Command: LIST . . . . . . . . . . . . . . . . . . . . .  10
    4.7.  Command: LOGOUT . . . . . . . . . . . . . . . . . . . .  10
    4.8.  Command: NOOP . . . . . . . . . . . . . . . . . . . . .  10
    4.9.  Command: RESERVE. . . . . . . . . . . . . . . . . . . .  10
    4.10. Command: STARTTLS . . . . . . . . . . . . . . . . . . .  11
    4.11. Command: UPDATE . . . . . . . . . . . . . . . . . . . .  12
5.  MUPDATE Formal Syntax . . . . . . . . . . . . . . . . . . . .  12
6.  MUPDATE URL Scheme. . . . . . . . . . . . . . . . . . . . . .  14
    6.1.  MUPDATE URL Scheme Registration Form. . . . . . . . . .  14
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
9.  Intellectual Property Rights. . . . . . . . . . . . . . . . .  16
10. References. . . . . . . . . . . . . . . . . . . . . . . . . .  17
    10.1. Normative References. . . . . . . . . . . . . . . . . .  17
    10.2. Informative References. . . . . . . . . . . . . . . . .  17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
12. Author's Address. . . . . . . . . . . . . . . . . . . . . . .  18
13. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  19

1. Introduction 🌈

okay so the whole point is supporting a setup where several [IMAP, POP3] servers share one mailbox database 🫶. for that to work, you need atomic mailbox operations, plus enough guarantees that the database stays consistent 💅

the main goal of MUPDATE is to be simple to implement while still keeping the database consistent across everyone involved 🔥

the key words "MUST, "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as defined in BCP 14, RFC 2119 [KEYWORDS] 📚. these are the official requirement words, so pay attention to them!

in examples, "C:" means lines sent by the client and "S:" means lines sent by the server 💬

2. Protocol Overview 🎀

MUPDATE assumes a reliable data stream, like a TCP network connection 🛜. IANA registered port 3905 with the short name "mupdate" for this exact purpose 🔢

in the current implementation there are three kinds of participants: one master server, slave (or replica) servers, and clients 👑. the master keeps the authoritative copy of the mailbox database. slaves connect to the master as clients, and from the end clients' point of view they act as replicas 🪞. end clients can connect to the master or to any slave and search the database, but anything that changes the database can only be done on the master 🔒. for protocol discussion purposes, a slave's connection to the master is treated the same as any other client's connection ✨

after connecting, every command from a client to a server has to carry a unique tag, which is an alphanumeric string 🏷️. commands MAY be pipelined, meaning the client doesn't have to wait for a response before sending the next command 🚀. however, the server MUST execute the commands in the order it received them 📋

if the server supports an inactivity login timeout, that timeout MUST be at least 15 minutes ⏰

MUPDATE uses data formats similar to the ones in [ACAP] 💖. that means atoms and strings. all commands and tags are sent as atoms, and all other data counts as a string, which has to be quoted or sent as a literal 🎀

outside of a literal, both clients and servers MUST support line lengths of at least 1024 octets (including the trailing CR and LF characters) 📏. if a longer line has to be sent, implementations MUST use literals to do it 🧩

2.1. Atoms 🍓

an atom is one or more alphanumeric characters. atoms MUST be less than 15 octets in length 🔤

2.2. Strings 🫧

like in [ACAP], a string can be either a literal or a quoted string 💜.

a literal is zero or more octets (CR and LF included) with a prefix that gives the octet count. the prefix looks like this: an open brace ({), the number of octets, an optional plus sign (+) meaning the data follows right away (a non-synchronized literal), a close brace (}), and then a CRLF sequence 🧵. if the plus sign is left out (a synchronized literal), the receiving side MUST send a + go ahead response, and the sending side MUST wait for that response ⏳. servers MUST support literals of atleast 4096 octets 💪

strings sent from server to client SHOULD NOT use the synchronized literal format 🙅‍♀️

a quoted string is zero or more 7-bit characters, excluding CR, LF, and the double quote ("), with a double quote at each end 🎀

the empty string can be written either as "" (a quoted string with zero characters between the double quotes) or as {0} followed by CRLF (a literal with an octet count of 0) 🫙

3. Server Responses 💬

every client command can get one or more tagged responses from the server 📨. each response starts with the same tag as the command that triggered it 🏷️

3.1. Response: OK ✅

a tagged OK response means the operation finished successfully 🥳. there is a mandatory implementation-defined string after OK. this response also marks the start of streaming update mode when it's given in response to an UPDATE command 🌊

example:

C: N01 NOOP
S: N01 OK "NOOP Complete"

3.2. Response: NO 🙅

a tagged NO response means the server explicitly denied the operation or it failed some other way 😬. there is a mandatory implementation-defined string after NO, and it SHOULD explain why the request was denied 📝

example:

C: A01 AUTHENTICATE "PLAIN"
S: A01 NO "PLAIN is not a supported SASL mechanism"

3.3. Response: BAD 🙈

a tagged BAD response means the server couldn't parse or understand the client's command 💀. there is a mandatory implementation-defined string after BAD to give more detail about the error. note that untagged BAD responses are allowed when it isn't clear what tag goes with a command (for example, if a blank line shows up at the mupdate server, it can send back an untagged BAD response) 🤷‍♀️. for an untagged response, the tag should be replaced with a "*" ⭐

example:

C: C01 SELECT "INBOX"
S: C01 BAD "This is not an IMAP server"
C:
S: * BAD "Need Command"

3.4. Response: BYE 👋

a tagged BYE response means the server has decided to close the connection 🚪. there is a mandatory implementation-defined string after BYE, and it SHOULD explain why the connection is being closed. the server MUST close the connection immediately after sending the BYE response 🔌

example:

C: L01 LOGOUT
S: L01 BYE "User Logged Out"

3.5. Response: RESERVE 🔐

a tagged RESERVE response can only be sent in response to a FIND, LIST, or UPDATE command 🎯. it has two parameters: the name of the mailbox being reserved (in mUTF-7 encoding, as specified in [IMAP]), and a location string. the contents of that location string are defined by the clients using the database, but it is RECOMMENDED that the string be the hostname of the server storing the mailbox 🖥️

this response means the name is no longer available in the namespace. it does NOT mean the mailbox is available to clients right now 🙃

example:

S: U01 RESERVE "internet.bugtraq" "mail2.example.org"

3.6. Response: MAILBOX 📬

a tagged MAILBOX response can only be sent in response to a FIND, LIST, or UPDATE command 💌. it has three parameters: the name of the mailbox, a location string (same as with RESERVE), and a client-defined string that specifies the IMAP ACL [IMAP-ACL] of the mailbox. this message means the mailbox is ready for clients to access 🥂

example:

S: U01 MAILBOX "internet.bugtraq" "mail2.example.org" "anyone rls"

3.7. Response: DELETE 🗑️

a tagged DELETE response can only be sent in response to an UPDATE command, and it MUST NOT be sent before the OK response to that UPDATE command is given 🚫. it has a single parameter, the mailbox that should be deleted from the slave's database. this response means the mailbox no longer exists in the namespace of the database. it can be sent for any mailbox name, whether it's active, reserved, or nonexistent (though implementations SHOULD NOT issue DELETE responses for nonexistent mailboxes) 💅

example:

S: U01 DELETE "user.rjs3.sent-mail-jan-2002"
part 1 of 3 done! 🎀 more of the rewrite (starting at section 3.8) is coming next 💖

3.8. Server Capability Response 💖

Okay bestie, the moment a client connects, and again right after a successful STARTTLS command, the server MUST issue a capabilities banner of the following format:

The banner MUST contain a line that begins with "* AUTH" and contains a space-separated list of SASL mechanisms the server will accept for authentication. The mechanism names are sent as atoms. Servers MAY advertise no available mechanisms, which tells the client that STARTTLS has to be completed before authentication can happen 🔐. If the server doesn't support STARTTLS, that line MUST contain at least one mechanism.

If the banner is going out without a TLS layer and the server supports the STARTTLS command, the banner MUST contain the line "* STARTTLS" ✨. If the banner is going out under a TLS layer (or the server doesn't support STARTTLS), the banner MUST NOT contain this line.

The last line of the banner MUST start with "* OK MUPDATE" and then be followed by four strings: the server's hostname, an implementation-defined string naming the implementation, an implementation-defined string giving the version of the implementation, and a string that says whether the server is a master or a slave 👑. The master/slave indication MUST be either "(master)" or an MUPDATE URL that tells you where the master can be contacted.

Any unrecognized responses that show up before the "* OK MUPDATE" response MUST be ignored by the client 🙈.

Example:

S: * AUTH KERBEROS_V4 GSSAPI
S: * STARTTLS
S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)"

4. Client Commands 🎀

The following are valid commands a client can send to the MUPDATE server: AUTHENTICATE, ACTIVATE, DEACTIVATE, DELETE, FIND, LIST, LOGOUT, NOOP, RESERVE, STARTTLS, and UPDATE 🧚.

Before a successful AUTHENTICATE command has happened, the server MUST NOT accept any commands except for AUTHENTICATE, STARTTLS, and LOGOUT (and SHOULD reply with a NO response to all other commands). Not gonna lie, that's a very strict bouncer 💅.

4.1. Command: ACTIVATE

The ACTIVATE command has 3 parameters: the mailbox name, its location, and its ACL. This command MUST NOT not be issued to a slave server 🙅‍♀️.

This command can also be used to update the ACL or location information of a mailbox. Note that a mailbox doesn't have to be reserved (or even exist in the database) for an ACTIVATE command to succeed. Implementations MUST allow this behavior, because it helps keep the database in sync with the current state of the mailboxes 🔄.

4.2. Command: AUTHENTICATE

The AUTHENTICATE command starts a [SASL] negotiation session between the client and the server 🤝. It has two parameters. The first is mandatory and is a string naming the desired [SASL] mechanism. The second is a string holding an optional BASE64 encoded (as defined in section 6.8 of [MIME]) client first send.

All of the remaining SASL blobs that get sent MUST be sent across the wire in BASE64 encoded format, and followed by a CR and LF combination. They MUST NOT be encoded as strings.

Clients can cancel authentication by sending a * followed by a CR and LF 🛑.

The [SASL] service name for the MUPDATE protocol is "mupdate". Implementations are REQUIRED to implement the GSSAPI [SASL] mechanism, though they SHOULD implement as many mechanisms as possible 🔑.

If a security layer is negotiated, it should be used directly following the CR and LF combination at the end of the server's OK response (i.e., beginning with the client's next command). Only one successful AUTHENTICATE command may be issued per session 💜.

4.3. Command: DEACTIVATE

The DEACTIVATE command takes two parameters: the mailbox name and location data. The mailbox MUST already exist and be activated on the MUPDATE server. If the server responds OK, then the mailbox name has been moved to the RESERVE state 📦. If the server responds NO, then the mailbox name has not been moved (for example, because the mailbox wasn't already active). Any ACL information known about the mailbox MAY be lost when a DEACTIVATE succeeds 🫠. This command MUST NOT be issued to a slave.

Example:

C: A01 DEACTIVATE "user.rjs3.new" "mail3.example.org!u4"
S: A01 OK "Mailbox Reserved."

4.4. Command: DELETE

The DELETE command takes only a single parameter, the mailbox name to be removed from the database's namespace 🗑️. The server SHOULD give a NO response if the mailbox doesn't exist. This command MUST NOT be issued to a slave server.

4.5. Command: FIND

The FIND command takes a single parameter, a mailbox name. The server then responds with the current record for that mailbox, if there is one, and then an OK response 🔍.

Example (mailbox does not exist):

C: F01 FIND "user.rjs3.xyzzy"
S: F01 OK "Search Complete"

Example (mailbox is reserved):

C: F01 FIND "user.rjs3"
S: F01 RESERVE "user.rjs3" "mail4.example.org"
S: F01 OK "Search Complete"

4.6. Command: LIST

The LIST command is basically FIND across the entire database, so it's giving "search everything" 🌸. The LIST command takes a single optional parameter, which is a prefix to try to match against the location field of the records. Without the parameter, LIST returns every record in the database.

For each mailbox that matches, either a MAILBOX or a RESERVE response (whichever applies) gets sent to the client. When all the responses are done, an OK response is issued 📋.

Example:

C: L01 LIST
S: L01 RESERVE "user.rjs3" "mail4.example.org!u2"
S: L01 MAILBOX "user.leg" "mail2.example.org!u1" "leg lrswipcda"
S: L01 OK "List Complete"
C: L02 LIST "mail4.example.org!"
S: L02 RESERVE "user.rjs3" "mail4.example.org!u2"
S: L02 OK "List Complete"

4.7. Command: LOGOUT

The LOGOUT command tells the server to close the connection 👋. Its only valid response is the BYE response. The LOGOUT command takes no parameters.

4.8. Command: NOOP

The NOOP command takes no parameters 😴. As long as the client is authenticated, its only acceptable response is an OK. Any idle timeouts the server may have on the connection SHOULD be reset when this command is received.

If this command is issued after an UPDATE command has been issued, then the OK response also indicates that all pending database updates have been sent to the client ✅. That means the slave can guarantee its local database is up to date as of a certain time by issuing a NOOP and waiting for the OK. The OK MUST NOT return until all updates that were pending at the time of the NOOP have been sent.

4.9. Command: RESERVE

The RESERVE command takes two parameters (just like the RESERVE response): the mailbox name to reserve and location data. If the server responds OK, then the mailbox name has been reserved 🎉. If the server responds NO, then the mailbox name has not been reserved (for example, because another server already reserved it). This command MUST NOT be issued to a slave.

The typical sequence for mailbox creation is:

C: R01 RESERVE "user.rjs3.new" "mail3.example.org!u4"
S: R01 OK "Mailbox Reserved."
<client does local mailbox create operations>
C: A01 ACTIVATE "user.rjs3.new" "mail3.example.org!u4" "rjs3 lrswipcda"
S: A01 OK "Mailbox Activated."

4.10. Command: STARTTLS

The STARTTLS command requests the start of a [TLS] negotiation 🔒. The negotiation begins immediately after the CRLF in the OK response. After a client issues a STARTTLS command, it MUST NOT issue further commands until a server response has been seen and the [TLS] negotiation is complete.

The STARTTLS command is only valid in the non-authenticated state. The server stays in the non-authenticated state, even if client credentials are supplied during the [TLS] negotiation. The [SASL] EXTERNAL mechanism MAY be used to authenticate once [TLS] client credentials are successfully exchanged. Note that servers are not required to support the EXTERNAL mechanism 🫶.

After the [TLS] layer is established, the server MUST re-issue the initial response banner (see Section 3.8). This is necessary to protect against man-in-the-middle attacks that alter the capabilities list before STARTTLS, and it also advertises any new SASL mechanisms (or other capabilities) that may be available under the layer 🛡️. The client MUST discard cached capability information and replace it with the new information.

After the a successful STARTTLS command, the server SHOULD return a NO response to additional STARTTLS commands.

Servers MAY choose not to implement STARTTLS. In this case, they MUST NOT advertise STARTTLS in their capabilities banner, and SHOULD return a BAD response to the STARTTLS command if it is issued.

Example:

C: S01 STARTTLS
S: S01 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * AUTH KERBEROS_V4 GSSAPI PLAIN
S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)"

4.11. Command: UPDATE

The UPDATE command is how a slave starts an update stream from the master (though it's also valid to issue this command to a slave) 📡. In response, the server returns a list of all mailboxes in its database (the same results as a parameterless LIST command), followed by an OK response. From that point on, whenever an update happens to the master database, the master MUST stream the update to the slave within 30 seconds ⏱️. That is, it will send RESERVE, MAILBOX, or DELETE responses as they apply.

After a client has issued an UPDATE command, it may only issue NOOP and LOGOUT commands for the rest of the session 💅.

Example:

C: U01 UPDATE
S: U01 MAILBOX "user.leg" "mail2.example.org!u1" "leg lrswipcda"
S: U01 MAILBOX "user.rjs3" "mail3.example.org!u4" "rjs3 lrswipcda"
S: U01 RESERVE "internet.bugtraq" "mail1.example.org!u5" "anyone lrs"
S: U01 OK "Streaming Begins"
<some time goes by, and another client creates a new mailbox>
S: U01 RESERVE "user.leg.new" "mail2.example.org!u1"
<some more time passes, and the create succeeds>
S: U01 MAILBOX "user.leg.new" "mail2.example.org!u1" "leg lrswipcda"
<much more time passes, and the slave decides to send a NOOP to reset
its inactivity timer>
C: N01 NOOP
S: U01 DELETE "user.leg.new"
S: N01 OK "NOOP Complete"

5. MUPDATE Formal Syntax ✨

okay so this section is the grammar, the official rulebook for what messages look like 🧾💅 It's written in ABNF (the notation from [ABNF]), using the core rules from Appendix A of that same doc. bestie, pay attention here 👀

Unless noted otherwise, all alphabetic characters are case-insensitive. Writing token strings in upper or lower case is just for readability, not a rule. Implementations MUST accept these strings case-insensitively, no exceptions 💖

This spec also borrows some terminals from section 8 of [ACAP] 🦋

cmd-activate = "ACTIVATE" SP string SP string SP string

cmd-authenticate = "AUTHENTICATE" SP sasl-mech [ SP string ]
cmd-delete = "DELETE" SP string

cmd-find = "FIND" SP string

cmd-list = "LIST" [ SP string ]

cmd-logout = "LOGOUT"

cmd-noop = "NOOP"

cmd-reserve = "RESERVE" SP string SP string

cmd-starttls = "STARTTLS"

cmd-update = "UPDATE"

command = tag SP command-type CRLF

command-type = cmd-activate / cmd-authenticate / cmd-delete /
               cmd-find / cmd-list / cmd-logout / cmd-noop /
               cmd-reserve / cmd-starttls / cmd-update

response = tag SP response-type CRLF

response-type = rsp-ok / rsp-no / rsp-bad / rsp-bye / rsp-mailbox /
                rsp-reserve / rsp-delete

rsp-bad = "BAD" SP string

rsp-bye = "BYE" SP string

rsp-mailbox = "MAILBOX" SP string SP string SP string

rsp-no = "NO" SP string

rsp-ok = "OK" SP string

rsp-reserve = "RESERVE" SP string SP string

rsp-delete = "DELETE" SP string

sasl-mech = 1*ATOM-CHAR
   ; ATOM-CHAR is defined in [ACAP]

string = quoted / literal
   ; quoted and literal are defined in [ACAP]

tag = 1*ATOM-CHAR
   ; ATOM-CHAR is defined in [ACAP]

6. MUPDATE URL Scheme 🔗

This doc defines a URL scheme for referencing MUPDATE resources, following the requirements in [RFC2717] 💫 That covers the whole MUPDATE server, and also individual mailbox entries on a given server.

There's no MIME type for these resources 🙈 A URL consumer would either fetch the MUPDATE record it points to, or just connect to the MUPDATE server on the specified host. Heads up: the consumer will need authentication credentials for that host 🔑

The MUPDATE URL scheme is like the IMAP URL scheme [IMAP-URL], but it only comes in two forms 🎀

mupdate://<iserver>/
mupdate://<iserver>/<mailbox>

The first form points at the server as a whole. The second points at the server AND a mailbox, and tells you to run a FIND against that mailbox once you've authenticated 🕵️‍♀️ Also, part of <iserver> can include username and authentication info along with the hostname and port.

6.1. MUPDATE URL Scheme Registration Form 📝

URL scheme name: "mupdate"

URL scheme syntax:

This defines the MUPDATE URL Scheme in [ABNF]. Terminals from the BNF of IMAP URLs [IMAP-URL] are also used.

     mupdateurl = "mupdate://" iserver "/" [ enc_mailbox ]
        ; iserver and enc_mailbox are as defined in [IMAP-URL]

Character encoding considerations:

Same as what [IMAP-URL] describes for the matching terminals ✨

Intended Usage:

The URL form without a mailbox is meant to designate just the MUPDATE server. If there's a mailbox name in the URL, the consumer is expected to run a FIND command for that mailbox on the specified server 🔍

Applications and/or protocols which use this URL scheme name:

The protocol described in this document 🦋

Interoperability Considerations:

None. 💅

Security Considerations:

People using the MUPDATE URL Scheme should check out the security considerations in [IMAP-URL] 🙈 Especially look at what happens when you put authentication mechanism info inside a URL. That one's a big deal, so it should be reviewed.

Relevant Publications:

This document and [IMAP-URL] 📚

Author, Change Controller, and Contact for Further Information:

Author of this document. 🌸

7. Security Considerations 🚨🔐

Okay, bestie, this one's SERIOUS 😭 Unauthenticated users may not modify the database or even search it. BUT it's important to know that this spec gives NO protections of any kind to authenticated users 💀

Every authenticated user has complete access to the database. So you really need to make sure any account touching the database is locked down tight 🔒

A more secure setup might send all read-only access through a slave, and only let accounts that need write access talk to the master 🛡️ The downside is that updates take a little longer to reach clients. Worth it, imo.

Now the big one. The protocol assumes all authenticated users are cooperating to keep operations atomic 🤝 So all new mailboxes SHOULD be RESERVEd before they are ACTIVATEd. The protocol doesn't actually require this, which means a group of participants who ignore the provided locking CAN end up creating an inconsistent database 😱 Also, RESERVEing first isn't needed for an ACTIVATE, because this behaviour makes syncing with where the mailboxes actually live way simpler ✨

Translation: reserve first, activate second, and don't go rogue with the locks. Trust me. 💀

8. IANA Considerations 🏛️

IANA has assigned TCP port number 3905 to "mupdate" 🔌

IANA has registered a URL scheme for the MUPDATE protocol, as defined in section 6.1 of this document 🎀

IANA has also registered a GSSAPI service name of "mupdate" for the MUPDATE protocol 🧚 You can find it in the registry at:

http://www.iana.org/assignments/gssapi-service-names

9. Intellectual Property Rights 📜

The IETF doesn't take a position on whether any intellectual property or other rights that someone might claim over the tech in this document are valid or in scope. It also doesn't say whether licenses for those rights are available, and it hasn't tried to find out what rights might exist 🤷‍♀️ Info about the IETF's procedures for rights in standards-track and standards-related documents is in BCP-11. Claims of rights that were made available for publication, plus any assurances of licenses, or the results of trying to get a general license or permission for implementers or users to use those proprietary rights, can be obtained from the IETF Secretariat 📬

The IETF also invites anyone to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practise this standard. Send that info to the IETF Executive Director 💌

10. References 📚

10.1. Normative References 💜

  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [IMAP] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 3501, March 2003.
  • [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [MIME] Freed, N. and N. Bornstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
  • [IMAP-ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
  • [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
  • [IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
  • [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
  • [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.

10.2. Informative References 🌈

  • [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
  • [RFC2717] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.

11. Acknowledgments 🫶

Huge thanks to Lawrence Greenfield and Ken Murchison, who gave a great deal of input on both the protocol and the text of the documents 💖

12. Author's Address 📮

Robert Siemborski
Carnegie Mellon, Andrew Systems Group
Cyert Hall 207
5000 Forbes Avenue
Pittsburgh, PA  15213

Phone: (412) 268-7456
EMail: rjs3+@andrew.cmu.edu

Copyright (C) The Internet Society (2003). All Rights Reserved. 🌸

This document, and translations of it, may be copied and given to others. Derivative works that comment on or explain it, or help with implementing it, may be written, copied, published and distributed, in whole or in part, with no restriction of any kind. The one condition is that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are: it can be modified as needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed; or it can be translated into languages other than English 🌍

The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assignees 💜

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀

Acknowledgement 🎀

Funding for the RFC Editor function is currently provided by the Internet Society ✨

📦 where this page comes from