Q6. How email works
1. There are totally six steps of sending a email.
2. The email format
The email format is design by David Crocker.
The format of Internet e-mail messages is defined in RFC 2822 and a series of RFCs, RFC 2045 through RFC 2049, collectively called Multipurpose Internet Mail Extensions (MIME). Although as of July 13, 2005 (see [4]) RFC 2822 is technically a proposed IETF standard and the MIME RFCs are draft IETF standards, these documents are the de facto standards for the format of Internet e-mail. Prior to the introduction of RFC 2822 in 2001 the format described by RFC 822 was the de facto standard for Internet e-mail for nearly two decades; it is still the official IETF standard. The IETF reserved the numbers 2821 and 2822 for the updated versions of RFC 821 (SMTP) and RFC 822, honoring the extreme importance of these two RFCs. RFC 822 was published in 1982 and based on the earlier RFC 733.
Internet e-mail messages consist of two major sections:
* Header - Structured into fields such as summary, sender, receiver, and other information about the e-mail
* Body - The message itself as unstructured text; sometimes containing a signature block at the end
The header is separated from the body by a blank line.
Email Header
The message header consists of fields. Each header field has a name and a value. RFC 2822 specifies the precise syntax. Informally, the field name starts in the first character of a line, followed by a ":", followed by the value which is continued on non-null subsequent lines that have a space or tab as their first character. Field names and values are restricted to 7-bit ASCII characters. Non-ASCII values may be represented using MIME encoded words. Messages usually have at least four fields in the header:
1. From: The e-mail address, and optionally name, of the sender of the message
2. To: The e-mail addresses, and optionally names, of the receiver of the message
3. Subject: A brief summary of the contents of the message
4. Date: The local time and date when the message was originally sent
Note however that the "To" field in the header is not necessarily related to the addresses to which the e-mail is delivered. The actual delivery list is supplied in the SMTP protocol, not extracted from the header content. The "To" field is similar to the greeting at the top of a conventional letter which is delivered according to the address on the outer envelope. Also note that the "From" field does not have to be the real sender of the e-mail. It is very easy to fake the "From" field and let an e-mail seem to be from any mail address. It is possible to digitally sign an e-mail, which is much harder to fake. Some Internet service providers do not relay e-mails claiming to come from a domain not hosted by them, but very few (if any) check to make sure that the person or even e-mail address named in the "From" field is the one associated with the connection.
Other common header fields include:
1. Cc: Carbon copy (because typewriters use carbon paper to make copies of letters)
2. Received: Tracking information generated by mail servers that have previously handled a message
3. Content-Type: Information about how the message has to be displayed, usually a MIME type
Many e-mail clients present "Bcc" (Blind carbon copy, recipients not visible in the "To" field) as a header field. Since the entire header is visible to all recipients, "Bcc" is not included in the message header. Addresses added as "Bcc" are only added to the SMTP delivery list, and do not get included in the message data.
3.
Simple Mail Transfer Protocol(SMTP)
SMTP is a relatively simple, text-based protocol, where one or more recipients of a message are specified (and in most cases verified to exist) and then the message text is transferred. It is quite easy to test a SMTP server using the telnet program (see below).
SMTP uses TCP port 25. To determine the SMTP server for a given domain name, the MX (Mail eXchange) DNS record is used.
SMTP started becoming widely used in the early 1980s. At the time, it was a complement to UUCP which was better suited to handle e-mail transfers between machines that were intermittently connected. SMTP, on the other hand, works best when both the sending and receiving machines are connected to the network all the time.
The article about sender rewriting contains technical background info about the early SMTP history and source routing before RFC 1123 (1989, obsoleted by RFC 2821 ).
Sendmail was one of the first (if not the first) mail transfer agents to implement SMTP. As of 2001 there are at least 50 programs that implement SMTP as a client (sender of messages) or a server (receiver of messages). Some other popular SMTP server programs include exim, Postfix, qmail, and Microsoft Exchange Server.
Since this protocol started out as purely ASCII text-based, it did not deal well with binary files. Standards such as MIME were developed to encode binary files for transfer through SMTP. Today, most SMTP servers support the 8BITMIME extension, permitting binary files to be transmitted almost as easily as plain text.
SMTP is a "push" protocol that does not allow one to "pull" messages from a remote server on demand. To do this a mail client must use POP3 or IMAP. Another SMTP server can trigger a delivery in SMTP using ETRN.
Multipurpose Internet Mail Extensions(MIME)
The basic Internet e-mail transmission protocol, SMTP, supports only 7-bit ASCII characters (see also 8BITMIME). This effectively limits Internet e-mail to messages which, when transmitted, include only the characters sufficient for writing a small number of languages, primarily English. Other languages based on the Latin alphabet typically include diacritics not supported in 7-bit ASCII, meaning text in these languages cannot be correctly represented in basic e-mail.
MIME defines mechanisms for sending other kinds of information in e-mail, including text in languages other than English using character encodings other than ASCII as well as 8-bit binary content such as files containing images, sounds, movies, and computer programs. MIME is also a fundamental component of communication protocols such as HTTP, which requires that data be transmitted in the context of e-mail-like messages, even though the data may not actually be e-mail.
Mapping messages into and out of MIME format is typically done automatically by an e-mail client or by mail servers when sending or receiving Internet (SMTP/MIME) e-mail.
The basic format of Internet e-mail is defined in RFC 2822, which is an updated version of RFC 822. These standards specify the familiar formats for text e-mail headers and body and rules pertaining to commonly used header fields such as "To:", "Subject:", "From:", and "Date:". MIME defines a collection of e-mail headers for specifying additional attributes of a message including content type, and defines a set of transfer encodings which can be used to represent 8-bit binary data using characters from the 7-bit ASCII character set. MIME also specifies rules for encoding non-ASCII characters in e-mail message headers, such as "Subject:", allowing these header fields to contain non-English characters.
MIME is extensible. Its definition includes a method to register new content types and other MIME attribute values.
One of the explicit goals of the MIME definition was to not require changes to pre-existing e-mail servers, and to allow plain text e-mail to function in both directions with pre-existing clients. This goal is achieved by allowing all MIME message attributes to be optional, with default values making a non-MIME message likely to be interpreted correctly by a MIME-capable client. In addition, a simple MIME text message is likely to be interpreted correctly by a non-MIME client although it has e-mail headers the non-MIME client won't know how to interpret. Similarly, if the quoted printable transfer encoding (see below) is used, the ascii parts of the message will be intelligible to users with non-mime clients.
Whatis MUA & MTA?
mail user agent [MUA]) is a computer program that is used to read and send e-mail.
Originally, the MUA was intended to be just a little program to read the messages, which the MDA in conjunction with the MTA would transfer into a local mailbox.
The most important mailbox formats are mbox and Maildir. These rather simple protocols for locally storing e-mails make import, export and backup of mailfolders quite easy.
E-mails to be sent would be handed over to the MTA (perhaps via an MSA), therefore an MUA would not have to provide any transport-related functions.
Since the various Windows versions intended for home use never provided an MTA, most modern MUAs have to support protocols like POP3 and IMAP to comunicate with a remote MTA located at the e-mail providers machine.
IMAP and the updated IMAP4 are optimized for storage of e-mail on the server, while the POP3 protocol generally assumes that the e-mail is downloaded to the client. The SMTP protocol is used by most e-mail clients to send e-mail.
In addition to the fat client e-mail clients (or small MUAs in cooperation with a local MDA/MTA) presented here, there are also Web-based e-mail programs ("webmail").
An important standard supported by most e-mail clients is MIME, which is used to send binary attachments. Attachments are files that are not part of the e-mail proper, but are sent with the e-mail.
MAPI (Messaging Application Programming Interface) is a proprietary Microsoft Windows API which can be used to access the Microsoft Exchange e-mail server or to interact with the Microsoft Outlook client.
Javamail, part of the platform-independent Java API, can be used to develop e-mail clients or servers using any of the standard e-mail protocols.
MTA
A mail transfer agent or MTA (also called a mail transport agent, mail server, or a mail exchange server in the context of the Domain Name System) is a computer program or software agent that transfers electronic mail messages from one computer to another.
It receives messages from another MTA (relaying), a mail submission agent (MSA) that itself got the mail from a mail user agent (MUA), or directly from an MUA, thus acting as an MSA itself. The MTA works behind the scenes, while the user usually interacts with the MUA.
The delivery of e-mail to a user's mailbox typically takes place via a mail delivery agent (MDA); many MTAs have basic MDA functionality built in, but a dedicated MDA like procmail can provide more sophistication.
2. The email format
The email format is design by David Crocker.
The format of Internet e-mail messages is defined in RFC 2822 and a series of RFCs, RFC 2045 through RFC 2049, collectively called Multipurpose Internet Mail Extensions (MIME). Although as of July 13, 2005 (see [4]) RFC 2822 is technically a proposed IETF standard and the MIME RFCs are draft IETF standards, these documents are the de facto standards for the format of Internet e-mail. Prior to the introduction of RFC 2822 in 2001 the format described by RFC 822 was the de facto standard for Internet e-mail for nearly two decades; it is still the official IETF standard. The IETF reserved the numbers 2821 and 2822 for the updated versions of RFC 821 (SMTP) and RFC 822, honoring the extreme importance of these two RFCs. RFC 822 was published in 1982 and based on the earlier RFC 733.
Internet e-mail messages consist of two major sections:
* Header - Structured into fields such as summary, sender, receiver, and other information about the e-mail
* Body - The message itself as unstructured text; sometimes containing a signature block at the end
The header is separated from the body by a blank line.
Email Header
The message header consists of fields. Each header field has a name and a value. RFC 2822 specifies the precise syntax. Informally, the field name starts in the first character of a line, followed by a ":", followed by the value which is continued on non-null subsequent lines that have a space or tab as their first character. Field names and values are restricted to 7-bit ASCII characters. Non-ASCII values may be represented using MIME encoded words. Messages usually have at least four fields in the header:
1. From: The e-mail address, and optionally name, of the sender of the message
2. To: The e-mail addresses, and optionally names, of the receiver of the message
3. Subject: A brief summary of the contents of the message
4. Date: The local time and date when the message was originally sent
Note however that the "To" field in the header is not necessarily related to the addresses to which the e-mail is delivered. The actual delivery list is supplied in the SMTP protocol, not extracted from the header content. The "To" field is similar to the greeting at the top of a conventional letter which is delivered according to the address on the outer envelope. Also note that the "From" field does not have to be the real sender of the e-mail. It is very easy to fake the "From" field and let an e-mail seem to be from any mail address. It is possible to digitally sign an e-mail, which is much harder to fake. Some Internet service providers do not relay e-mails claiming to come from a domain not hosted by them, but very few (if any) check to make sure that the person or even e-mail address named in the "From" field is the one associated with the connection.
Other common header fields include:
1. Cc: Carbon copy (because typewriters use carbon paper to make copies of letters)
2. Received: Tracking information generated by mail servers that have previously handled a message
3. Content-Type: Information about how the message has to be displayed, usually a MIME type
Many e-mail clients present "Bcc" (Blind carbon copy, recipients not visible in the "To" field) as a header field. Since the entire header is visible to all recipients, "Bcc" is not included in the message header. Addresses added as "Bcc" are only added to the SMTP delivery list, and do not get included in the message data.
3.
Simple Mail Transfer Protocol(SMTP)
SMTP is a relatively simple, text-based protocol, where one or more recipients of a message are specified (and in most cases verified to exist) and then the message text is transferred. It is quite easy to test a SMTP server using the telnet program (see below).
SMTP uses TCP port 25. To determine the SMTP server for a given domain name, the MX (Mail eXchange) DNS record is used.
SMTP started becoming widely used in the early 1980s. At the time, it was a complement to UUCP which was better suited to handle e-mail transfers between machines that were intermittently connected. SMTP, on the other hand, works best when both the sending and receiving machines are connected to the network all the time.
The article about sender rewriting contains technical background info about the early SMTP history and source routing before RFC 1123 (1989, obsoleted by RFC 2821 ).
Sendmail was one of the first (if not the first) mail transfer agents to implement SMTP. As of 2001 there are at least 50 programs that implement SMTP as a client (sender of messages) or a server (receiver of messages). Some other popular SMTP server programs include exim, Postfix, qmail, and Microsoft Exchange Server.
Since this protocol started out as purely ASCII text-based, it did not deal well with binary files. Standards such as MIME were developed to encode binary files for transfer through SMTP. Today, most SMTP servers support the 8BITMIME extension, permitting binary files to be transmitted almost as easily as plain text.
SMTP is a "push" protocol that does not allow one to "pull" messages from a remote server on demand. To do this a mail client must use POP3 or IMAP. Another SMTP server can trigger a delivery in SMTP using ETRN.
Multipurpose Internet Mail Extensions(MIME)
The basic Internet e-mail transmission protocol, SMTP, supports only 7-bit ASCII characters (see also 8BITMIME). This effectively limits Internet e-mail to messages which, when transmitted, include only the characters sufficient for writing a small number of languages, primarily English. Other languages based on the Latin alphabet typically include diacritics not supported in 7-bit ASCII, meaning text in these languages cannot be correctly represented in basic e-mail.
MIME defines mechanisms for sending other kinds of information in e-mail, including text in languages other than English using character encodings other than ASCII as well as 8-bit binary content such as files containing images, sounds, movies, and computer programs. MIME is also a fundamental component of communication protocols such as HTTP, which requires that data be transmitted in the context of e-mail-like messages, even though the data may not actually be e-mail.
Mapping messages into and out of MIME format is typically done automatically by an e-mail client or by mail servers when sending or receiving Internet (SMTP/MIME) e-mail.
The basic format of Internet e-mail is defined in RFC 2822, which is an updated version of RFC 822. These standards specify the familiar formats for text e-mail headers and body and rules pertaining to commonly used header fields such as "To:", "Subject:", "From:", and "Date:". MIME defines a collection of e-mail headers for specifying additional attributes of a message including content type, and defines a set of transfer encodings which can be used to represent 8-bit binary data using characters from the 7-bit ASCII character set. MIME also specifies rules for encoding non-ASCII characters in e-mail message headers, such as "Subject:", allowing these header fields to contain non-English characters.
MIME is extensible. Its definition includes a method to register new content types and other MIME attribute values.
One of the explicit goals of the MIME definition was to not require changes to pre-existing e-mail servers, and to allow plain text e-mail to function in both directions with pre-existing clients. This goal is achieved by allowing all MIME message attributes to be optional, with default values making a non-MIME message likely to be interpreted correctly by a MIME-capable client. In addition, a simple MIME text message is likely to be interpreted correctly by a non-MIME client although it has e-mail headers the non-MIME client won't know how to interpret. Similarly, if the quoted printable transfer encoding (see below) is used, the ascii parts of the message will be intelligible to users with non-mime clients.
Whatis MUA & MTA?
mail user agent [MUA]) is a computer program that is used to read and send e-mail.
Originally, the MUA was intended to be just a little program to read the messages, which the MDA in conjunction with the MTA would transfer into a local mailbox.
The most important mailbox formats are mbox and Maildir. These rather simple protocols for locally storing e-mails make import, export and backup of mailfolders quite easy.
E-mails to be sent would be handed over to the MTA (perhaps via an MSA), therefore an MUA would not have to provide any transport-related functions.
Since the various Windows versions intended for home use never provided an MTA, most modern MUAs have to support protocols like POP3 and IMAP to comunicate with a remote MTA located at the e-mail providers machine.
IMAP and the updated IMAP4 are optimized for storage of e-mail on the server, while the POP3 protocol generally assumes that the e-mail is downloaded to the client. The SMTP protocol is used by most e-mail clients to send e-mail.
In addition to the fat client e-mail clients (or small MUAs in cooperation with a local MDA/MTA) presented here, there are also Web-based e-mail programs ("webmail").
An important standard supported by most e-mail clients is MIME, which is used to send binary attachments. Attachments are files that are not part of the e-mail proper, but are sent with the e-mail.
MAPI (Messaging Application Programming Interface) is a proprietary Microsoft Windows API which can be used to access the Microsoft Exchange e-mail server or to interact with the Microsoft Outlook client.
Javamail, part of the platform-independent Java API, can be used to develop e-mail clients or servers using any of the standard e-mail protocols.
MTA
A mail transfer agent or MTA (also called a mail transport agent, mail server, or a mail exchange server in the context of the Domain Name System) is a computer program or software agent that transfers electronic mail messages from one computer to another.
It receives messages from another MTA (relaying), a mail submission agent (MSA) that itself got the mail from a mail user agent (MUA), or directly from an MUA, thus acting as an MSA itself. The MTA works behind the scenes, while the user usually interacts with the MUA.
The delivery of e-mail to a user's mailbox typically takes place via a mail delivery agent (MDA); many MTAs have basic MDA functionality built in, but a dedicated MDA like procmail can provide more sophistication.
posted by Calvinica at 2:47 AM
0 Comments:
Post a Comment
<< Home