Explore Network and Email Protocols

Send raw protocol commands to explore DNS, HTTP, SMTP, and POP3 hands-on.

Introduction

30 Second Summary

Every time you open a website or send an email, your computer has an invisible conversation with servers around the world. You never see these conversations because your browser and email app handle everything behind the scenes.

In this project, you will build a hands-on protocol lab on your Windows machine. You will use command-line tools to speak directly to servers using raw protocol commands, watching every step of what normally happens out of sight.

What You'll Build

Picture yourself in a terminal, typing commands directly to a mail server one line at a time, and watching it accept a forged email without any authentication check.

By the end of this project, you'll have:

Queried DNS records from the command line to watch your computer translate domain names into IP addresses and discover the mail servers behind any domain.
Made raw HTTP and HTTPS requests and watched a TLS handshake negotiate encryption in real time.
Run your own local mail server, sent and forged emails using raw SMTP commands, retrieved them with POP3, and decoded real SPF, DKIM, and DMARC records to understand how email authentication blocks spoofing.
Secret Mission: An optional challenge to push your protocol skills even further.

Are there any prerequisites?

This project is designed for Windows 10 or 11. You will need Docker Desktop installed before you begin.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

In this project, you'll use command-line tools to speak directly to servers using raw protocol commands. Taking a moment now to connect this work to your own goals will help everything that follows stick.

Set Up Your Protocol Lab

To explore network protocols hands-on, you need command-line tools that let you speak directly to servers using raw protocol commands. Most of these tools are already built into your Windows machine.

Two things need extra setup. Telnet is built into Windows but disabled by default, and your local mail server needs to be pulled from Docker. In this step, you'll enable both, then verify everything is ready to go.

In this step, get ready to:

Enable the Windows Telnet Client for raw protocol connections.
Verify that nslookup and curl are available.
Pull and run Mailpit as your local mail server.

Enable the Windows Telnet Client

Telnet lets you open raw TCP connections and type protocol commands by hand. It is built into Windows but disabled by default. You need to enable it through PowerShell running as an Administrator.

Press the Windows key to open your search bar.
Type PowerShell.
Right-click Windows PowerShell and select Run as administrator.
If prompted by User Account Control, click Yes to allow it.
Enable Telnet by running this command:

Enable-WindowsOptionalFeature -Online -FeatureName TelnetClient -NoRestart

What does this command do?

Enable-WindowsOptionalFeature turns on a Windows feature that is installed but disabled.
-Online tells PowerShell to apply the change to your running operating system (not an offline image).
-FeatureName TelnetClient specifies which feature to enable.
-NoRestart means you do not need to restart your computer.

The command takes a few seconds to complete. Now verify that Telnet is working.

Open a new Command Prompt window by pressing the Windows key, typing cmd, and pressing Enter.
Verify Telnet is enabled by running:

telnet

You should see the Microsoft Telnet prompt (Microsoft Telnet>).

Type quit and press Enter to exit Telnet.

Don't see the Telnet prompt?

Make sure you ran PowerShell as an Administrator. Without admin privileges, the enable command will fail.
Open a NEW Command Prompt window after running the enable command. Existing windows do not pick up the change.
If you see an error about the feature not being found, make sure you typed TelnetClient exactly (it is case-sensitive).

help me enable the Telnet Client on Windows

Verify your built-in tools

Both nslookup and curl are built into Windows 10 and Windows 11. Let's confirm they are ready before moving on.

In your Command Prompt window, check that nslookup is available by running:

nslookup

You should see your default DNS server listed in the output.

Type exit and press Enter to leave the nslookup prompt.
Check that curl is available by running:

curl --version

You should see a version number and the word Schannel in the output. Schannel is the Windows native TLS library that lets curl make encrypted HTTPS connections.

Command not found?

Both tools ship with Windows 10 (version 1803 and later) and Windows 11. If either command is not recognized, make sure you are running a regular Command Prompt, not PowerShell. Some PowerShell versions alias curl to a different command.

help me get nslookup or curl working on Windows

Pull and run Mailpit

Mailpit is a lightweight email testing tool that runs an SMTP server, POP3 server, and web UI all in one Docker container. This is the mail server you will use to send and retrieve emails using raw protocol commands.

Make sure Docker Desktop is running. Look for the Docker whale icon in your system tray (bottom-right corner of your screen).
In your Command Prompt, pull and start Mailpit by running this command:

docker run -d --name mailpit -p 1025:1025 -p 8025:8025 -p 1110:1110 -e MP_POP3_AUTH="testuser:testpass" axllent/mailpit

What does this command do?

docker run -d starts a container in the background.
--name mailpit gives the container a name you can reference later.
-p 1025:1025 maps the SMTP port so you can send emails to the server.
-p 8025:8025 maps the web UI port so you can view emails in your browser.
-p 1110:1110 maps the POP3 port so you can retrieve emails from the server.
-e MP_POP3_AUTH="testuser:testpass" sets the POP3 login credentials to testuser / testpass.
axllent/mailpit is the official Docker image.

Before you check the result, what do you expect to see when you open the Mailpit web UI for the first time?

Open your browser and go to http://localhost:8025.

You should see the Mailpit web UI with an empty inbox. This confirms your SMTP server (port 1025), POP3 server (port 1110), and web UI (port 8025) are all running.

Don't see the Mailpit web UI?

Make sure Docker Desktop is running. Look for the Docker whale icon in your system tray.
Check that the container is running by typing docker ps in Command Prompt. You should see mailpit listed.
If the container is not listed, check for errors by running docker logs mailpit. A common cause is another application already using port 1025, 8025, or 1110.

help me get Mailpit running in Docker

Your protocol lab is ready. Next up, you'll use nslookup to query DNS directly and watch your computer translate domain names into IP addresses in real time.

Explore DNS in Action

Your protocol lab is set up and ready to go. Now you are going to make something invisible visible: the DNS queries that happen every time your computer reaches out to the internet.

Every time you type a URL into your browser, your computer sends a DNS query to translate that domain name into an IP address. Without this translation, nothing on the internet would work.

In this step, get ready to:

Query A, AAAA, and NS DNS records using nslookup.
Discover a domain's mail servers by looking up MX records.
Map your DNS queries to the OSI Model.

Resolve a domain name to an IP address

An A record is the most basic DNS record type. It maps a domain name to an IPv4 address, and it is the very first thing your browser looks up before it can load any webpage.

Switch back to your Command Prompt and query the A record for example.com by running this command:

nslookup example.com 8.8.8.8

You should see a response that includes a Name and an Address line showing the IP address for example.com.

What did this query do?

This command sent a DNS query to Google's public DNS server (8.8.8.8) asking: "What is the IP address for example.com?" The response is an A record containing the IPv4 address.

This is the first thing your browser does before it can load any webpage. Without this translation from name to number, the internet would not work.

Not seeing results?

Check your internet connection. DNS queries require network access to reach the 8.8.8.8 server.
If you see a timeout, try running nslookup example.com without the 8.8.8.8 argument to use your default DNS server instead.
Make sure you are in Command Prompt, not PowerShell. The output format may differ between the two.

Help me troubleshoot my nslookup query

Now try two more DNS record types to see what else DNS can tell you about a domain.

Query the AAAA record for the IPv6 address by running:

nslookup -type=AAAA example.com 8.8.8.8

The AAAA record returns the IPv6 address for the same domain. Same concept as the A record, just a newer and longer address format.

Look up the authoritative name servers by running:

nslookup -type=NS example.com 8.8.8.8

What are NS records?

NS (Name Server) records reveal which servers are the "source of truth" for a domain's DNS records. When you query any other DNS server, it ultimately gets its answers from these authoritative name servers.

Discover a domain's mail servers

DNS does more than map domain names to web servers. It also tells the world which servers handle email for a domain using MX records.

Before you run the next query, take a guess. What information would a mail server need to find in DNS before it could deliver an email to a @gmail.com address?

Look up the MX records for gmail.com by running:

nslookup -type=MX gmail.com 8.8.8.8

You should see a list of mail servers with priority numbers next to each one. Lower numbers mean higher priority.

How do MX records route email?

MX (Mail eXchange) records tell the world which servers handle email for a domain. When someone sends an email to a @gmail.com address, their mail server looks up these MX records to find where to deliver it.

The sending server tries the highest-priority server first (the lowest number). If that server is unavailable, it falls back to the next one. This is how the entire email system routes messages across the internet.

Not seeing MX records?

Double check you typed -type=MX (uppercase MX) and included 8.8.8.8 at the end of the command.
If nslookup drops into interactive mode (showing a > prompt instead of results), type exit and re-run the full command on one line.

Help me troubleshoot my MX record lookup

Map your queries to the OSI Model

Every DNS query you just ran traveled through multiple layers of networking before it reached the DNS server and came back. The OSI Model breaks this journey into seven layers.

Where does DNS sit in the OSI Model?

Layer 7 (Application): The DNS protocol itself. Your query and the server's response.
Layer 4 (Transport): DNS used UDP port 53 to carry your query.
Layer 3 (Network): IP routing got your query packet to 8.8.8.8 and back.
Layer 2 (Data Link): Your network card framed the packet for your local network.
Layer 1 (Physical): Electrical signals or radio waves carried the actual bits over the wire or through the air.

Every protocol you will use in this project follows this same layered structure. DNS just gave you the first taste.

You have seen how DNS translates domain names into addresses and routes email across the internet. Next up, you will use those addresses to make web requests and watch encryption happen in real time.

Compare HTTP and HTTPS with the TLS Handshake

In the last step, you used DNS to translate domain names into IP addresses. That name-to-number lookup is the very first thing that happens when you visit a website. Now it is time to see what happens next.

In this step, you will make web requests using curl and watch the raw protocol exchange. First over plaintext HTTP where every header is readable. Then over HTTPS where a TLS handshake encrypts the entire conversation before any data flows.

In this step, get ready to:

Send a plaintext HTTP request and read every header in the raw exchange.
Send an HTTPS request and watch the TLS handshake negotiate encryption in real time.
Compare the two to understand how TLS secures web traffic.

Make a plaintext HTTP request and read the raw exchange

When you type a URL into your browser, it sends an HTTP request to a server and gets a response back. Normally this happens invisibly in milliseconds. The -v flag on curl makes every byte of that exchange visible.

In your Command Prompt window, send a plaintext HTTP request by running this command:

curl -v http://example.com -o NUL 2>&1

What does this command do?

-v turns on verbose mode, showing every header sent and received.
-o NUL discards the HTML body so you can focus on the protocol exchange.
2>&1 redirects stderr (where curl prints verbose output) to stdout so you can see everything together.

Look at the output. You will see lines like these:

> GET / HTTP/1.1 is your request, in plain text.
> Host: example.com is the Host header, telling the server which site you want.
< HTTP/1.1 200 OK is the server's response status.
< Content-Type: text/html is one of the response headers describing the content.

Everything is readable. Nothing is encrypted. Anyone watching the network could read every byte.

Not seeing any output?

Make sure you typed http:// (not https://) for this first request.
Check that you included 2>&1 at the end. Without it, the verbose output goes to a separate stream and may not display.
Ask for help: Why is my curl -v command not showing any output on Windows?

Make an HTTPS request and watch the TLS handshake

That HTTP request was completely transparent. Now you will make the same request over HTTPS and see what changes. HTTPS wraps the entire HTTP conversation inside an encrypted tunnel. The SSL/TLS handshake that creates this tunnel happens before any HTTP data is exchanged.

Send the same request over HTTPS by running this command:

curl -v https://example.com -o NUL 2>&1

The output is dramatically longer this time. Before the familiar HTTP headers appear, you will see an entire handshake negotiation.

What is the TLS handshake?

Look for these lines in the output. They tell the story of how your computer and the server agree on encryption:

* TLSv1.3 (OUT), TLS handshake, Client hello means your computer proposes TLS parameters to the server.
* Server certificate: shows the server proving its identity with a certificate.
The subject: line shows who the certificate belongs to. The issuer: line shows who vouched for it.
* SSL connection using TLSv1.3 / ... confirms the encryption is active and shows the negotiated cipher.

Only AFTER this handshake completes do the familiar HTTP headers appear. But now they travel inside an encrypted tunnel. An eavesdropper sees gibberish instead of your data.

Seeing an SSL certificate error?

Make sure you typed https://example.com exactly. A typo in the domain name may point to a server with an invalid certificate.
If you are behind a corporate proxy or VPN, it may intercept TLS connections. Try disconnecting from the VPN and running the command again.
Ask for help: Why am I seeing an SSL certificate error when running curl -v https://example.com?

Compare HTTP vs HTTPS side by side

You have now seen both exchanges raw. The key insight is that HTTP and HTTPS use the exact same request and response format. The only difference is that HTTPS wraps the entire conversation in a TLS encrypted tunnel BEFORE any HTTP data is exchanged.

What is PKI?

The certificate chain you saw (subject and issuer) is how your browser decides to trust a website. This system is called PKI (Public Key Infrastructure).

If the certificate is invalid, expired, or issued by an untrusted authority, your browser shows a warning. This is the trust layer that secures the modern web.

Before you run the next command, take a moment to predict what you will see. If you filter the HTTPS output for just the TLS version line, what version do you expect to appear?

Confirm TLS is in action by running this filtered command:

curl -v https://example.com -o NUL 2>&1 | findstr "TLSv"

What should I see?

You should see one or more lines containing TLSv1.3, confirming that the connection was encrypted using TLS version 1.3. This is the "S" in HTTPS in action.

You have now seen web traffic both ways. Plaintext HTTP is simple and readable, but completely exposed. HTTPS adds a few hundred milliseconds for the TLS handshake, but makes the connection private and authenticated. Next up, you will do the same kind of raw protocol exploration with email.

Send Email with Raw SMTP Commands

In the last step, you watched the TLS handshake encrypt a web request in real time. You now understand how HTTP and HTTPS work at the protocol level.

Now you are going to apply the same hands-on approach to email. SMTP is the protocol that sends email. It was designed in an era before security was a concern, and you are about to discover the consequences firsthand.

In this step, get ready to:

Send a legitimate email using raw SMTP commands.
Forge a sender address and see it accepted without question.
Inspect raw email headers to understand how real servers detect forgery.

Connect to your mail server and send a legitimate email

Your Mailpit container is already running an SMTP server on port 1025. You are going to connect to it directly using Telnet and speak SMTP by typing each command by hand. This is the same protocol that every mail server in the world uses to deliver messages.

Connect to your local SMTP server by running this command in Command Prompt:

telnet localhost 1025

You should see a greeting starting with 220, confirming you are connected to the Mailpit SMTP server.

Connection refused?

Make sure your Mailpit Docker container is still running. Open a separate Command Prompt window and run:

docker ps

If mailpit is not listed, restart it by running:

docker start mailpit

Then try the telnet command again.

Type these SMTP commands one at a time, pressing Enter after each line:

EHLO mylaptop
MAIL FROM:<alice@example.com>
RCPT TO:<bob@example.com>
DATA
Subject: My First SMTP Email
From: Alice <alice@example.com>
To: Bob <bob@example.com>

Hello Bob, I typed this email one SMTP command at a time!
.
QUIT

What do these SMTP commands do?

EHLO mylaptop introduces your client to the server. The server responds with its capabilities.
MAIL FROM:<alice@example.com> sets the envelope sender address.
RCPT TO:<bob@example.com> sets the recipient address.
DATA tells the server you are about to send the message headers and body.
The headers (Subject:, From:, To:) are followed by a blank line, then the body text.
A single . on its own line marks the end of the message.
QUIT closes the connection.

Return to your browser and open http://localhost:8025.
You should see your email from Alice in the Mailpit inbox. Click on it to read the full message.

Don't see the email in Mailpit?

Make sure you typed the final . on its own line after the message body. SMTP uses this as the end-of-message marker.
Check that you pressed Enter after each command, including after QUIT.
If Telnet disconnected unexpectedly, reconnect with telnet localhost 1025 and start the sequence again from EHLO.

My SMTP email did not appear in Mailpit. What went wrong?

Forge a sender address

SMTP accepted your first email without asking for any credentials. No username, no password, nothing. What happens if you lie about who you are?

Return to Command Prompt and connect to the SMTP server again by running:

telnet localhost 1025

After seeing the greeting, type these SMTP commands one at a time, pressing Enter after each line:

EHLO mylaptop
MAIL FROM:<ceo@bigcorp.com>
RCPT TO:<bob@example.com>
DATA
Subject: Urgent Wire Transfer
From: CEO <ceo@bigcorp.com>
To: Bob <bob@example.com>

Please wire $50,000 to account 12345 immediately.
.
QUIT

What changed this time?

The only difference is the sender address. You told the SMTP server that you are ceo@bigcorp.com in both the MAIL FROM envelope and the From: header. You are obviously not that person. The question is whether SMTP cares.

Before you check the inbox, take a guess. Do you think the SMTP server accepted this email from ceo@bigcorp.com, even though you are clearly not the CEO?

Return to the Mailpit web UI at http://localhost:8025.

The email appears in the inbox, sent from ceo@bigcorp.com. SMTP accepted it without question. No password, no verification, nothing.

Why did the forgery work?

SMTP has zero built-in authentication. When the protocol was designed in the early 1980s, the internet was a small, trusted network of universities. Nobody anticipated that a stranger could forge a sender address.

This is exactly how phishing attacks work today. An attacker types a fake MAIL FROM address and the SMTP server accepts it without checking.

Forged email not showing up?

The same troubleshooting applies as the first email. Make sure you ended the message body with a . on its own line before typing QUIT.
If your Telnet session disconnected, reconnect and start from EHLO again.

My forged SMTP email is not appearing in Mailpit. How can I fix this?

Inspect the raw email headers

The forged email looks convincing in the inbox. Now you are going to look at the raw data behind it to understand what a real mail server would check.

In the Mailpit web UI, click on the forged email from ceo@bigcorp.com.
Look for the headers view in the message detail pane. You should see the full list of raw email headers.

What do the headers reveal?

Notice the From: header says ceo@bigcorp.com. There is also a Return-Path: that matches the envelope MAIL FROM. In this case, both claim the same fake address.

In a real email system, the receiving server compares these values against DNS records to detect forgery. It checks whether the sending server's IP address is authorized to send email for that domain. Your local Mailpit server does not do this check, which is why the forgery worked.

You just proved that SMTP lets anyone send email as anyone. If that feels alarming, good. In the next step, you will look up the real authentication records that prevent exactly what you just did.

Explore Email Authentication and Retrieve Email via POP3

In the last step, you proved that SMTP has zero built-in authentication. The forged email from ceo@bigcorp.com landed in the Mailpit inbox without a single challenge.

If SMTP accepts any sender address, how does the real email system prevent forgery? In this step, you will look up the actual DNS records that protect real inboxes. Then you will retrieve your emails from Mailpit using raw POP3 commands.

In this step, get ready to:

Look up real SPF, DKIM, and DMARC records for gmail.com to see how email authentication works.
Retrieve your emails from Mailpit using raw POP3 commands.
Map every protocol you have used to the OSI Model.

Look up SPF, DKIM, and DMARC records for gmail.com

Three DNS-based systems were invented to solve the exact problem you just exploited. Together, they tell receiving mail servers how to verify that an email actually came from who it claims to be from.

You are going to look up the real records for gmail.com and see exactly how Google prevents the kind of forgery you just performed.

Look up the SPF record

SPF (Sender Policy Framework) tells the world which IP addresses are allowed to send email for a domain. Look it up by running this command in Command Prompt:

nslookup -type=TXT gmail.com 8.8.8.8

In the output, find the TXT record that starts with v=spf1. This record says "only servers listed here are authorized to send email from @gmail.com addresses."

If your laptop's IP address is not on that list, a receiving server should reject or flag your email.

What does the SPF record mean?

The v=spf1 prefix identifies this as an SPF record. The entries after it list authorized mail servers by IP address, domain, or include reference. The record typically ends with ~all or -all, which tells receiving servers what to do with email from unlisted senders.

Think of SPF as a guest list. If your server is not on the list, the bouncer (the receiving mail server) knows to be suspicious.

Look up the DKIM public key

DKIM (DomainKeys Identified Mail) uses cryptographic signatures. The sending server signs each email with a private key, and the matching public key is published in DNS for anyone to verify. Look it up by running:

nslookup -type=TXT 20230601._domainkey.gmail.com 8.8.8.8

You should see a long TXT record containing a base64-encoded public key. Receiving servers use this key to verify that an email claiming to be from Gmail was actually signed by Gmail's servers and was not tampered with in transit.

Not seeing a DKIM key?

Gmail rotates its DKIM selectors over time. The selector 20230601 is a date-based selector that may have been replaced since this project was written. If you get no results, try the google selector instead:

nslookup -type=TXT google._domainkey.gmail.com 8.8.8.8

If that also returns nothing, Gmail may have rotated to a new selector. The concept still holds: every DKIM public key lives at selector._domainkey.domain in DNS.

Help me troubleshoot my DKIM lookup for gmail.com. I tried the 20230601 selector and did not get a result.

How does DKIM work?

When Gmail sends an email, it creates a cryptographic hash of the message body and selected headers, then signs that hash with its private key. The signature is attached to the email as a DKIM-Signature header.

When the receiving server gets the email, it looks up the public key from DNS using the selector in the signature. It then verifies that the signature matches the message content. If anything was changed in transit, the verification fails.

Look up the DMARC policy

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with a policy. It tells receiving servers what to do when authentication checks fail.

Before you run this, predict: what do you think Gmail tells receiving servers to do with emails that fail SPF and DKIM checks? Accept them, quarantine them, or reject them outright?

Look up Gmail's DMARC record by running:

nslookup -type=TXT _dmarc.gmail.com 8.8.8.8

Find the p= value in the DMARC record. This policy tells receiving servers what to do when SPF and DKIM checks fail: none (do nothing), quarantine (mark as spam), or reject (refuse the email entirely).

Why do SPF, DKIM, and DMARC matter together?

SPF alone can be bypassed if an attacker relays through an authorized server. DKIM alone can be stripped from a message in transit. DMARC ties them together by requiring that at least one passes AND that the domain aligns with the From header.

Together, SPF + DKIM + DMARC are why your forged email from ceo@bigcorp.com would never reach a real Gmail inbox. The receiving server would check these DNS records, find that your laptop is not authorized, and reject the message.

What are greylisting and whitelisting?

Greylisting and whitelisting are additional server-side defenses beyond SPF, DKIM, and DMARC.

Greylisting temporarily rejects the first delivery attempt from unknown senders. Legitimate mail servers retry automatically, usually within minutes. Spam bots typically do not retry, so the spam never gets delivered.

Whitelisting is the opposite: pre-approved senders that bypass spam checks entirely. Organizations use whitelists for trusted partners whose email should always be delivered.

Not seeing any TXT records?

Make sure you are connected to the internet. The 8.8.8.8 at the end of each command tells nslookup to query Google's public DNS server directly. If your network blocks outbound DNS on port 53, try removing the 8.8.8.8 to use your default DNS server instead.

Help me troubleshoot my nslookup commands. I am not seeing TXT records for gmail.com.

Retrieve your email using raw POP3 commands

POP3 (Post Office Protocol version 3) is how email clients download messages from a server. You are going to connect to your Mailpit POP3 server and pull down the emails you sent earlier, using the same raw commands that Outlook and Thunderbird use behind the scenes.

Connect to your Mailpit POP3 server by running this in Command Prompt:

telnet localhost 1110

You should see +OK POP3 server ready. This confirms you are connected to Mailpit's POP3 service on port 1110.

Authenticate and retrieve your email by typing these POP3 commands one at a time, pressing Enter after each:

USER testuser
PASS testpass
STAT
LIST
RETR 1
QUIT

What do these POP3 commands do?

USER and PASS authenticate you with the credentials you set when starting Mailpit.
STAT shows the number of messages in the mailbox and their total size.
LIST shows each message's number and size in bytes.
RETR 1 downloads message #1, displaying the full raw email including all headers and body.
QUIT ends the POP3 session and closes the connection.

After running RETR 1, you should see the full raw email you sent earlier, including headers like Subject:, From:, To:, and the message body. You just retrieved email the same way every POP3 client does.

What is the difference between POP3 and IMAP?

POP3 downloads messages from the server to your device and optionally deletes them from the server. Each device gets its own separate copy.

IMAP (Internet Message Access Protocol) keeps messages on the server and syncs them across all your devices. When you read an email on your phone, it shows as read on your laptop too. Most modern email clients use IMAP for this reason.

Connection refused on port 1110?

Make sure your Mailpit container is still running. Open a new Command Prompt and run docker ps to check. If you do not see mailpit in the list, restart it with docker start mailpit.

Help me connect to my Mailpit POP3 server on port 1110.

Map the protocols to the OSI Model

You have now used six different protocols hands-on. Here is every protocol you have used, mapped to the seven layers of the OSI Model:

Layer 7 (Application): DNS, HTTP, SMTP, POP3.
Layer 6 (Presentation): SSL/TLS encryption, MIME encoding in emails.
Layer 5 (Session): TLS handshake establishing secure sessions.
Layer 4 (Transport): TCP (used by HTTP, SMTP, POP3), UDP (used by DNS).
Layer 3 (Network): IP addressing and routing.
Layer 2 (Data Link): Ethernet/Wi-Fi framing.
Layer 1 (Physical): The actual cables, radio waves, or fiber carrying bits.

Why does understanding the layers matter?

Every protocol you touched today sits on top of this stack. Understanding the layers helps you diagnose problems.

If DNS works but HTTP fails, the issue is at Layer 7, not Layer 3. If you can ping a server but cannot load a webpage, the problem is above Layer 3. The layers give you a mental framework for narrowing down where things break.

Secret mission

SSH and SFTP - Secure Remote Access

You have explored how the web and email work at the protocol level. There are two more protocols every IT professional uses daily: SSH for secure remote access and SFTP for encrypted file transfers. In this Secret Mission, you will spin up a remote server, connect to it over an encrypted tunnel, and pull a file back to your machine.

Clean Up Your Resources

This project runs entirely locally using Docker containers, so there are no ongoing costs or cloud charges.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

Docker container mailpit (Mailpit email server with SMTP, POP3, and web UI).
Docker container ssh-server (SSH server from the Secret Mission).
Local file testfile.txt (downloaded via SFTP).

Keep everything running

No action needed. Choose this if you are still actively experimenting with SMTP, POP3, SSH, or any of the other protocol commands you learned.

Your mailpit and ssh-server containers continue running in Docker Desktop.
The Mailpit web UI stays accessible at http://localhost:8025.
You can reconnect to the SSH server at any time with ssh testuser@localhost -p 2222.

Pause - I'll come back to this later

Stop the running containers to free up memory and CPU. Your containers and their data are preserved so you can restart them later.

Stop both containers by running this in Command Prompt:

docker stop mailpit ssh-server

When you are ready to continue, restart them by running:

docker start mailpit ssh-server

Your emails in the Mailpit inbox and any files on the SSH server will still be there when you restart.

Delete - I don't want to use this again

Remove all project containers, images, and files to start completely fresh.

Remove both Docker containers (this also stops them if they are running) by running:

docker rm -f mailpit ssh-server

Remove the Docker images to free up disk space by running:

docker rmi axllent/mailpit lscr.io/linuxserver/openssh-server

Delete the testfile.txt file you downloaded via SFTP. Navigate to the folder where you downloaded it and run:

del testfile.txt

After these commands, all project resources are removed from your machine.

Nice Work!

You just built a hands-on protocol lab and spoke directly to servers using raw commands. You have explored over a dozen network and email protocols from the command line, seeing every step of what normally happens invisibly when you browse the web or send an email.

You've learned how to:

Query DNS records (A, AAAA, NS, MX, TXT) using nslookup, make HTTP and HTTPS requests with curl, and watch the TLS handshake negotiate encryption in real time.
Run your own local mail server with Mailpit, send emails by typing raw SMTP commands, and forge a sender address to prove that SMTP has zero built-in authentication.
Look up real SPF, DKIM, and DMARC records for a live domain, retrieve email using raw POP3 commands, and map every protocol to the OSI Model's seven layers.
Take on an optional Secret Mission to push your protocol skills even further.

Ready to quiz yourself?