- Data Comm & Networks Home
- DCN - Overview
- DCN - What is Computer Network
- DCN - Uses of Computer Network
- DCN - Computer Network Types
- DCN - Network LAN Technologies
- DCN - Computer Network Models
- DCN - Computer Network Security
- DCN - Components
- DCN - Connectors
- DCN - Switches
- DCN - Repeaters
- DCN - Gateways
- DCN - Bridges
- DCN - Socket
- DCN - Network Interface Card
- DCN - NIC: Pros and Cons
- DCN - Network Hardware
- DCN - Network Port
- Computer Network Topologies
- DCN - Computer Network Topologies
- DCN - Point-to-point Topology
- DCN - Bus Topology
- DCN - Star Topology
- DCN - Ring Topology
- DCN - Mesh Topology
- DCN - Tree Topology
- DCN - Hybrid Topology
- Physical Layer
- DCN - Physical Layer Introduction
- DCN - Digital Transmission
- DCN - Analog Transmission
- DCN - Transmission media
- DCN - Wireless Transmission
- DCN - Transmission Impairments
- DCN - Multiplexing
- DCN - Network Switching
- Data Link Layer
- DCN - Data Link Layer Introduction
- DCN - Data Link Control & Protocols
- DCN - RMON
- DCN - Token Ring Network
- DCN - Hamming Code
- DCN - Byte Stuffing
- DCN - Channel Allocation
- DCN - MAC Address
- DCN - Cyclic Redundancy Checks
- DCN - Error Control
- DCN - Flow Control
- DCN - Framing
- DCN - Error Detection & Correction
- DCN - Error Correcting Codes
- DCN - Parity Bits
- Network Layer
- DCN - Network Layer Introduction
- DCN - Network Addressing
- DCN - Routing
- DCN - Internetworking
- DCN - Network Layer Protocols
- DCN - Routing Information Protocol
- DCN - Border Gateway Protocol
- DCN - OSPF Protocol
- DCN - Network Address Translation
- DCN - Network Address Translation Types
- Transport Layer
- DCN - Transport Layer Introduction
- DCN - Transmission Control Protocol
- DCN - User Datagram Protocol
- DCN - Congestion Control
- DCN - TCP Service Model
- DCN - TLS Handshake
- DCN - TCP Vs. UDP
- Application Layer
- DCN - Application Layer Introduction
- DCN - Client-Server Model
- DCN - Application Protocols
- DCN - Network Services
- DCN - Virtual Private Network
- DCN - Load Shedding
- DCN - Optimality Principle
- DCN - Service Primitives
- DCN - Services of Network Security
- DCN - Hypertext Transfer Protocol
- DCN - File Transfer Protocol
- DCN - Secure Socket Layer
- Network Protocols
- DCN - ALOHA Protocol
- DCN - Pure ALOHA Protocol
- DCN - Sliding Window Protocol
- DCN - Stop and Wait Protocol
- DCN - Link State Routing
- DCN - Link State Routing Protocol
- Network Algorithms
- DCN - Shortest Path Algorithm
- DCN - Routing Algorithm
- DCN - Leaky Bucket Algorithm
- Wireless Networks
- DCN - Wireless Networks
- DCN - Wireless LANs
- DCN - Wireless LAN & IEEE 802.11
- DCN - IEEE 802.11 Wireless LAN Standards
- DCN - IEEE 802.11 Networks
- Multiplexing
- DCN - Multiplexing & Its Types
- DCN - Time Division Multiplexing
- DCN - Synchronous TDM
- DCN - Asynchronous TDM
- DCN - Synchronous Vs. Asynchronous TDM
- DCN - Frequency Division Multiplexing
- DCN - TDM Vs. FDM
- DCN - Code Division Multiplexing
- DCN - Wavelength Division Multiplexing
- Miscellaneous
- DCN - Shortest Path Routing
- DCN - B-ISDN Reference Model
- DCN - Design Issues For Layers
- DCN - Selective-repeat ARQ
- DCN - Flooding
- DCN - E-Mail Format
- DCN - Cryptography
- DCN - Unicast, Broadcast, & Multicast
- DCN - Network Virtualization
- DCN - Flow Vs. Congestion Control
- DCN - Asynchronous Transfer Mode
- DCN - ATM Networks
- DCN - Synchronous Vs. Asynchronous Transmission
- DCN - Network Attacks
- DCN - WiMax
- DCN - Buffering
- DCN - Authentication
- DCN Useful Resources
- DCN - Quick Guide
- DCN - Useful Resources
E-Mail Format in Computer Networks
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
E-mail Envelope
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.
Message
The actual message inside the envelope is made of two parts
- Header
- Body
The header carries the control information while the Body contains the message contents. The envelope and messages are shown in the figure below
Message Formats
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 users 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
| Header | Meaning |
|---|---|
| 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 To field
The field gives the DNS address of the primary recipient. It is allowed to have multiple recipients.
The Cc field
This field gives the addresses of any secondary recipients.
The Bcc
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.
From and Sender fields
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.
Received field
A-line containing the Received field is added by each message transfer agent along the way. This line carries the agents 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 Return-Path field
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.
Other header fields
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 :
| Header | Meaning |
|---|---|
| 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.
Message Body
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.