TerminologyPrior to the spread of electronic mail services, the word ''email'', here derived from the French word ''émail'', primarily referred to or sometimes . A rare term, it was mainly used by art historians and medievalists. Historically, the term ''electronic mail'' is any electronic document transmission. For example, several writers in the early 1970s used the term to refer to document transmission. As a result, finding its first use is difficult with the specific meaning it has today. The term ''electronic mail'' has been in use with its current meaning since at least 1975, and variations of the shorter ''E-mail'' have been in use since at least 1979: * ''email'' is now the common form, and recommended by s. It is the form required by (RFC) and working groups. This spelling also appears in most dictionaries.Random House Unabridged Dictionary, 2006The American Heritage Dictionary of the English Language, Fourth EditionPrinceton University WordNet 3.0The American Heritage Science Dictionary, 2002 * ''e-mail'' is the form favored in edited published American English and British English writing as reflected in the data, but is falling out of favor in some style guides. * ''EMail'' is a traditional form used in RFCs for the "Author's Address" and is required "for historical reasons". * ''E-mail'' is sometimes used, capitalizing the initial ''E'' as in similar abbreviations like '' '', '' '', '' '', and '' ''. In the original protocol, ''RFC 524'', none of these forms was used. The service is simply referred to as ''mail'', and a single piece of electronic mail is called a ''message''. An Internet email consists of an envelope and content; the content consists of a header and a body.
OriginComputer-based mail and messaging became possible with the advent of computers in the early 1960s, and informal methods of using shared files to pass messages were soon expanded into the first mail systems. Most developers of early mainframes and minicomputers developed similar, but generally incompatible, mail applications. Over time, a complex web of gateways and routing systems linked many of them. Many US universities were part of the ARPANET (created in the late 1960s), which aimed at between its systems. In 1971 the first ARPANET network email was sent, introducing the now-familiar address syntax with the '@' symbol designating the user's system address. The (SMTP) protocol was introduced in 1981. For a time in the late 1980s and early 1990s, it seemed likely that either a proprietary commercial system or the email system, part of the (GOSIP), would predominate. However, once the final restrictions on carrying commercial traffic over the Internet ended in 1995, a combination of factors made the current Internet suite of SMTP, and email protocols the standard.
OperationThe following is a typical sequence of events that takes place when sender transmits a message using a (MUA) addressed to the of the recipient. # The MUA formats the message in email format and uses the submission protocol, a profile of the (SMTP), to send the message content to the local (MSA), in this case ''smtp.a.org''. # The MSA determines the destination address provided in the SMTP protocol (not from the message header) — in this case, ''email@example.com'' — which is a fully qualified domain address (FQDA). The part before the @ sign is the ''local part'' of the address, often the of the recipient, and the part after the @ sign is a . The MSA resolves a domain name to determine the of the in the (DNS). # The for the domain ''b.org'' (''ns.b.org'') responds with any s listing the mail exchange servers for that domain, in this case ''mx.b.org'', a (MTA) server run by the recipient's ISP. # smtp.a.org sends the message to mx.b.org using SMTP. This server may need to forward the message to other MTAs before the message reaches the final (MDA). # The MDA delivers it to the mailbox of user ''bob''. # Bob's MUA picks up the message using either the (POP3) or the (IMAP). In addition to this example, alternatives and complications exist in the email system: * Alice or Bob may use a client connected to a corporate email system, such as or . These systems often have their own internal email format and their clients typically communicate with the email server using a vendor-specific, proprietary protocol. The server sends or receives email via the Internet through the product's Internet mail gateway which also does any necessary reformatting. If Alice and Bob work for the same company, the entire transaction may happen completely within a single corporate email system. * Alice may not have an MUA on her computer but instead may connect to a service. * Alice's computer may run its own MTA, so avoiding the transfer at step 1. * Bob may pick up his email in many ways, for example logging into mx.b.org and reading it directly, or by using a webmail service. * Domains usually have several mail exchange servers so that they can continue to accept mail even if the primary is not available. Many MTAs used to accept messages for any recipient on the Internet and do their best to deliver them. Such MTAs are called '' s''. This was very important in the early days of the Internet when network connections were unreliable. However, this mechanism proved to be exploitable by originators of unsolicited bulk email and as a consequence open mail relays have become rare, and many MTAs do not accept messages from open mail relays.
Message formatThe basic Internet message format used for email is defined by RFC 5322, with encoding of non-ASCII data and multimedia content attachments defined in RFC 2045 through RFC 2049, collectively called '' '' or ''MIME''. The extensions in apply only to email. RFC 5322 replaced the earlier RFC 2822 in 2008, then RFC 2822 in 2001 replaced RFC 822 – the standard for Internet email for decades. Published in 1982, RFC 822 was based on the earlier RFC 733 for the ARPANET. Internet email messages consist of two sections, 'header' and 'body'. These are known as 'content'. The header is structured into such as From, To, CC, Subject, Date, and other information about the email. In the process of transporting email messages between systems, SMTP communicates delivery parameters and information using message header fields. The body contains the message, as unstructured text, sometimes containing a at the end. The header is separated from the body by a blank line.
Message headerRFC 5322 specifies the of the email header. Each email message has a (the "header section" of the message, according to the specification), comprising a number of ("header fields"). Each field has a name ("field name" or "header field name"), followed by the separator character ":", and a value ("field body" or "header field body"). Each field name begins in the first character of a new line in the header section, and begins with a non- printable character. It ends with the separator character ":". The separator is followed by the field value (the "field body"). The value can continue onto subsequent lines if those lines have space or tab as their first character. Field names and, without , field bodies are restricted to 7-bit ASCII characters. Some non-ASCII values may be represented using MIME encoded words.
Header fieldsEmail header fields can be multi-line, with each line recommended to be no more than 78 characters, although the limit is 998 characters. Header fields defined by RFC 5322 contain only characters; for encoding characters in other sets, a syntax specified in RFC 2047 may be used. In some examples, the IETF EAI working group defines some standards track extensions, replacing previous experimental extensions so encoded characters may be used within the header. In particular, this allows email addresses to use non-ASCII characters. Such addresses are supported by Google and Microsoft products, and promoted by some government agents. The message header must include at least the following fields: * ''From'': The email address, and, optionally, the name of the author(s). Some email clients are changeable through account settings. * ''Date'': The local time and date the message was written. Like the ''From:'' field, many email clients fill this in automatically before sending. The recipient's client may display the time in the format and time zone local to them. RFC 3864 describes registration procedures for message header fields at the ; it provides fo
Content encodingInternet email was designed for 7-bit ASCII. Most email software is 8-bit clean, but must assume it will communicate with 7-bit servers and mail readers. The standard introduced character set specifiers and two content transfer encodings to enable transmission of non-ASCII data: quoted printable for mostly 7-bit content with a few characters outside that range and for arbitrary binary data. The and extensions were introduced to allow transmission of mail without the need for these encodings, but many s may not support them. In some countries, e-mail software violates by sending rawNot using Internationalized Email or MIME non-ASCII text and several encoding schemes co-exist; as a result, by default, the message in a non-Latin alphabet language appears in non-readable form (the only exception is a coincidence if the sender and receiver use the same encoding scheme). Therefore, for international s, is growing in popularity.
Plain text and HTMLMost modern graphic s allow the use of either or for the message body at the option of the user. messages often include an automatic-generated plain text copy for compatibility. Advantages of HTML include the ability to include in-line links and images, set apart previous messages in block quotes, wrap naturally on any display, use emphasis such as s and , and change styles. Disadvantages include the increased size of the email, privacy concerns about s, abuse of HTML email as a vector for attacks and the spread of . Some e-mail clients interpret the body as HTML even in the absence of a
Content-Type: htmlheader field; this may cause various problems. Some web-based s recommend all posts be made in plain-text, with 72 or 80 for all the above reasons, and because they have a significant number of readers using text-based email clients such as Mutt. Some email clients may allow rich formatting using their proprietary (RTF), but this should be avoided unless the recipient is guaranteed to have a compatible email client.
Servers and client applicationsMessages are exchanged between hosts using the with software programs called s (MTAs); and delivered to a mail store by programs called s (MDAs, also sometimes called local delivery agents, LDAs). Accepting a message obliges an MTA to deliver it, and when a message cannot be delivered, that MTA must send a back to the sender, indicating the problem. Users can retrieve their messages from servers using standard protocols such as or , or, as is more likely in a large environment, with a