Computer Networks

The Application Layer

Email and Other Protocols

Two Different Protocols, Two Different Jobs

JrCodex·9 min read

Jr Codex Computer Networks Notes

Level: Intermediate Prerequisites: Chapter 4: REST, WebSockets and Real-Time Time to complete: ~20 minutes

Table of Contents

  1. How Email Actually Moves
  2. SMTP
  3. Retrieval — POP3 and IMAP
  4. Email Authentication
  5. File Transfer
  6. SSH and NTP
  7. Summary & Next Steps

1. How Email Actually Moves

The Path of One Message
─────────────────────────────────────────
  asha@example.com ──► ravi@other.org

  1. Asha's client submits to her provider's server
       SMTP, port 587, authenticated

  2. Her server looks up other.org's MX record
       DNS (Chapter 1)

  3. Her server connects to their server
       SMTP, port 25, server to server

  4. Their server stores it in Ravi's mailbox

  5. Ravi's client retrieves it
       IMAP, port 993
─────────────────────────────────────────

Two Different Protocols, Two Different Jobs
─────────────────────────────────────────
  SMTP  PUSHES mail toward its destination.
        Used for submission AND for server-to-server
        relay.

  IMAP / POP3  PULL mail from a mailbox you own.

  Email is one of the few remaining widely-used
  systems that is genuinely FEDERATED — anyone may
  run a server, and they interoperate. That
  openness is also why spam is such a problem, and
  why Section 4 exists.
─────────────────────────────────────────

2. SMTP

A Session, in Full
─────────────────────────────────────────
  S: 220 mail.other.org ESMTP ready
  C: EHLO mail.example.com
  S: 250-mail.other.org
     250-STARTTLS
     250-SIZE 35882577
     250 AUTH PLAIN LOGIN
  C: STARTTLS
  S: 220 Ready to start TLS
     ── everything after this is encrypted
        (Module 6, Chapter 3)
  C: MAIL FROM:<asha@example.com>
  S: 250 OK
  C: RCPT TO:<ravi@other.org>
  S: 250 OK
  C: DATA
  S: 354 End with <CRLF>.<CRLF>
  C: From: Asha <asha@example.com>
     To: Ravi <ravi@other.org>
     Subject: Networks notes

     Here is the link.
     .
  S: 250 OK queued as 3F9C1
  C: QUIT
─────────────────────────────────────────

THE ENVELOPE vs THE HEADERS
─────────────────────────────────────────
  MAIL FROM and RCPT TO are the ENVELOPE — what
  the mail servers actually use to route and
  deliver.

  From: and To: are HEADERS inside the message —
  what the recipient's client displays.

  THEY NEED NOT MATCH. This is not a bug; it is how
  mailing lists and forwarding work.

  It is also the entire basis of email spoofing:
  nothing in SMTP itself verifies that the From:
  header belongs to you. Section 4 is the response.
─────────────────────────────────────────

Port Numbers, and Why They Differ
─────────────────────────────────────────
  25    server-to-server relay. Widely BLOCKED by
        consumer ISPs to limit spam from
        compromised machines.
  587   SUBMISSION — client to its own server,
        AUTHENTICATED. The port your mail client
        uses.
  465   implicit TLS submission.

  The split exists so that "relaying mail onward"
  and "accepting mail from an authenticated user"
  are separable — an open relay accepting anything
  on port 25 becomes a spam source within hours.
─────────────────────────────────────────

3. Retrieval — POP3 and IMAP

The Distinction
─────────────────────────────────────────
  POP3 (port 995)
    DOWNLOAD and typically DELETE. Mail lives on
    the client.
    + simple, works offline, minimal server storage
    - one device only; no shared state, no server
      folders

  IMAP (port 993)
    Mail lives ON THE SERVER; clients view and
    manipulate it.
    + many devices stay in sync
    + server-side folders, flags and search
    + fetch headers only, bodies on demand
    - more complex; needs connectivity
─────────────────────────────────────────

Why IMAP Won
─────────────────────────────────────────
  People have a phone, a laptop and a browser.

  POP3's model — mail is downloaded to one machine
  — makes multi-device access incoherent. Read a
  message on your phone and your laptop does not
  know.

  IMAP keeps the SERVER as the source of truth and
  clients as views of it, so state is shared by
  construction.

  It is the same architectural choice as
  server-side sessions versus client-side state
  (Chapter 2).
─────────────────────────────────────────

4. Email Authentication

Three DNS-published mechanisms that together make spoofing hard.

SPF — Sender Policy Framework
─────────────────────────────────────────
  A TXT record listing which servers may send mail
  for your domain.

    example.com. TXT "v=spf1 ip4:203.0.113.0/24
                      include:_spf.provider.com
                      -all"

  The receiver checks the connecting server's IP
  against it.

  CHECKS: the ENVELOPE sender (MAIL FROM).
  BREAKS ON: forwarding, because the forwarding
  server is not in your SPF record.

DKIM — DomainKeys Identified Mail
─────────────────────────────────────────
  The sending server SIGNS the message with a
  private key; the public key is published in DNS.

    selector._domainkey.example.com. TXT
      "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

  The receiver verifies the signature.

  CHECKS: the message CONTENT and selected headers.
  SURVIVES FORWARDING, as long as the message is
  not modified.

DMARC — the policy that ties them together
─────────────────────────────────────────
  _dmarc.example.com. TXT
    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

  It states:
    - require SPF and/or DKIM to pass AND ALIGN
      with the From: header domain
    - what to do on failure: none, quarantine, or
      reject
    - where to send aggregate reports

  ALIGNMENT is the crucial part: it connects the
  authenticated identity to the From: header the
  USER SEES — closing the envelope-versus-header
  gap from Section 2.
─────────────────────────────────────────

dig example.com TXT +short | grep spf
dig selector1._domainkey.example.com TXT +short
dig _dmarc.example.com TXT +short
The Deployment Order That Avoids Disaster
─────────────────────────────────────────
  1. Publish SPF and DKIM.
  2. Publish DMARC with p=none and a reporting
     address.
  3. READ THE REPORTS for weeks. You will discover
     legitimate senders you had forgotten —
     invoicing systems, marketing tools, monitoring
     alerts.
  4. Fix or authorise each one.
  5. Move to p=quarantine, then p=reject.

  Going straight to p=reject silently discards
  legitimate mail from systems nobody remembered.
  This happens regularly.
─────────────────────────────────────────

5. File Transfer

FTP — and why to avoid it
─────────────────────────────────────────
  TWO connections: a CONTROL connection (port 21)
  and a separate DATA connection per transfer.

  ACTIVE MODE:  the SERVER connects back to the
                client ── blocked by every NAT and
                firewall (Module 3, Chapter 5)
  PASSIVE MODE: the client opens both ── works, but
                needs a range of ports open

  And it is UNENCRYPTED: credentials in plaintext.

  Worse, FTP embeds IP ADDRESSES IN ITS PAYLOAD,
  which is exactly the case that requires
  NAT helpers (Module 3, Chapter 5).

  USE INSTEAD: SFTP (over SSH), FTPS, or HTTPS.
─────────────────────────────────────────

The Alternatives
─────────────────────────────────────────
  SFTP     file transfer over SSH, port 22.
           One connection, encrypted, NAT-friendly.
           The default choice.

  SCP      simpler, older, over SSH. Fine for a
           single file.

  RSYNC    transfers only DIFFERENCES. Enormously
           faster for repeated syncs of large
           trees.

  HTTPS    for downloads: cacheable, CDN-friendly,
           resumable with Range requests
           (Chapter 2).
─────────────────────────────────────────

6. SSH and NTP

SSH — port 22
─────────────────────────────────────────
  1. TCP connect
  2. Version exchange
  3. KEY EXCHANGE ── Diffie-Hellman, producing a
     shared secret (Module 6, Chapter 2)
  4. SERVER AUTHENTICATION ── its host key is
     checked against known_hosts
  5. CLIENT AUTHENTICATION ── public key, or
     password
  6. Encrypted channels, multiplexed over the one
     connection
─────────────────────────────────────────

Trust On First Use
─────────────────────────────────────────
  "The authenticity of host ... can't be
   established. Are you sure you want to continue?"

  You are being asked to verify a key you have no
  way to check. Most people type yes.

  It is accepted after that, so a machine-in-the-
  middle on the FIRST connection succeeds
  permanently.

  This is TOFU — trust on first use. It is weaker
  than the certificate authority model
  (Module 6, Chapter 3), and it is why
  "REMOTE HOST IDENTIFICATION HAS CHANGED" should
  never be dismissed casually.
─────────────────────────────────────────

# Port forwarding — SSH as a general-purpose secure tunnel.
ssh -L 5432:localhost:5432 user@server     # LOCAL: reach a remote DB as if local
ssh -R 8080:localhost:3000 user@server     # REMOTE: expose a local service outward
ssh -D 1080 user@server                    # DYNAMIC: a SOCKS proxy
NTP — port 123, over UDP
─────────────────────────────────────────
  Synchronises clocks, typically to within
  milliseconds.

  STRATUM 0  reference clocks — atomic, GPS
  STRATUM 1  servers directly attached to them
  STRATUM 2  servers synchronised to stratum 1
  ...

  It measures the ROUND TRIP and assumes symmetry
  to estimate the offset — so an asymmetric path
  degrades accuracy.
─────────────────────────────────────────

Why Clock Skew Breaks Things
─────────────────────────────────────────
  - TLS CERTIFICATES have validity windows. A clock
    off by a day makes every certificate appear
    expired or not yet valid (Module 6, Chapter 3).
  - Kerberos and many token schemes reject requests
    outside a small time window.
  - LOG CORRELATION across machines becomes
    impossible.
  - Distributed systems that order events by
    timestamp produce wrong answers.

  "It works on one machine and fails across two"
  is sometimes a clock problem, and it is rarely
  the first thing anyone checks.
─────────────────────────────────────────

7. Summary & Next Steps

Key Takeaways

  • SMTP's envelope and the message's From: header need not match, which is what makes mailing lists work and what makes spoofing trivial without SPF, DKIM and DMARC.
  • IMAP won over POP3 because keeping the server as the source of truth is the only coherent model for multiple devices.
  • DMARC's contribution is alignment — tying the authenticated identity to the From: header the user actually sees — and it must be deployed with p=none first.
  • FTP embeds addresses in its payload and needs a server-initiated connection, which is why it fails through NAT and should be replaced by SFTP or HTTPS.

Module 5 Complete — What's Next

You now know what programs say to each other. Module 6 addresses the fact that, so far, everything in this curriculum has been sent in plaintext across networks owned by strangers.

Concept Check

  1. Why can the SMTP envelope sender differ from the From: header, and what does that enable?
  2. What does DMARC add that SPF and DKIM do not provide on their own?
  3. Why does SSH's trust-on-first-use model leave a specific window of vulnerability?

Next Module

→ Module 6: Network Security

Jr Codex — 1-on-1 Personalized Coaching | Back to Module Index | Back to Computer Networks Index