Appendix A. Simple Mail Access Protocol, Version 1

Note

This document is a work-in-progress.

Introduction

Simple Mail Access Protocol (SMAP, or SMAP1 if referring specifically to this version) enables programs (referred in this document as "clients") to use a network connection to a server process for reading and manage MIME E-mail messages in a mailbox.

SMAP is an experimental protocol for testing new mail client/server functionality that's not possible with existing mail access protocols. SMAP is sufficient for implementing traditional mail access functionality: a hierarchical arrangement of folders; random access to messages in a folder; access individual MIME sections of messages; per-message metadata such as various flags, and a datestamp. Beyond that, SMAP's primary focus is to serve as an experimental implementation of advanced mail client/server functionality.

Summary

  • SMAP tries to provide powerful mail access service using a structurally-simple, line oriented syntax. Client commands and server replies are newline-delimited lines of text consisting of whitespace-delimited tokens. SMAP syntax's complexity is closer to POP3's and SMTP's, rather than to IMAP's.

  • SMAP's design allows it to coexist with IMAP. Both IMAP and SMAP can be implemented by the same server. An SMAP client has the ability to fall back to IMAP if the server does not have SMAP capabilities.

  • SMAP decodes MIME-encoded attachments, and sends the raw data to the SMAP client. base64-encoded MIME attachments enjoy a 25% reduction in bandwidth needed to download the attachment...

  • A single SMAP transaction saves a new message to a folder, and sends the message to its designated recipients. This essentially halfes the bandwidth required to send a new message. Without SMAP, a mail client has to transmit the message twice: once to save a file-copy of the sent message in a folder, and a second time to send the message using SMTP. With SMAP, the mail client only needs to send the message once. The server saves the message in the folder, the sends the message to its listed recipients.

  • An SMAP client does not need to download the entire index of folder's contents when reopening a previously seen folder. When reopening a folder, the client receives a much shorter list of changes to the folder's contents since the last time the client had the folder opened.

    This is done by the client and server saving an index of folder's contents. After reopening the folder the server only needs to send the delta of changes between the saved folder index, and the current folder index.

  • SMAP provides a hierarchical collection of mail folders. Folder names use the UTF-8 character set. A telnet connection from an UTF-8 terminal will be able to fully navigate and manage the folders. Names of SMAP folders may contain any UTF-8 character (excluding the control character range U+0000 through U+001F). SMAP does not reserve a folder hierarchy delimiter character.

  • SMAP specifies a clearly defined process for synchronizing multiple SMAP clients that have the same folder opened concurrently.

  • SMAP uses simple unique identifiers that are similar to the POP3's model.

  • SMAP provides two ways for removing messages from a folder. Messages may be removed directly, or using a mark as deleted, then expunge paradigm.

    Similarly, messages are moved between folders using a single move process, instead of copy, delete, expunge (which is also available). This allows for greater efficiency with quota-limited mail accounts, since moving messages between folders will not require reserving quota-limited space equivalent to the sum total of the messages that are moved.

  • Additional facilities, that are useful in internationalized environments, include specifying native languages for error messages, and internationalized folder names.

Roadmap

SMAP is a work-in-progress. Additional advanced mail handling protocols are expected to be defined in the future. At this time, the following additions are planned:

  • Advanced mechanism for uploading new messages to the server. Individual attachments are uploaded as binary data. The server selects and applies the appropriate encoding. The server creates the appropriate MIME headers.

Conventions used in this document

This document uses U+hhhh, where hhhh is a hexadecimal number, to refer to a specific Unicode/ISO-10646 character. In examples, C: indicates a command sent by the SMAP client to the server, and S: indicates the server's response.

Some examples have long commands or replies line-wrapped for readability purposes. The actual commands and replies are generally a single line of text, terminated by the LF character (U+000A).