Email box

An email box (also email mailbox, e-mailbox) is the destination to which electronic mail messages are delivered. It is the equivalent of a letter box in the postal system.

Definitions

A mailbox is identified by an email address. However, not all email addresses correspond to a storage facility. The term pseudo-mailbox is sometimes used to refer to an address that does not correspond to a definitive mail store. Email forwarding may be applied to reach end recipients from such addresses. Electronic mailing lists and email aliases are typical examples.

RFC 5321,^[1] defines an email address as a character string that identifies a user to whom mail will be sent or a location into which mail will be deposited. The term mailbox refers to that depository. In that sense, the terms mailbox and address can be used interchangeably.

RFC 5322 defines a mailbox as follows:^[2] A mailbox receives mail. It is a 'conceptual entity' that does not necessarily pertain to file storage. It further exemplifies that some sites may choose to print mail on a printer and deliver the output to the addressee's desk, much like a traditional fax transmission.

Access

Access to a mailbox is controlled by a mailbox provider. Usually, anyone can send messages to a mailbox while only authenticated users can read or delete from their own mailboxes. An email client retrieves messages from one or more mailboxes. The database (file, directory, storage system) in which the client stores the messages is called the local mailbox.

Read access

Popular client–server protocols to retrieve messages are:

• Post Office Protocol (POP): a method that is most suitable for reading messages from a single client computer. Usually messages are removed from the server mailbox after retrieval. Anyway, the master copy of a message is the one in the local mailbox.
• Internet Message Access Protocol (IMAP): designed to retrieve messages from multiple clients by allowing remote management of the server mailbox. Master copies stay on the server, but a copy can be saved locally.
• Webmail over HTTP: messages are served to a user's browser in a server-defined format. Master copies stay on the server, possibly in the original format, which may be downloadable.

IMAP and webmail can go along with each other more or less seamlessly. POP, if configured to leave messages on server, can be compatible with them.

Internet message format, currently defined by RFC 5322, dates back to 1982 (RFC 822). That is what POP and IMAP clients expect to retrieve.

Write access

Messages sent to a mailbox are written by a mail delivery agent into the server's local mailbox, which, for remote users, is a remote mailbox that they own on that server. IMAP clients can copy, move, and delete messages in remote mailboxes.

Size quota

Mailboxes have a size limit, either determined implicitly by available memory, or after quota definitions for that mailbox or folders thereof. Besides administrative trivia, quota limits help mitigate email bomb attacks.^[3]

An IMAP extension for quota was standardized in 1997.^[4]

Storage format

Any kind of database can be used to store email messages. However, some standardization has resulted in several well-known file formats to allow access to a given mailbox by different computer programs. There are two kinds of widely used formats:

• mbox is the original technique of storing all messages in a single file,
• Maildir is a newer specification that provides for storing all messages in a directory tree, with one file for each message.

Mailbox names

A mailbox name is the first part of an email address, also known as local-part; that is, the part before the @ symbol. Its format is formally specified by RFC 5322 and RFC 5321. It is often the username of the recipient on the mail server or in the destination domain.

The local-part may be up to 64 characters long and, in theory, is case-sensitive. It can consist of either a sequence of valid characters (described below) or a quoted string, which can also contain spaces and special characters. Using SMTPUTF8 extended SMTP it is also possible to use non-ASCII characters.^[5] Some common sense is needed when creating new mailbox names, in order to avoid common pitfalls. In the words of RFC 5321, very wary of imposing restrictions:

While the above definition for Local-part is relatively permissive, for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case-sensitive.

— John Klensin, RFC 5321

Valid characters

The following characters may appear in a local-part without quoting:

• Uppercase and lowercase English letters (a–z, A–Z), and UTF-8 sequences if using SMTPUTF8
• Digits 0 to 9
• Characters ! # $ % & ' * + - / = ? ^ _ ` { | } ~
• Character . (dot) provided that it is not the first or last character, and provided also that it does not appear two or more times consecutively (e.g. [email protected]).

Reserved names

The names "postmaster", "abuse", and others correspond to well-known roles and functions, and are required to be valid.^[6]

Some names are known to cause troubles, possibly because they conflict with names used internally by (some parts of) the mail software, including mail filters, or because the underlying storage system chokes on them. A number of lists exist, for example on GitHub.^[7][8][9] See the Scunthorpe problem for a striking filter case.

References

1. RFC 5321, Simple Mail Transfer Protocol, J. Klensin, The Internet Society (October 2008), Section 2.3.11 (Mailbox and Address)
2. RFC 5322, Internet Message Format, P. Resnick (Ed.), The Internet Society (October 2008), Section 3.4 (Address Specification)
3. Nick Christenson; Tim Bosserman; David Beckemeyer (December 9, 1997). "A Highly Scalable Electronic Mail Service Using Open Systems". USENIX. Retrieved December 12, 2015. In addition to authentication and mailbox location, the mail delivery agent also knows about mailbox quotas which we impose on our subscribers. If the current mailbox size is over the quota for that user, the default being 10 MB, then the message is bounced back to the MTA with reason, "User npc, mailbox full." In addition to preventing resource abuse on the part of subscribers, this also helps mitigate possible damaging effects of mail bombing by malicious people on the Internet. We believe that a 10 MB quota is quite generous, especially considering over a 28.8 modem using very high quality line speeds and no network bottlenecks, one could expect to take over an hour to download the contents of a 10 MB mailbox.
4. John G. Myers (January 1997). IMAP4 QUOTA extension. IETF. RFC 2087. https://tools.ietf.org/html/rfc2087. 
5. Jiankang YAO; Wei MAO (February 2012). "The SMTPUTF8 Extension". SMTP Extension for Internationalized Email. IETF. sec. 3.2. RFC 6531. https://tools.ietf.org/html/rfc6531#section-3.2. Retrieved December 12, 2015. 
6. Dave Crocker (May 1997). Mailbox names for common services, roles and functions. IETF. sec. 3,4,5. RFC 2142. https://tools.ietf.org/html/rfc2142#section-3,4,5. Retrieved December 12, 2015. 
7. Casey O'Hara (2011). "A list of reserved usernames to avoid vanity URL collision with resource paths". GitHub. Retrieved December 12, 2015.
8. Michael Mahemoff (2011). "Reserved username list". GitHub. Retrieved December 12, 2015.
9. ShouldBee. "reserved-usernames". GitHub. Retrieved December 12, 2015.