[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

# 3. Concepts

To use IMAIL effectively, it is helpful to know the terminology and understand the concepts underlying IMAIL's design. Here we will introduce you to messages, folders, URLs, and server connections.

> 3.1 Messages |  |
> 3.2 Folders |  |
> 3.3 Containers |  |
> 3.4 URLs |  |
> 3.5 Server Connections |  |

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 3.1 Messages

A message, or email message, is the basic unit of electronic mail. The format of a message is defined by RFC 822. Nearly all email messages are transmitted over the internet, which means that the contents of such messages are further constrained by the SMTP protocol that is used for internet message transmission, as defined in RFC 821.

In brief, the primary constraints on an email message is that it may contain only printable US-ASCII characters, and that lines of text in the message may not exceed 1000 characters, including the carriage-return/linefeed pair at the end of each line. These constraints are fairly strict, and do not permit messages to contain text in languages other than English, or to contain non-textual data such as images. The Multipurpose Internet Mail Extensions (MIME, RFC 2045) provide a way to encode other kinds of text and data so that they can be carried in an email message. Most modern email software supports the MIME standard; one notable exception is Emacs Rmail.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 3.2 Folders

Another important concept is a means for grouping messages together. All email software provides some means for doing this, and IMAIL is no exception. IMAIL provides objects called folders. A folder is just an object that holds an arbitrary number of email messages. Messages can be added to a folder, deleted from a folder, and moved or copied from one folder to another.

In IMAIL, the concept of the folder is used to embrace different grouping mechanisms. This is because IMAIL provides a uniform means for accessing different kinds of email systems. In particular, IMAIL supports access to Emacs Rmail files (also known as BABYL files, for historical reasons), to unix mailbox files (sometimes called mbox files), and to IMAP mailboxes. Each of these grouping mechanisms, although implemented very differently, is viewed as a folder by IMAIL. With some exceptions, each of these different types of folder are treated exactly the same by IMAIL. Finally, because IMAIL is extensible, other types of folders may be supported in the future.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 3.3 Containers

Folders can themselves be grouped together inside objects called containers. A container is an object that holds folders, much in the same way that a folder holds messages. As for folders, the concept of a container is a generalization of the different kinds of mechanisms used by the underlying mail technology. So, for example, the container of a file folder is the directory holding that file.

IMAP containers are a little different: each IMAP mailbox is capable of holding other mailboxes. What this means is that, from IMAIL's point of view, an IMAP mailbox is both a folder object and a container object at the same time. However, when IMAIL views an IMAP mailbox as a container, it is treated differently than when it is viewed as a folder, and consequently different notation is used in each case.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 3.4 URLs

In email software like Rmail, where mail is stored in files, filenames are used to refer to groups of messages. Since IMAIL folders often aren't files, it is necessary to use a more general kind of reference for folders. To this end, IMAIL uses Uniform Resource Locators (URLs) to refer to folders.(2) IMAIL currently supports two kinds of URLs: IMAP URLs and file URLs.

> 3.4.1 IMAP URLs |  |
> 3.4.2 File URLs |  |
> 3.4.3 Container URLs |  |

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### 3.4.1 IMAP URLs

The first kind of URL is an IMAP URL,(3) which looks like this:

    imap://uname@hostname:port/mailbox

In this syntax, the parts ``uname@`' and ``:port`' are optional. Hostname is the internet host name or IP address of the IMAP server. Uname is the user name that identifies the account to be accessed on the server; this defaults to your user name. Port is the server's IP port; this defaults to `143` and is normally not specified.

Mailbox specifies the IMAP mailbox (or folder, in IMAIL's terminology) that is being referred to. Since most IMAP servers support hierarchical mailboxes, mailbox is a structured component indicating the location of the folder in the hierarchy, much like filenames or HTTP URLs. Here are some examples of IMAP URLs showing different mailbox paths:

    imap://localhost/inbox
    imap://localhost/inbox/sysadmin
    imap://localhost/inbox/sysadmin/equipment

Here you see several interesting properties of IMAP mailboxes. The first URL refers to the primary IMAP mailbox for this account, called the inbox. All IMAP servers must support this mailbox, which is always called ``inbox`'; the name is not case sensitive and may be typed in any combination of upper or lower case letters. However, case sensitivity for names other than ``inbox`' is undefined by IMAP, so IMAIL treats all other names as if they were case sensitive.

The second and third URLs show how hierarchically-nested mailboxes are referred to: by writing the components of the path, separated by slashes. Note that IMAP does not require particular path-separator characters for hierarchical names, and in fact different IMAP servers use different separators. However, IMAIL always uses the forward-slash character as a separator, and translates to the server's character as needed.(4)

Another thing to note about these examples is that IMAP, unlike most file systems, allows a folder to contain messages and to have subfolders. This includes the ``inbox`' folder, as shown here. At least one server (Cyrus) puts all subfolders for a user account under ``inbox`', but this is not required by IMAP and is not generally true.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### 3.4.2 File URLs

There is one other URL type supported by IMAIL: file URLs. This uses the ``file:`' URL syntax,(5) as follows:

    file://hostname/pathname

Here hostname refers to the host on which the file (folder) resides. Since IMAIL supports only files on the local file system, hostname must be ``localhost`'; it may also be omitted, as in

    file:///pathname

IMAIL also supports a non-standard abbreviation:

    file:/pathname

As specified by the URL standard, pathname is a slash-separated sequence of path components, where unusual characters appearing in the components, such as the space character, are specially encoded. However, IMAIL will accept nearly any character in a component, and encode it if required; with few exceptions you can type any pathname without encoding. IMAIL always displays URLs with proper encoding.

In practice, this means that most unix filenames are written verbatim, with exceptions for special characters, and with the leading slash omitted. However, DOS-style filenames, as used by Windows and OS/2, must be specially rewritten to conform to this style.

The rewriting rules for DOS file URLs are not specified by the standard, so consequently IMAIL defines its own rules for this encoding, as follows. A DOS filename is encoded by replacing all of the backslash characters with forward-slash characters, and by encoding unusual characters in the path components. Finally, the drive letter is prefixed to the path with an additional forward-slash separator. So for, example, the filename

    C:\My Documents\Mail\My Mail.rmail

becomes the URL

    file://localhost/C:/My%20Documents/Mail/My%20Mail.rmail

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### 3.4.3 Container URLs

IMAIL also uses URLs to refer to containers. The notation used for a container is what you would expect: take a folder URL and drop everything after the rightmost slash. For example, the folder URL

    imap://localhost/inbox/sysadmin/equipment

has the corresponding container URL

    imap://localhost/inbox/sysadmin/

Note that this is different from the URL for the `sysadmin` folder:

    imap://localhost/inbox/sysadmin

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 3.5 Server Connections

Unlike a file folder, in which the folder's contents are always available, access to an IMAP folder requires an active network connection to the IMAP server. This adds an additional layer of complexity to the mail-reading process, which is reflected in the connection state of an IMAP folder.

An IMAP folder can be in one of two states: online, meaning that there is an established network connection between IMAIL and the IMAP server, and offline when there is not. IMAIL is, at present, a very simple IMAP mail reader: it must be online to read and manipulate mail messages. Mail readers that have this property are said to operate in online mode.(6) Do not confuse the online state with online mode. When we refer to online or offline in this document, it always means the corresponding state.

When an IMAP folder is selected in an IMAIL buffer, the modeline for that buffer shows either ``online`' or ``offline`' to indicate the folder's connection state. Normally, an IMAP folder goes online when it is first selected, and stays online indefinitely until it is explicitly disconnected.(7) Commands that break the connection are explicitly pointed out in their descriptions below; most other commands will force an IMAP folder into the online state if it is offline.

[ << ] | [ >> ] |  |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

This document was generated by Chris Hanson on June, 17 2002 using texi2html