COMP347 (Revision 10) | TrustOpen University
Upon completion of this expanded tutorial, students will be able to:
Electronic mail is one of the oldest and most resilient Internet applications. Its architecture, built around store‑and‑forward message transfer, has proven remarkably scalable. This tutorial provides a deep technical examination of the email system, from the user agent to the mail server, and the protocols that glue them together.
We begin with a system‑level view, defining the components (UA, MTA, MDA) and their interactions. We then dissect the SMTP protocol, including its state machine, extensions, and the role of DNS MX records. The message format is explored through RFC 5322 and MIME (RFC 2045‑2049), with a focus on multipart structures and content encoding. The comparison between POP3 and IMAP highlights the fundamental design choices: download‑and‑delete vs. server‑side storage and synchronisation. Finally, we examine the security landscape, including SPF, DKIM, DMARC, and DANE, which combat spoofing and ensure transport security.
Email is not a real‑time protocol; it uses store‑and‑forward. An MTA accepts a message, queues it, and attempts delivery to the next hop. If delivery fails, the message is retried with exponential backoff (typically for several days). This makes the system tolerant of transient network failures.
To find the destination MTA, the sending MTA performs a DNS lookup for MX (Mail Exchange) records of the recipient's domain. MX records have a preference value (lower is higher priority). The MTA then connects to the hostname returned, using port 25 (or 587 for submission).
SMTP (RFC 5321) is a text‑based, command‑response protocol. Commands are 4‑letter words; responses are 3‑digit numeric codes with optional text.
| Command | Purpose | Example |
|---|---|---|
| HELO / EHLO | Identify client (EHLO for ESMTP) | EHLO mail.example.com |
| MAIL FROM | Specify sender (reverse‑path) | MAIL FROM:<sender@example.com> |
| RCPT TO | Specify recipient (forward‑path) | RCPT TO:<recipient@example.net> |
| DATA | Begin message data (terminated by ".\r\n") | DATA |
| QUIT | End session | QUIT |
| RSET | Reset session (abort current mail transaction) | RSET |
| VRFY | Verify a mailbox (often disabled for security) | VRFY user |
| EXPN | Expand a mailing list (often disabled) | EXPN list |
Common responses: 220 (ready), 250 (OK), 354 (start mail input), 421 (service not available), 450 (mailbox unavailable, temporary), 550 (mailbox unavailable, permanent).
To prevent open relays, MTAs require authentication for relaying (especially on submission ports). The AUTH command negotiates a mechanism; credentials are sent Base64‑encoded. STARTTLS upgrades the plaintext connection to TLS, protecting credentials and message content in transit.
A message consists of headers and a body, separated by a blank line. Headers include From, To, Subject, Date, Message‑ID, and optional Reply‑To, CC, BCC (though BCC is often stripped by MTAs). The body is plain ASCII text originally.
MIME (RFC 2045‑2049) extends email to support:
MIME‑Version: 1.0Content‑Type: media type (e.g., text/plain, image/jpeg, multipart/mixed).Content‑Transfer‑Encoding: encoding used (e.g., base64, quoted‑printable, 7bit, 8bit).Content‑Disposition: inline or attachment with filename.Content‑ID: for inline referencing.
Multipart messages use a boundary string to separate parts. Example for multipart/mixed:
USER, PASS, STAT, LIST, RETR, DELE, QUIT.\Seen, \Answered, \Deleted, \Draft, and custom keywords.LOGIN, SELECT, FETCH, STORE, SEARCH, APPEND, CREATE, DELETE, EXPUNGE.FETCH with BODY.PEEK to avoid marking as seen.| Feature | POP3 | IMAP |
|---|---|---|
| Server storage | Usually no (download and delete) | Yes (server retains messages) |
| Multi‑device sync | Poor (flags not sync) | Excellent (flags and folders sync) |
| Offline access | Full (messages stored locally) | Partial (cached, sync on reconnect) |
| Bandwidth usage | High (downloads all) | Low (fetch headers, partial content) |
| Server‑side search | No | Yes (SEARCH) |
| Push notifications | No (polling) | Yes (IDLE) |
MAIL FROM) against the SPF record.pass, fail, softfail, neutral, none.From, Subject) to prevent tampering.p=none (monitor), p=quarantine (mark as spam), p=reject (discard).If delivery fails (e.g., destination MTA unreachable), the message is queued. The MTA will retry with increasing intervals (e.g., 5 min, 15 min, 1 h, 4 h, etc.) until a maximum lifetime (e.g., 4‑5 days) is exceeded, after which a bounce message (DSN) is sent to the sender.
Q1: Which DNS record type is used to locate a mail server?
MX (Mail Exchange).
Q2: What SMTP command is used to start a mail transaction and specify the sender?
MAIL FROM.
Q3: What is the purpose of the MIME Content‑Transfer‑Encoding header?
It specifies how the message body is encoded (e.g., base64, quoted‑printable) to allow safe transmission over 7‑bit channels.
Q4: Which protocol supports server‑side mailboxes and folders?
IMAP.
Q5: What is the role of SPF in email security?
It authorises which IP addresses are allowed to send email for a domain, preventing spoofing.
Q6: How does DKIM protect email integrity?
It uses a digital signature over selected headers and body; the signature is verified against a public key published in DNS.
Q7: What does DMARC's p=reject policy do?
It instructs receivers to reject (discard) messages that fail SPF and/or DKIM authentication.
Q8: In IMAP, what is the purpose of the IDLE command?
It allows the server to push real‑time notifications of new messages to the client, avoiding polling.
Q9: What is the difference between RETR in POP3 and FETCH in IMAP?
RETR downloads the entire message; FETCH can retrieve specific parts (headers, body, MIME parts) and supports partial fetching.
Q10: Why is port 587 preferred over port 25 for client submission?
Port 587 requires authentication and supports STARTTLS; port 25 is typically for MTA‑to‑MTA relay and may be blocked by ISPs to prevent spam.
Q11: What is the function of the Message‑ID header?
It provides a globally unique identifier for the message, used for threading and tracking.
Q12: How does DANE improve SMTP security?
It uses DNS TLSA records to pin the expected certificate, reducing reliance on CAs and preventing MITM attacks.
Exercise 1 – SMTP Session Trace
Interpret the following SMTP session and explain each response code.
220: service ready; 250: command OK (multiple with EHLO response); 354: start mail input; 250 after DATA: message queued; 221: closing connection.
Exercise 2 – MIME Message Construction
Create a MIME message with a plain text part, an HTML part, and an image attachment. Show all relevant headers and structure.
Use multipart/mixed with a multipart/alternative child for text/html, and a separate part for the image with Content‑Type: image/png and Content‑Disposition: attachment.
Exercise 3 – IMAP Synchronisation
Explain how an IMAP client keeps read/unread status synced across multiple devices.
The client uses STORE to set the \Seen flag on the server. All other clients will see the updated flag when they FETCH the message or when the server sends unsolicited flag updates (if supported).
Exercise 4 – Email Deliverability Troubleshooting
Emails from your domain are going to spam. What steps would you take?
Check SPF, DKIM, DMARC records. Ensure reverse DNS (PTR) matches the sending IP. Check IP reputation (blacklists). Use a dedicated IP for bulk sending. Ensure DKIM signing uses a strong key. Monitor DMARC reports.
Exercise 5 – POP3 Session Walkthrough
Write the commands for a POP3 session that downloads message 1, marks it for deletion, then quits.
USER username, PASS password, RETR 1, DELE 1, QUIT.
Exercise 6 – MTA Queuing Behavior
What happens if the destination MTA responds with a 450 (temporary failure)?
The sending MTA queues the message and retries later with exponential backoff. After repeated failures, a DSN (bounce) may be sent to the sender.
Homework 1 – Email Security Deployment
Design a complete email security deployment for a small business domain. Include SPF, DKIM, DMARC policies, and TLS configuration. Provide DNS records and justification for policy choices.
Use a DMARC policy of p=quarantine initially, then progress to reject after monitoring.
Homework 2 – IMAP vs POP3 Decision
A company has 100 employees who use both desktop and mobile email clients. Which protocol would you recommend and why?
Recommend IMAP for synchronisation, server‑side folders, and flags. Consider Exchange ActiveSync if push is needed.
Homework 3 – DANE and DNSSEC Research
Research the relationship between DANE and DNSSEC. How does DNSSEC protect TLSA records? What are the challenges in deploying DANE for SMTP?
DNSSEC provides authentication of DNS responses; DANE relies on it. Challenges include DNSSEC adoption and CA opposition.
Homework 4 – Email Headers Analysis
Analyse the full headers of a spam email. Identify the authentication results (SPF, DKIM, DMARC) and trace the relay path.
Look for Received headers, Authentication‑Results, and DKIM‑Signature.
Homework 5 – MIME Parsing Implementation
Write a simple MIME parser (in pseudo‑code) that extracts the plain text body from a multipart/alternative message.
Parse boundaries, read Content‑Type headers, select the text/plain part, and decode transfer encoding if needed.
This expanded tutorial has provided a comprehensive, technical examination of Internet email systems. Key takeaways:
Understanding these protocols and mechanisms is essential for managing mail servers, troubleshooting delivery issues, and securing email communications.