E-mail is represented as the transmission of messages on the Internet. It is one of the most commonly used features over communications networks containing text, files, images, or other attachments.
Format of E-mail− An e-mail includes three parts that are as follows−
In modern e-mail systems, there is a distinction made between the e-mail and its contents. An e-mail envelope contains the message, destination Address, Priority security level etc. The message transport agents use this envelope for routing.
The actual message inside the envelope is made of two parts
The header carries the control information while the Body contains the message contents. The envelope and messages are shown in the figure below −
Let us understand the RFC 822 message format in an email.
Messages consist of a primitive envelope, some header fields and a blank line, and the message body. Each header field logically includes a single line of ASCII text which contains the field name, a colon and a field. RFC 822 is an old standard. Usually, the user agent builds a message and passes it to be the message transfer agent with the user’s header fields to construct an envelope.
The following table shows the principal header fields related to message transport.
RFC 822 header fields related to message transport
|To −||E-mail address of primary recipients.|
|Cc −||E-mail address of secondary recipients.|
|BCC||E-mail address for blind carbon copies.|
|From −||Person who created the message.|
|Sender||E-mail address of the actual sender.|
|Received||Line inserted by each transfer agent along the route.|
|Return Patch||It can use it to identify the path to the sender.|
The field gives the DNS address of the primary recipient. It is allowed to have multiple recipients.
This field gives the addresses of any secondary recipients.
The long form of Bcc is Blind Carbon Copy. This field is such as the Cc field, except that this is removed from all the copies shared with the primary and secondary recipients. This feature allows people to send copies to third parties without primary and secondary recipients knowing this.
These fields tell about who wrote the message and who sent the message, respectively, because the person who creates the message and the person who sends it can be different.
The from the field is required, but the sender field can be omitted if it is the same as the one from the field. These fields are required in case the message is undeliverable and is to be returned to the sender.
A-line containing the Received field is added by each message transfer agent along the way. This line carries the agent’s identity, date and time at which they received the message. It also contains some other information that can be used to find bugs in the routing system.
The final message transfer agent adds this field, and it is predetermined to tell how to receive back to the sender. It can gather this information from all the received headers.
In addition to the field to table below, RFC 822 messages may contain various header fields used by user agents or human recipients. Many of them are shown in the table below
Some fields in RFC 822 message header are as follows :
|Date:||The date and time of the message.|
|Reply− To||The E-mail address to which the reply is to be sent.|
|Message-Id:||Message identifying number|
|In− Reply − To:||Message-Id of the message to which this is a reply.|
|References:||Other relevant messages identifying numbers.|
|Keywords:||Keywords chosen by users.|
|Subject:||Summary of the message for the one-line display.|
The RFC 822 allows the users to invent new headers for their private use, but these headers must start with the string X − Event of the week.
The message body comes after the header. The users can put whatever they want to send in the message body. It is possible to terminate the messages with ASCII cartoons, quotations, and political statements.