RFC 1733

RFC 1733: Distributed Electronic Mail Models in IMAP4 💌

Title block tea ☕

• Series: Network Working Group 🌸
• RFC number: 1733 ✨
• Title: Distributed Electronic Mail Models in IMAP4 💖
• Author: M. Crispin (Mark R. Crispin), University of Washington 🎀
• Category: Informational 📚
• Date: December 1994 📅
• Obsoletes / Updates: the title block doesn't list anything here, so no obsoleting or updating to report 🫶

Status of this Memo 📜

okay so this memo is giving info for the Internet community 🦋 It is not an Internet standard of any kind, so nobody is forced to do anything because of it. Distribution is unlimited, which means share it with everyone you know 💅

Distributed Electronic Mail Models 💌

okay bestie, there are three fundamental models of client/server email: offline, online, and disconnected use 🔥 IMAP4 can run in any one of the three, and it's giving main character energy ✨

The offline model 📮 is the most familiar form of client/server email today. Protocols like POP-3 (RFC 1225) and UUCP use it. A client app periodically connects to a server, downloads all the pending messages to the client machine, and deletes them from the server 🗑️ After that, all mail processing happens locally on the client. It's store-and-forward, so it moves mail on demand from an intermediate server (maildrop) to one single destination machine. Lowkey iconic, but a little old-school 🧚

The online model 🖥️ is mostly used with remote filesystem protocols like NFS. The client app messes with mailbox data sitting on a server machine, and the connection stays up for the whole session. No mailbox data gets kept on the client. The client just grabs data from the server whenever it's needed 🌈 IMAP4 brings in its own version of online that uses way less network bandwidth than a remote filesystem protocol, and it lets you hand CPU or I/O heavy stuff like parsing and searching over to the server 🫶 slay.

The disconnected use model 🦋 is a hybrid of offline and online, and protocols like PCMAIL (RFC 1056) use it. A user downloads some set of messages from the server, edits them offline, and later uploads the changes. The server is still the authoritative repository of the messages 👑 Syncing can get messy, especially when multiple clients are involved, so it's handled with a unique identifier for each message 💜

Each of these models has its own strengths and weaknesses, and the table is the tea ☕

   Feature                               Offline Online  Disc
   -------                               ------- ------  ----
   Can use multiple clients               NO      YES     YES
   Minimum use of server connect time     YES     NO      YES
   Minimum use of server resources        YES     NO      NO
   Minimum use of client disk resources   NO      YES     NO
   Multiple remote mailboxes              NO      YES     YES
   Fast startup                           NO      YES     NO
   Mail processing when not online        YES     NO      YES

Okay so IMAP4 started out designed for the online model 🌸 but it can totally support the other two too 🙈 That makes it possible to build clients that work in any of the three models. For example, a user might want to switch between online and disconnected on a regular basis, like when they're traveling ✈️ literally so relatable.

IMAP4 is built to send message data on demand, and it gives the client the tools to figure out what data it needs at any given moment 💅 There's usually no reason to transfer a whole mailbox, or even the full text of one message. That matters a lot when the mailbox is huge or the link to the server is slow 🐌

More specifically, IMAP4 supports server-based RFC 822 and MIME processing 🎀 With that info, a client can decide ahead of time whether it even wants a message or part of one. Say a user on a dialup link finds out a message has a 2000 byte text segment and a 40 megabyte video segment. They can just fetch the text and skip the video 😭 no thanks, bestie.

In IMAP4, the client/server relationship only lasts as long as the TCP connection 🌊 There's no client registration. Except for any unique identifiers used in disconnected use operation, the client starts out knowing nothing about the mailbox state. It learns that from the IMAP4 server when a mailbox gets selected. That first transfer is pretty minimal, and the client asks for more state data as it needs it 🧚

As mentioned above, where mailbox data lives depends on the model. Message state, like whether a message has been read or answered, is also decided by the model, and it doesn't have to live in the same place as the mailbox data 🍓 For example, in the online model, message state can sit right next to the mailbox data. It can also live somewhere else, like on the client or on a third agent, using unique identifiers so everyone can reference the same thing across sessions. That last option is especially handy with a server that shares public data like netnews and doesn't keep per-user state 💜

The IMAP4 protocol has the flexibility to implement all these different models ✨ That happens through server and (especially) client configuration, not by changing the protocol or how it's implemented. Literally no protocol rewrite needed, periodt 💖

Security Considerations 🔒

💀 Okay, real talk, this is the dramatic part. Security issues are not discussed in this memo. Zero. None. Keep that in mind before you trust anything here 🙈

Author's Address 🎀

Mark R. Crispin
Networks and Distributed Computing, JE-30
University of Washington
Seattle, WA  98195

Phone: (206) 543-5762

EMail: MRC@CAC.Washington.EDU

That's the whole RFC, bestie! 🌈🦋💖