Computer Networks

Answer: (i) with external access

Why: A proxy server sits between the internal clients and the outside internet, fetching resources on their behalf — so it is the computer with external access that works on behalf of internally-restricted hosts. It is not a backup machine, a file-handling server, or a permission-management host.

Answer: (i) end systems

Why: The application layer is implemented only on end systems (hosts) — protocols such as HTTP, SMTP, FTP, DNS and SNMP run directly in the communicating user processes/hosts. NIC is a network-layer-2 hardware device, Ethernet is a link/physical-layer standard, and routers/routes operate at the network layer (layer 3) — none of them implement application-layer protocols.

Answer: (i) end systems

Why: The application layer (HTTP, DNS, FTP, SMTP, …) is implemented by the communicating end hosts — the sender and receiver processes — not by network-core devices. NIC is a data-link/physical-layer device, Ethernet is a link-layer technology, and routers forward packets at the network layer, never processing application-layer content.

Answer: (ii) HTTP describes the structure of web pages

Why: HTTP is only a request/response transfer protocol; the structure (markup) of web pages is described by HTML, not by HTTP. The other statements are true — HTTP runs over TCP (port 80/443), it can carry data inside the URL/query string (iii), and status codes such as 404 Not Found can be used to test whether a hypertext link is valid (iv).

Answer: (iii) DNS query, TCP SYN, HTTP GET request

Why: The freshly restarted host has an empty DNS cache, so it must first resolve the server's name into an IP address (DNS query). It then opens a TCP connection to the server's port 80 (three-way handshake initiated by the TCP SYN) and only finally sends the HTTP GET request inside that established connection.

Answer: (i) 110

Why: POP3 (Post Office Protocol version 3) uses well-known TCP port 110 (995 for POP3 over TLS). Port 80 is HTTP, port 49 is the LOGIN host protocol, and 90 is not assigned to POP3 — so (ii), (iii) and (iv) are all wrong.

Answer: (ii) 2^16 bytes - size of TCP header

Why: A TCP segment (header + data) becomes the payload of an IP datagram, and IP's 16-bit Total Length field caps the whole packet at 2^16 = 65536 bytes — so the data the application hands down must fit into that space after the TCP header is added, i.e. 2^16 − TCP header size (65536 − 20 = 65516 bytes). Option (i) is wrong because the length is strictly bounded by that 16-bit field; option (iii) forgets that the TCP header occupies part of the same space; option (iv) 1500 bytes is only the Ethernet MTU (a link-layer limit), not the TCP/IP limit.

Answer: (i) maintains state information

Why: FTP is stateful: the server tracks the control connection, the logged-in user, the current working directory and the transfer mode. It is not stateless (HTTP, by contrast, is), it uses two TCP connections (control port 21 + data port 20) rather than a single one, and file transfer runs over TCP, never UDP.

Connectionless service is a service in which no logical connection is set up between sender and receiver before data is transferred — each packet (datagram) carries the full destination address and is routed independently of other packets.

• Packets may follow different paths and arrive out of order; ordering/reassembly is left to higher layers.
• No handshake, no reserved resources → faster, cheaper, and robust, but no guarantee of delivery, ordering or error-free transfer (e.g., IP, UDP).
• Analogous to the postal system: each letter is independently addressed and delivered.
• Contrasted with connection-oriented service, where a connection is established, data follows the same path, and the connection is released (e.g., TCP).

Answer: (ii) IMAP

Port 143 is the well-known port of IMAP (Internet Message Access Protocol), which a mail client uses to reach a mailbox on a server and download/manage messages and folders. IMAP secured with TLS uses port 993.

The other options use different standard ports: SMTP = 25 (i), FTP = 21 for the control connection and 20 for the data connection (iii), and POP3 = 110 (iv).

Answer: (ii) UDP

Why: DNS primarily uses UDP on port 53 for ordinary queries because its request/response exchanges are short and the low overhead of connectionless UDP gives fast answers. It falls back to TCP only for responses larger than 512 bytes (zone transfers, AXFR); Telnet (port 23) and HTTP (port 80) are unrelated application-layer protocols.

Answer: (i) SMTP client

Delivery of mail between mail servers uses SMTP as a push protocol. The server that has mail to send opens a TCP connection to the receiving mail server (port 25) and issues the SMTP commands - HELO/EHLO, MAIL FROM, RCPT TO, DATA - which makes it the SMTP client of that connection, while the receiving server is the SMTP server.

A mail server therefore changes role with the direction of traffic: it acts as an SMTP server when a user's mail client (or another server) connects to it to submit or deliver mail, and as an SMTP client when it forwards/relays that mail onward to the next mail server. It also runs a POP3/IMAP server so users can retrieve their mail. Peer and Master are not SMTP roles.

Answer: (i) Telnet

Why: Telnet (port 23) establishes a TCP connection that gives a text-command interface to log in and work on a remote host. FTP transfers files (not a login session), and HTTP retrieves web pages — neither provides remote terminal login.

DNS over UDP: Does Packet Loss Cause a Problem?

Short answer: Yes, a lost query or reply would stall name resolution if nothing else acted, but DNS deliberately places recovery in the application layer (the stub resolver) instead of in the transport layer, so the loss is handled without ever opening a TCP connection.

Why UDP is preferred anyway

• A lookup is normally one small request/response pair. Setting up TCP first (SYN, SYN-ACK, ACK) would add a full handshake plus teardown, roughly doubling the messages and adding 1-2 extra RTTs to every web access.
• DNS needs no long-lived stream, no ordering across messages, and each message is self-contained.
• UDP lets one name server answer thousands of clients concurrently with no per-client connection state.

How the loss is solved

1. Client retransmission with timeout (primary fix): every query is sent with a timer. If no reply arrives, the stub resolver retransmits the same query (typically after 1 s, 2 s, 4 s, ... up to 5 attempts) and finally returns SERVFAIL/time-out to the application. This is essentially stop-and-wait with timeout implemented by DNS itself.
2. Transaction ID + source-port matching: each query carries a random 16-bit ID (and is sent from an ephemeral port), so the client can match the eventual reply to the outstanding query and discard stray, duplicate or forged responses. Late duplicates are harmless because replies are idempotent.
3. TCP fallback for large responses: if an answer exceeds the message-size limit (512 bytes classically) the server sets the TC (truncation) bit and the resolver retries the same query over TCP; zone transfers (AXFR/IXFR) always use TCP. EDNS0 also allows larger UDP payloads.
4. Redundant name servers: each zone is served by at least two authoritative servers (and there are multiple root/TLD servers), so the query can simply be sent to another server.

Conclusion

Loss only costs one retransmission timeout of delay, not correctness. Reliability is recovered by application-level retries and ID matching, and by TCP whenever responses are large - so using UDP costs nothing in accuracy while saving connection setup on the critical path of every request.

FTP: The Two Connections and the File Types It Can Transfer

FTP is unusual in that it uses two separate TCP connections between client and server: one long-lived control connection and one short-lived data connection.

1. Control connection (well-known port 21)

• Established when the session starts and kept open for the whole session, closed only with QUIT.
• Carries ASCII commands and replies: USER, PASS, PWD, CWD, LIST, RETR (retrieve), STOR (store), PORT/PASV, TYPE, QUIT and the 3-digit replies (220, 200, 226, 550, ...).
• Small, interactive, one line at a time, always in ASCII mode; it controls the session, authentication and the state of the data connection.

2. Data connection (port 20 in active mode, negotiated ephemeral port in passive mode)

• Opened only for one transfer (a file, a directory listing) and closed as soon as it finishes - one data connection per RETR/STOR/LIST.
• Carries the actual file bytes or directory listing, in ASCII, EBCDIC or image (binary) mode.
• Two variants:
  • Active mode (PORT): the server initiates the connection from its port 20 to the port the client advertised.
  • Passive mode (PASV): the server opens an ephemeral port and waits; the client connects to it - preferred today because it works through client-side NAT and firewalls.
• Bulk data flows at full window size, independent of the interactive channel.

Separating the two lets the user stay logged in and issue further commands while (or between) transfers, and lets each transfer be optimised independently.

File types FTP can transfer

TYPE mode	Purpose
ASCII (A)	Text files; default - end-of-line characters are converted to/from the local convention (CRLF <-> LF)
EBCDIC (E)	Text transfer between EBCDIC mainframes
Image / Binary (I)	Byte-for-byte copy of any file: executables, images, PDFs, archives, compressed files
Local (L n)	Machine-dependent byte size between two hosts

Conclusion: because image/binary mode transfers every bit unchanged, FTP can move any kind of file; the ASCII and EBCDIC modes exist only for character-set and newline conversion between dissimilar systems.

POP3 vs IMAP4 and Delivery of E-mail

Part A — POP3 vs IMAP4

Aspect	POP3 (RFC 1939)	IMAP4 (RFC 3501)
Full form	Post Office Protocol version 3	Internet Message Access Protocol version 4
Basic model	Download-and-delete (default) or download-and-keep	Messages remain on the server; the client manipulates the server's copy
Server-side storage	Mailbox is emptied after retrieval → mail stored on one machine	All mail retained on the server; folders, flags and read state kept server-side
Client access	Effectively one client at a time (mailbox is locked)	Many clients/devices can access the same mailbox simultaneously
Operations	Simple: USER, PASS, LIST, RETR, DELE, STAT, QUIT	Rich: LOGIN, SELECT, FETCH, STORE, SEARCH, CREATE/DELETE, EXPUNGE, NOOP
Folders	Not supported (flat mailbox)	Multiple folders supported, created/deleted on the server
Partial download	No — a whole message must be fetched	Yes — headers only, byte ranges, individual MIME parts
Server-side search	No	Yes (SEARCH)
Default ports	110 (cleartext), 995 (TLS)	143 (cleartext), 993 (TLS)
Typical use	Simple offline reading, low server load	Webmail, smartphones, sync across devices
Authentication	USER/PASS (cleartext unless TLS)	LOGIN or SASL (CRAM-MD5, OAuth2, …)

Both protocols are used only to retrieve mail from the user's own mailbox; moving a message between hosts is always done by SMTP.

Part B — How Alice's message reaches Bob

Application-layer protocols used, in order: HTTPS (HTTP) → DNS → SMTP (possibly several hops) → POP3 or IMAP4.

1. Alice composes the message in her web-based account (Gmail/Hotmail). Since she uses a browser, the message is uploaded to her provider's web server using HTTP over TLS (HTTPS), port 443. (With an installed mail client she would instead submit it with SMTP on port 587.)
2. Alice's mail server (originating MTA) takes the message. Before sending, it queries DNS for Bob's domain MX record (then an A/AAAA record) to learn the address of Bob's mail exchanger — mail cannot be delivered without this lookup.
3. SMTP transfer: Alice's server opens a TCP connection to Bob's mail server on port 25 and runs SMTP — HELO/EHLO → MAIL FROM → RCPT TO → DATA → QUIT — handing over the envelope and the message. If Bob's server is down, the message is queued and retried.
4. Possible relays: the message may pass through one or more intermediate mail servers, each forwarding it with SMTP, until it reaches Bob's mail server (destination MTA), which accepts it and appends the message to Bob's mailbox.
5. Bob retrieves the mail with a mail client that logs into his own server using POP3 (110/995) or IMAP4 (143/993): USER/PASS (or LOGIN), LIST, then RETR (POP3) or FETCH (IMAP4), followed by QUIT. Under POP3 the message is normally deleted from the server after download; under IMAP4 it stays on the server.

 Alice's host        Alice's mail server      DNS server        Bob's mail server     Bob's host
 (web browser)       (webmail provider)                          (Bob's domain)        (mail client)
      |                      |                     |                     |                   |
      | 1 HTTPS (443)        |                     |                     |                   |
      |   compose + send     |                     |                     |                   |
      |--------------------->|                     |                     |                   |
      |                      | 2 DNS query: MX for bob.com              |                   |
      |                      |-------------------->|                     |                   |
      |                      | 3 MX answer: mail.bob.com                |                   |
      |                      |<--------------------|                     |                   |
      |                      | 4 SMTP (25): EHLO / MAIL FROM / RCPT TO / DATA               |
      |                      |---------------------------------------->|                   |
      |                      |                     |                     | 5 message stored  |
      |                      |                     |                     |   in Bob's mailbox|
      |                      |                     |                     |                   |
      |                      |                     |                     | 6 POP3 (110/995)  |
      |                      |                     |                     | or IMAP4 (143/993)|
      |                      |                     |                     |<------------------|

Series of application-layer protocols: HTTP/HTTPS (Alice → her provider), DNS (MX lookup), SMTP (Alice's server → Bob's server, possibly several relays), and POP3 or IMAP4 (Bob's server → Bob's client) — all carried over TCP/IP beneath them.

Name-address resolution in DNS

A client (the resolver) must convert a domain name such as www.example.com into an IP address. DNS is a hierarchical, distributed database of servers: root servers → TLD servers (.com) → authoritative servers (example.com), plus a local (recursive) DNS server of the ISP or organisation. The lookup can be done in two ways.

1. Recursive resolution

The client asks a DNS server to do the entire job. If that server does not know the answer, it contacts other servers on the client's behalf and returns only the final answer (or an error).

Client -> Local DNS: "IP of www.example.com?"
           Local DNS -> Root -> TLD -> Authoritative (chain)
           <- final IP address
Client <- Local DNS: 93.184.216.34

Characteristics:

• Burden is on the queried server; the client sends one query and gets one answer.
• The server usually caches the result, speeding up later queries.
• Client-to-local-server queries are normally recursive.

2. Iterative resolution

The client (or the local server) asks a server, and if the server cannot answer it returns a referral: the address of another server that is closer to the answer. The asker then queries that next server itself, repeating until the answer is found.

Local DNS -> Root server:  "www.example.com?"
          <- referral: ask the .com TLD server
Local DNS -> TLD server:   "www.example.com?"
          <- referral: ask ns1.example.com
Local DNS -> Authoritative: "www.example.com?"
          <- 93.184.216.34

Characteristics:

• Burden is on the requester; each server does minimal work.
• Servers reply immediately with the best information they have.
• Root and TLD servers normally answer only iteratively (to protect them from overload).

Comparison

Basis	Recursive	Iterative
Who does the work	The queried server resolves fully	The requester follows referrals itself
Reply to the requester	Final answer (or error)	Answer or a referral to another server
Load on the server	High	Low
Number of queries by the client	One	Several
Typical use	Client → local DNS server	Local DNS server → root / TLD / authoritative servers
Caching benefit	Server caches the final answers	Requester caches each step

In practice the two are combined: the host sends a recursive query to its local DNS server, which then performs iterative queries against the root, TLD, and authoritative servers and returns the final IP address to the host.

File Transfer Protocol (FTP)

1. File types FTP can transfer

FTP defines three file types so that files stored in different formats can be moved between unlike machines:

File type	Purpose / conversion
ASCII	Text files. Converted to/from the Network Standard ASCII (NVT-ASCII, 7-bit, CRLF line ends) at each end — used for editor commands and text.
EBCDIC	Mainframe (EBCDIC-coded) text. Converted to ASCII at the sending side and back to EBCDIC at the receiving side.
Image (binary)	Any file treated as an uninterpreted byte stream — copied exactly with no conversion, for executables, graphics, compressed files etc.

2. The three transmission modes

• Stream mode — data flows as a continuous stream of bytes over the TCP connection; records have no length field, the receiver must delimit them itself. Flow control is done by TCP.
• Block mode — data is cut into blocks, each preceded by a 3-byte header (block length + descriptor byte: B = beginning, I = intermediate, D = end, E = error) so the receiver knows record boundaries.
• Compressed mode — uses run-length encoding: a sequence of n identical bytes is sent as (count, byte), which suits highly repetitive data such as images.

3. Functions of the two FTP connections

	Control connection	Data connection
Ports	server 21 ↔ client ephemeral	server 20 ↔ client ephemeral
Lifetime	Opened at start, stays open for the whole session, closed at the end	Opened and closed for every data transfer (e.g. each LIST, RETR, STOR)
Carries	ASCII commands and replies (USER, RETR, STOR, response codes)	The actual file data / directory listing
Mode	Always client → server initiation	Server initiates it back to the client (active mode)

FTP is therefore an out-of-band protocol: the control connection carries instructions while the data connection carries the payload.

4. Storing a file vs retrieving a file

• Retrieving (RETR) = download: the client asks the server for a file, so data flows server → client on the data connection.
• Storing (STOR) = upload: the client sends a local file to the server, so data flows client → server on the (newly opened) data connection; the server creates or overwrites the file (STOU stores under a unique name, APPE appends).

The only difference is the direction of data flow — both use the same two-connection mechanism, and both are initiated by a command on the control connection.

Short Notes on FTP (File Transfer Protocol)

Definition. FTP is an application-layer protocol of the TCP/IP model (Layer 5 of the TCP/IP stack, Layer 7 of the OSI model), standardised in RFC 959, for copying files between a client and a server over an IP network. It supports login/authentication, directory listing, upload, download, rename and delete, and can transfer files in ASCII (text) mode or image/binary mode (also EBCDIC), with file structures of file, record or page.

Two connections. FTP is unusual in using two separate TCP connections:

• Control connection — port 21 (well-known). Carries commands and replies as 7-bit ASCII lines (USER, PASS, RETR, STOR, LIST, CWD, DELE, TYPE, PORT, PASV, QUIT) and remains open for the whole session.
• Data connection — carries the actual file bytes; opened only for each transfer and closed afterwards.

Active vs passive mode.

• Active mode: the server opens the data connection from its port 20 to an ephemeral port chosen by the client.
• Passive mode (PASV): the client opens the data connection to an ephemeral port announced by the server. Passive mode is what works through NAT/firewalls, which normally refuse inbound connection attempts.

Features. User authentication with USER/PASS (anonymous FTP uses the username anonymous and any e-mail address as password), ASCII/binary translation so that text files are converted between operating-system line endings, remote directory navigation, and resumption of interrupted transfers. Reliability comes from TCP, so FTP needs no error correction of its own.

Security — the main limitation. Classic FTP transmits the password and file data in clear text; anyone sniffing the path can capture them. Secure alternatives are:

• SFTP — SSH File Transfer Protocol, running over SSH on port 22; a completely different protocol, not FTP with security added.
• FTPS — FTP secured with TLS/SSL: implicit TLS on port 990, or explicit AUTH TLS negotiated on port 21.

Other issue. The PORT command embeds the client's private IP address inside the payload, which breaks behind NAT; RFC 2428 added the EPRT/EPSV extensions and IPv6 support to solve this. Because FTP keeps control and data on different ports, it is also awkward for packet-filtering firewalls, which must be told to open both.

Short Notes on Firewall

Definition. A firewall is a combination of hardware and software placed between a trusted internal network and an untrusted network (usually the Internet) that enforces an access-control policy: it examines every entering and leaving packet against a rule set and permits, drops or rejects it accordingly. Its goals are to keep intruders out, limit which services are reachable from outside, and stop internal hosts from contacting dangerous destinations. It does not replace authentication, antivirus or user awareness.

Types (classified by the layer at which they filter)

1. Packet-filtering firewall (Layers 3/4). Filters each packet individually using a rule list (ACL) built on the 5-tuple: source IP, destination IP, protocol (TCP/UDP/ICMP), source port and destination port. It is cheap, fast, transparent to applications and needs no host configuration. But it is stateless — it cannot tell whether an inbound ACK belongs to a connection this host actually started — it cannot inspect payloads, and a large rule set quickly becomes inconsistent and error-prone.
2. Stateful-inspection firewall (Layers 3-5). Maintains a state table of live connections, e.g. 192.168.1.10:49152 -> 142.250.x.x:443 ESTABLISHED. Inbound packets are accepted only if they belong to an existing session or are genuine new connection requests. This blocks spoofed, random inbound packets that a loose stateless rule would let through.
3. Circuit-level gateway / proxy (Layer 5). Validates the session (TCP handshake, SOCKS) between internal and external hosts without examining each packet; simple but gives no content control.
4. Application-layer firewall / proxy (Layer 7). Understands specific protocols (HTTP, FTP, SMTP, DNS), so it can filter URLs and keywords, block file types, log individual user actions and reject malformed requests. It is the most thorough but adds latency and needs a proxy for every service. Next-generation firewalls (NGFW) add intrusion-prevention, application identification and user/packet deep inspection.

Other important ideas

• DMZ (demilitarised zone): a screened subnet between two firewall interfaces holding the public servers (web, mail, FTP). Even if a DMZ server is compromised, the internal network stays isolated.
• Default-deny policy: inbound traffic is denied unless explicitly allowed (only ports such as 80/443/25 open) — the safe default; default-allow is the opposite and is dangerous.
• Bastion host: the most exposed, heavily hardened system in the DMZ.
• Egress filtering restricts outbound traffic too, which limits data exfiltration and blocked-malware callbacks.

Limitations

A firewall cannot stop attacks arriving over an allowed channel (malware inside HTTPS, phishing), cannot see content of encrypted traffic unless it terminates TLS, does nothing against insider users or guests on the Wi-Fi, and cannot protect links (modem/remote access) that bypass it.

Unicast vs Multicast

Both are IP delivery modes describing how many receivers a single stream of data reaches. Unicast is one-to-one communication between exactly one sender and one receiver; multicast is one-to-many, where one sender transmits a single copy of the data that is replicated by routers only along the branches leading to subscribed receivers.

1. Comparison table

Basis	Unicast	Multicast
Communication type	One-to-one (single sender, single receiver)	One-to-many (single sender, group of receivers)
Address used	Class A/B/C unicast address (host-specific)	Class D address, range 224.0.0.0 – 239.255.255.255
Address identifies	One specific host interface	A group, not a host — no fixed location
Receiver membership	Implicit — the address names the receiver	Explicit join/leave via IGMP (Internet Group Management Protocol)
Packet replication	One copy sent to that host only	Router replicates packets only on links with group members
Bandwidth usage	$N$ receivers ⇒ $N$ copies of the traffic on the source link path	One copy leaves the source; total network load ≪ $N$ copies
Router behaviour	Standard forwarding along the unicast route	Needs multicast routing (e.g. PIM, DVMRP) and a shared/distribution tree
Routing table	Simple per-destination unicast route	Separate multicast forwarding table built from group state
Use of receiver address	Destination address is the receiver's unicast IP	Destination address is the group address; receiver IP never appears in the header
Example protocols/applications	HTTP, FTP, SMTP, SSH	IPTV, video conferencing, live streaming, OSPF/MOSPF updates, news feeds
Scalability of delivery	Scales with number of receivers (source sends repeatedly)	Scales well — sender effort is constant regardless of group size
Error/ack behaviour	Each receiver can be acknowledged individually	No per-receiver ACK (would defeat the purpose); unreliable, best-effort
Address classes (IPv4)	A, B, C	D only
Requires	Nothing beyond routing	IGMP at host/router, multicast-capable routers and protocols

2. Why multicast is efficient

If a source must send a 1 Mbps video stream to 1000 users:

• Unicast: the source (or its access link) transmits $1000 \times 1 \text{ Mbps} = 1000$ Mbps.
• Multicast: the source transmits 1 Mbps once; the network duplicates packets only at routers where members exist, so link carrying depends on topology, not on group size.

3. Diagram (conceptual)

        Unicast (3 copies)                Multicast (1 copy, replicated)

   S ──► R1 ──► H1                    S ──► R1 ──┬──► H1 (member)
        │                             (one copy) ├──► H2 (member)
        ├──► R2 ──► H2                          │
        │                                       R2 ──► H3 (member)
        └──► R3 ──► H3  (non-member: no copy)

4. Summary

Unicast addresses a device and is used for ordinary request–response traffic where reliability and individual delivery matter. Multicast addresses a group and is used for bandwidth-hungry one-to-many distribution, where sending a single copy and letting routers replicate it saves enormous network capacity — at the cost of needing IGMP plus multicast routing.

Email architecture (context)

Email uses three kinds of agents:

• UA (User Agent): the mail client (Outlook, Thunderbird, Gmail app) used to compose and read mail.
• MTA (Message Transfer Agent): the server software that transfers mail between servers; it uses SMTP.
• MAA (Message Access Agent): lets the recipient retrieve mail from the mailbox server; it uses POP3 or IMAP4.

Sender UA --SMTP--> Sender's MTA --SMTP--> Receiver's MTA --> Mailbox
                                                                 |
Receiver UA <------------- POP3 / IMAP4 (MAA) -------------------+

SMTP vs POP

Basis	SMTP (Simple Mail Transfer Protocol)	POP3 (Post Office Protocol v3)
Purpose	Sending / transferring mail	Retrieving mail from the server
Type	Push protocol	Pull protocol
Direction	Client → server, and server → server	Server → client
Used by	MTA (sender UA to server, between servers)	MAA (receiver UA)
Port	25 (587 for submission; 465 secure)	110 (995 with SSL/TLS)
Commands	HELO/EHLO, MAIL FROM, RCPT TO, DATA, QUIT	USER, PASS, STAT, LIST, RETR, DELE, QUIT
Message storage	Only relays it toward the destination	Downloads to the local machine, usually deleting it from the server
Format handling	Transfers 7-bit ASCII (binary content via MIME)	Retrieves the stored message
Connection	TCP, persistent for multiple messages	TCP, one session per download

Mail Access Agents (MAA)

SMTP only pushes mail to the receiver's mail server. Because the recipient's computer is often not always online, the message is stored in the mailbox on the server, and the user's UA fetches it later with a Mail Access Agent. MAAs are pull protocols.

1. POP3 (Post Office Protocol, version 3)

• Simple protocol with three phases: authorization (USER, PASS), transaction (STAT, LIST, RETR, DELE), and update (QUIT applies deletions).
• Two modes: delete mode (messages removed from the server after download) and keep mode (copies remain on the server).
• Advantages: simple, quick, works offline after download, saves server space.
• Disadvantages: poor for several devices (mail lives on one computer), no server-side folders, limited management on the server.

2. IMAP4 (Internet Message Access Protocol, version 4)

• More powerful: mail stays on the server, and the client works on it remotely.
• Features: create, delete, and rename server-side mailboxes/folders; partial download (read headers only, or part of a message); search on the server; flags (read, replied, deleted) synchronised across devices; multiple clients see the same mailbox.
• Port 143 (993 with SSL/TLS).
• Disadvantages: needs more server storage and resources and a continuous connection for full use.

3. Web-based mail (HTTP)

• Gmail, Yahoo, or Outlook.com: the user reads mail through a browser over HTTP/HTTPS; the web server acts as the MAA using POP3/IMAP internally. Mail is sent from the browser to the mail server by HTTP, then between servers by SMTP.

POP3 vs IMAP4

Basis	POP3	IMAP4
Mail location	Downloaded to the client	Kept on the server
Multi-device use	Poor	Excellent
Server-side folders	No	Yes
Partial fetch / search	No	Yes
Complexity and server load	Low	Higher

Summary: SMTP is used to send mail; POP3 and IMAP4 (the Mail Access Agents) are used to read mail.