Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Email box.
Nothing was collected or created yet.
Email box
View on Wikipediafrom Wikipedia
A mailbox[1] (also electronic mailbox,[1] email box, 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
[edit]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,[2] 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:[3] 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
[edit]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
[edit]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
[edit]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
[edit]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.[4]
An IMAP extension for quota was standardized in 1997.[5]
Storage format
[edit]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:
Mailbox names
[edit]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 extension of SMTP it is also possible to use non-ASCII characters.[6] 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
[edit]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
0to9 - 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. John..Doe@example.com).
Reserved names
[edit]The names "postmaster", "abuse", and others correspond to well-known roles and functions, and are required to be valid.[7]
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.[8][9]
References
[edit]- ^ a b ISO/IEC 2382:2015
- ^ RFC 5321, Simple Mail Transfer Protocol, J. Klensin, The Internet Society (October 2008), Section 2.3.11 (Mailbox and Address)
- ^ RFC 5322, Internet Message Format, P. Resnick (Ed.), The Internet Society (October 2008), Section 3.4 (Address Specification)
- ^ 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.
- ^ John G. Myers (January 1997). IMAP4 QUOTA extension. IETF. doi:10.17487/RFC2087. RFC 2087.
- ^ Jiankang YAO; Wei MAO (February 2012). "The SMTPUTF8 Extension". SMTP Extension for Internationalized Email. IETF. sec. 3.2. doi:10.17487/RFC6531. RFC 6531. Retrieved December 12, 2015.
- ^ Dave Crocker (May 1997). Mailbox names for common services, roles and functions. IETF. sec. 3,4,5. doi:10.17487/RFC2142. RFC 2142. Retrieved December 12, 2015.
- ^ Casey O'Hara (2011). "A list of reserved usernames to avoid vanity URL collision with resource paths". GitHub. Retrieved December 12, 2015.
- ^ Michael Mahemoff (2011). "Reserved username list".
Email box
View on Grokipediafrom Grokipedia
An email box, also known as a mailbox, is a digital repository that serves as the destination for electronic mail messages, where incoming emails are stored and organized for retrieval by the recipient, typically associated with an email address in the format
local-part@domain.[1] This structure functions analogously to a physical letter box in postal systems, enabling the separation of message delivery from user access.[2]
The concept of the email box originated in 1965 with the MAIL command on MIT's Compatible Time-Sharing System (CTSS), which allowed users on the same computer to exchange messages stored in files named MAIL.BOX.[3] In 1971, Ray Tomlinson extended this capability across the ARPANET by inventing network email and introducing the "@" symbol to denote the user's mailbox on a specific host, marking the birth of modern internet email addressing.[4] By the 1970s, email had proliferated on ARPANET, with protocols evolving to standardize mailbox handling for reliable message transport.[5]
Email boxes are governed by key Internet standards defined in Request for Comments (RFCs) published by the Internet Engineering Task Force (IETF). The Simple Mail Transfer Protocol (SMTP), specified in RFC 5321, handles the delivery of messages to mailboxes via commands like MAIL FROM for the sender's reverse-path and RCPT TO for recipient forward-paths.[6] The message format, including how mailboxes appear in headers such as From: and To:, is outlined in RFC 5322 (updating RFC 2822), where a mailbox is syntactically defined as a local-part followed by "@" and a domain, optionally with a display name.[7] These standards ensure interoperability across diverse email systems, with mailboxes serving as the core identifier for routing and delivery.[8]
Users access email boxes through retrieval protocols that allow interaction with stored messages on a server. The Internet Message Access Protocol (IMAP), detailed in RFC 9051 (updating RFC 3501), enables clients to manage mailboxes remotely, including creating, renaming, and searching folders while supporting offline synchronization.[9] In contrast, the Post Office Protocol (POP3), defined in RFC 1939, facilitates downloading messages to a local client, often removing them from the server after retrieval. These protocols decouple mailbox storage from end-user devices, promoting centralized management.
Mailbox storage varies by implementation, with common formats including mbox and Maildir. The mbox format, standardized as the application/mbox media type in RFC 4155, stores multiple messages in a single plain-text file, where each begins with a "From " line followed by the sender's address and timestamp. Maildir, introduced in the 1990s for qmail, uses a directory structure with subdirectories like new, cur, and tmp to hold individual message files, avoiding file-locking issues inherent in mbox and improving concurrency.[10] Other formats, such as Microsoft's PST for Outlook, provide proprietary container-based storage but adhere to core RFC message formats.[11]
Definitions and Concepts
Core Definition
An email box, commonly referred to as a mailbox, is a digital storage container that holds electronic messages destined for a specific user or email address, functioning as the primary repository for incoming and outgoing correspondence in an email system.[12][13] It serves as the virtual equivalent of a physical letter box, where messages are accumulated for the recipient's review.[14] Upon transmission, electronic messages are routed and delivered to the designated email box using protocols such as the Simple Mail Transfer Protocol (SMTP), which ensures reliable transfer from the sender's server to the recipient's mail server.[15] Once delivered, the messages remain persistently stored in the box until the user accesses, reads, or deletes them, providing a stable holding area independent of the sender's actions.[12] The concept of the email box traces its origins to early computing in the 1960s, with the development of the MAILBOX program at MIT for exchanging messages on time-sharing systems, and gained prominence in the 1970s during the ARPANET era as email usage exploded among researchers.[16] Key attributes include data persistence to retain messages over time, organizational structures like folders for categorizing and archiving content, and tight integration with delivery mechanisms like SMTP to facilitate seamless message inflow.[12] These features enable efficient management while distinguishing the box from broader elements like an email account.[14]Related Terminology
An email box, often referred to as a mailbox, serves as the digital storage container for electronic messages delivered to a specific address, analogous to a physical receptacle for letters.[17] In contrast, an email account represents the user's subscription to an email service provider, which includes authentication credentials, billing details, and potentially access to multiple mailboxes or additional features like calendars and contacts.[18] This distinction ensures that while the box handles message retention, the account manages secure access and service-level permissions.[19] Within an email box, the inbox functions as the default primary folder designated for receiving and initially storing incoming messages before they are sorted or archived elsewhere.[20] It acts as the central hub for new correspondence in most email clients, allowing users to view unread items prominently upon login.[21] The term "mailbox" is a standard synonym for email box in technical specifications, as defined in RFC 5322, where it denotes a conceptual entity that receives mail, typically represented by an addr-spec such as a local-part followed by "@" and a domain.[7] Other related terms include "mail folder," which may refer to subcontainers within the box for organizing messages, though this is more common in client interfaces than core protocols.[22] These synonyms maintain consistency with postal metaphors while adapting to digital contexts. The etymology of "mailbox" traces back to 1797 in English, combining "mail" (from Old French "male," meaning a traveling bag or pouch for letters, derived from Frankish *malha for "mesh" or bag) with "box," initially describing containers for mailbags on coaches before evolving to public letter deposits by 1853.[23] In electronic mail, this postal heritage was directly adopted in the 1970s, with early systems like MIT's MAILBOX program explicitly borrowing the concept to describe digital message repositories.[16]Types of Email Boxes
Local Storage Boxes
Local storage boxes, also referred to as local mailboxes, consist of email collections stored directly on user devices such as personal computers or mobile applications, typically organized as files or directories within the client's file system.[24] These setups allow users to manage emails independently of remote servers, with data residing in designated folders like the user's profile directory.[25] In early Unix systems, local email storage emerged as a foundational approach, with the mail command introduced in the first edition of Unix in 1971 for basic sending and receiving.[26] By the mid-1970s, the mbox format became standard, storing all messages for a user in a single file, often located in /var/mail/user or /var/spool/mail/user, as seen in Version 6 AT&T Unix and subsequent releases.[27] This single-file structure, where messages are delimited by lines starting with "From ", persisted into the 1980s and influenced modern local storage practices.[28] Common use cases for local storage boxes include offline-capable email clients like Mozilla Thunderbird, which downloads messages from servers and stores them locally in mbox or Maildir formats within the user's profile folder, enabling review and composition without network connectivity.[25] Other clients, such as those on Unix-like systems, continue to use /var/mail for spool files holding incoming mail until users retrieve it via tools like mailx.[24] A key advantage of local storage boxes is the full user control over data, allowing offline access and operation independent of internet availability or server status.[29] However, a significant disadvantage is the risk of permanent data loss if the device fails, is lost, or experiences hardware issues without proper backups.[30]Server-Based Boxes
Server-based email boxes provide centralized storage for email messages on remote servers, enabling users to maintain their mailboxes independently of local devices. In the Internet Mail Architecture, these boxes function as Message Stores (MS) where incoming emails are deposited by Mail Delivery Agents (MDAs) after transfer via Mail Transfer Agents (MTAs).[31] This server-centric model contrasts with local storage by keeping data persistently available on the host infrastructure, as seen in consumer services like Gmail and enterprise platforms such as Microsoft Exchange.[32][33] Key features of server-based boxes include multi-device access, where users can retrieve and manage emails from any compatible Mail User Agent (MUA) over the network, supporting seamless synchronization across desktops, smartphones, and web browsers.[31] Automatic backups are integral, with providers implementing redundant storage to safeguard against data loss from hardware failures or deletions, often retaining copies for extended periods.[34] Scalability allows these systems to accommodate growing volumes, distributing load across clustered servers to support organizational or global user bases without performance degradation.[33] In modern email services, server-based boxes underpin the processing of vast traffic, with an estimated 376 billion messages sent and received daily worldwide as of 2025.[35] Providers like Microsoft Exchange, first released in 1996 as an evolution from earlier Microsoft Mail systems, have been pivotal in enterprise environments since the late 1990s, enabling reliable handling of high-volume communications integrated with tools like calendars and contacts.[33] Unique security implications arise from the centralized nature of server-based boxes, particularly in shared hosting setups where multiple mailboxes reside on the same infrastructure, increasing the potential for lateral movement by attackers if one account is breached.[36] Compromised servers can expose aggregated user data, amplifying risks of unauthorized access or credential theft compared to isolated local storage.[37]Access Mechanisms
Retrieval and Reading
Email retrieval from a server-based email box primarily relies on two standard protocols: Post Office Protocol version 3 (POP3) and Internet Message Access Protocol version 4 (IMAP4). POP3, first specified in RFC 1081 in 1988 and later updated in RFC 1939 in 1996, enables clients to download messages to local storage, typically deleting them from the server after retrieval to free up space. In contrast, IMAP4, originating from development in 1986 and first documented in RFC 1064 in 1988 with its current revision in RFC 9051 in 2023, supports synchronized access where messages remain on the server, allowing multi-device viewing and manipulation without mandatory deletion.[9] This distinction makes POP3 suitable for single-device, offline-focused setups, while IMAP4 facilitates real-time collaboration across clients.[9] The retrieval process begins with the client establishing a TCP connection to the server—typically on port 110 (or 995 for TLS-encrypted connections) for POP3 or 143 (or 993 for TLS-encrypted connections) for IMAP4—followed by authentication using a username and password or more secure methods like SASL.[9] Upon successful authentication, the client issues commands to list available messages, often using unique identifiers (UIDs) for precise referencing; UIDs remain constant for a message's lifetime within a mailbox's validity period, preventing duplication or loss during sessions.[9] The client then selects specific messages for download via commands like RETR in POP3 or FETCH in IMAP4, retrieving headers, body, or attachments as needed.[9] In IMAP4, this process supports partial fetches to optimize bandwidth, such as retrieving only message envelopes initially.[9] IMAP4 includes advanced reading features not native to POP3, enhancing user interaction with the email box. The SEARCH command allows server-side querying of messages by criteria like sender, date, or keywords, reducing client-side processing.[9] Sorting is enabled through the SORT extension (RFC 5256), which orders messages by attributes such as arrival time or subject before transmission.[38] Threading, which groups related messages into conversations based on references and in-reply-to headers, is supported via the THREAD extension in the same RFC, improving readability of discussion chains.[38] Additionally, folder subscriptions via the SUBSCRIBE command let clients specify which mailboxes to monitor, streamlining navigation in complex hierarchies without listing all server folders.[9] In multi-client environments, synchronization conflicts can arise, particularly with IMAP4, where concurrent modifications—like flag changes (e.g., read/unread status)—may not propagate consistently if clients operate offline or during UIDVALIDITY shifts, potentially leading to duplicate views or lost updates.[9] POP3 exacerbates this by downloading messages unilaterally, often resulting in desynchronized copies across devices unless server retention is explicitly configured. These issues are mitigated through UID-based tracking and periodic full synchronizations, but require client-server compatibility with extensions like CONDSTORE (RFC 7162) for reliable flag and state handling.Composition and Sending
Email composition typically occurs within a mail user agent (MUA), where users draft messages including subject, body, attachments, and recipients before submission. The MUA submits the composed message to a mail submission agent (MSA) using the Simple Mail Transfer Protocol (SMTP), as defined in RFC 5321, which handles the initial transport.[15] The MSA then relays the message via SMTP to the recipient's mail delivery agent (MDA), which appends it to the recipient's email box, ensuring delivery or reporting failures through non-delivery reports.[15][31] For the sender, write access involves the MUA retaining a copy of the sent message by appending it to a designated "Sent" folder in the email box, commonly using the IMAP APPEND command to add the full message literal, including optional flags like \Seen for immediate marking as read.[9] This process occurs post-submission to maintain records of outbound communications within the user's message store.[31] Deleting or archiving messages provides further write capabilities; deletion sets the \Deleted flag via the IMAP STORE command, followed by EXPUNGE to permanently remove marked items, while archiving relocates messages to alternative folders without immediate erasure.[9] Folder management enhances organization during outbound workflows, allowing users to create subfolders with the IMAP CREATE command for categorizing sent or archived items, such as project-specific directories.[9] Messages can be moved between folders using the COPY command to duplicate content followed by DELETE from the source, or directly via the UID MOVE extension for atomic operations that avoid data loss during transfer.[9][39] Integration with address books streamlines composition by enabling auto-completion and resolution of recipient email addresses, often through directory services like LDAP in enterprise MUAs. Auto-replies specific to write workflows, such as out-of-office responders, are configured within the MUA to automatically generate and send responses from the user's box upon detecting certain triggers, incorporating headers like Auto-Submitted: auto-replied to prevent response loops and limiting replies to once per sender within a reasonable period, typically seven days.[31][40]Storage and Limits
Data Formats
Email boxes store messages in various data formats that define how content is organized on disk or in databases. The two most common formats are mbox and Maildir, each with distinct structures suited to different storage needs.[41][42] The mbox format, originating in the 1970s on UNIX-like systems, stores all messages in a single file by appending new ones sequentially.[41] Each message begins with a separator line starting "From " followed by the sender's address and a UTC timestamp, and ends with an empty line; the first message uses one such separator, while subsequent ones are preceded by two end-of-line sequences plus the separator.[41] This linear structure allows simple appending but requires file locking to prevent corruption during concurrent access.[41] In contrast, the Maildir format, introduced in the mid-1990s by the Qmail mail server, uses a directory-based approach for better concurrency support.[42] A mailbox consists of a main directory (e.g.,$HOME/[Maildir](/page/Maildir)) with three subdirectories: tmp/ for temporary delivery, new/ for unseen messages, and cur/ for viewed ones; each message is a separate file with a unique name in the format time.MusecPpid.host,S=size (or similar variants ensuring uniqueness via timestamp, process ID, hostname, and delivery size).[42] Folders are subdirectories prefixed with a period (e.g., .Sent), each replicating the tmp/, new/, and cur/ structure, eliminating the need for locks as operations use atomic file renames.[42]
Regardless of the overall format, individual email messages follow a standardized structure defined by RFC 5322 for headers and MIME for the body.[43][44] Key headers include From, which lists the author(s) as mailbox specifications (e.g., "From: John Doe [email protected]"); To, specifying primary recipients (e.g., "To: Jane [email protected]"); and Date, indicating transmission time in a formatted string (e.g., "Date: Mon, 10 Nov 2025 12:00:00 +0000").[43] The body follows these headers, separated by a blank line, and uses MIME (Multipurpose Internet Mail Extensions) to encode content, supporting non-ASCII text via character sets and attachments through multipart structures delimited by boundaries (e.g., Content-Type: multipart/mixed with base64-encoded files).[44] Indexing, often via separate files or embedded metadata, enables quick searches and access without parsing entire messages.[45]
Converting between formats like mbox and Maildir is common for migrations, using tools such as mb2md, which reads mbox files from a directory and generates corresponding Maildir structures while preserving headers and adapting to conventions like those in Dovecot or Courier IMAP.[46] However, compatibility issues can arise, such as mismatched folder hierarchies or loss of flags (e.g., read/unread status) if the tool does not fully support extensions like Maildir++.[46]
Over time, email storage has evolved from simple flat files like mbox to more efficient directory-based systems like Maildir, and further to indexed formats in modern servers such as Dovecot's mdbox, which optimizes Maildir by grouping messages into fewer files with dedicated index databases for faster retrieval.[45]