Core CS · Computer Networks
One protocol pushes. Another has to pull.
Email and FTP are the two oldest application protocols you will be asked about, and both split their job in a way that surprises people. Every answer here comes down to one question: which side opens the connection?
Run the same transfer in active and passive mode, and watch the router decide →01 The idea
Sending mail and reading mail are two different jobs
Start with what actually moves. When you send mail, the message travels away from you and toward a machine you have never logged into. When you read mail, it travels toward you from a machine you own an account on. Those are opposite directions, and in a client-server protocol the direction of travel is decided by whichever side dialled. That single asymmetry is why email needs two protocols rather than one, and it is the thing a well-answered interview question turns on.
Three programs are involved, and they have names worth using. The mail user agent is what you type in: Thunderbird, Outlook, the Gmail app. The mail transfer agent is the server-side relay that carries a message from one organisation to another: Postfix, Exim, Sendmail. The mail delivery agent is the last step, the program that takes an accepted message and writes it into the right person’s mailbox on disk. Mail moves from agent to agent, and SMTP, the Simple Mail Transfer Protocol, is the protocol for every hop between agents, from your app all the way to the server that owns the recipient’s mailbox. The final handover from that server to the delivery agent happens inside one machine and is the only part of the journey SMTP does not have to carry.
Then it stops. SMTP is a push protocol in the strict sense: the sender opens the connection, announces who the message is from and who it is for, and hands the bytes over. There is no command in SMTP that means show me what is in that mailbox, and there could not usefully be one, because your phone is not a server. It has no fixed address, it is asleep half the day, and it sits behind a network that refuses unsolicited inbound connections. A mailbox on a server cannot dial your phone. Your phone has to dial the server. So a second, pulling protocol is required, and there are two of them: POP3 and IMAP, which differ on one question, namely where does the real copy of your mail live.
FTP, the File Transfer Protocol, splits its job along a completely different seam and is asked about for exactly that reason. It uses two TCP connections at once. One is the control connection, opened at login and held open for the whole session, and it carries nothing but short text commands and three-digit reply codes. The other is a data connection, opened fresh for every single file or directory listing and closed when that transfer ends. Keeping commands out of the data stream is a genuinely good design, and it also creates the one problem this lesson spends its console on: in the original scheme, it is the server that opens the data connection, back toward the client, and modern client networks drop exactly that kind of connection.
02 Worked example
One message from Asha to Ravi, hop by hop
Asha, at asha@examate.in, sends one message to Ravi at ravi@nitk.ac.in. Follow it left to right and watch which side opens each connection, because that is the only detail that changes between the boxes. The highlighted box is the one SMTP structurally cannot perform, and it is where every "why do we need POP3 or IMAP at all" question lands.
Now the dialogue on hop 2, because being able to recite it is worth marks and it makes the push visible line by line. The receiving server speaks first with 220, then every line is a command from the sender and a coded reply from the receiver: EHLO mail.examate.in answered with 250 and a list of extensions; MAIL FROM:<asha@examate.in> answered 250 OK; RCPT TO:<ravi@nitk.ac.in> answered 250 OK, once per recipient; DATA answered 354 Start mail input; then the headers and body, terminated by a line containing a single full stop, answered 250 Queued; then QUIT and 221. Every command is issued by the side that has the message. At no point does the receiver ask for anything.
That is the mechanical proof of the structural claim. There is nothing in that dialogue you could turn around. A command like RCPT TO announces a destination; there is no GIVE ME. If you wanted SMTP to deliver Ravi’s mail to his phone, his phone would have to be running an SMTP server, listening on a stable address, permanently reachable from the internet, so that his provider could dial it. That is exactly the arrangement organisations use for their mail servers, and exactly the arrangement no laptop or phone can offer.
Two details in box 1 that get asked about on their own. First, why 587 and not 25, when both are SMTP. They are the same protocol serving two different roles. Port 25 is for relay, MTA to MTA, and accepts mail from strangers without a password because that is what interconnecting the world’s mail requires. Port 587 is the submission port, where a server accepts mail only from its own authenticated users. Splitting them lets a network block outbound port 25 from ordinary machines to stop compromised laptops spraying spam directly at the world, while leaving 587 open so real mail clients still work. Nearly every residential ISP and cloud provider does block outbound 25 for that reason, so an application that tries to send mail by connecting to port 25 from a cloud VM usually hangs until it times out. Port 465 is the same submission job with TLS from the first byte instead of upgrading mid-session, and RFC 8314 brought it back as the recommended option after years of it being called deprecated.
Second, MIME, in the one clause it deserves. SMTP was defined to carry 7-bit US-ASCII text and nothing else, so a photograph cannot be put into a message as it stands. MIME is the set of headers that solves this without changing SMTP at all: Content-Type declares what a part actually is, and Content-Transfer-Encoding declares how it was rewritten into printable characters for the journey, almost always base64 for binary and quoted-printable for text that is mostly ASCII. The receiving client reads those headers and reverses the encoding. That is the whole trick, and it is why attachments arrive larger than the file on disk.
03 Mechanics
The retrieval table, the two connections, and the three names
Three tables, in the order the questions come. The first is the one to be able to reproduce from memory, because "POP3 or IMAP, and why" is the single most asked question in the application layer. Read it as one decision repeated down the rows: where does the authoritative copy live. Every other difference follows from that answer.
| Property | POP3 · port 110 | IMAP · port 143 |
|---|---|---|
| Storage location | on the client device | on the server |
| Default after download | the server copy is deleted | nothing is removed |
| Multiple devices | each device sees a different subset — whichever one collected a message has it, and the others never will | every device sees one mailbox, because there is only one mailbox and all of them are looking at it |
| Working with no network | complete — the mail is already on disk, and this is the first of the two things POP3 is genuinely better at | only what the client cached — the protocol itself needs the server for every operation |
| Server storage used | close to none — and this is the second | grows with the mailbox — this is why providers quote a quota in gigabytes |
| Folder support | none — POP3 knows exactly one mailbox and has no command to create or list another | server-side folders, created, renamed and moved between over the protocol itself |
| Message flags | not carried — read and unread is a note your one client keeps to itself | kept on the server — \Seen, \Answered, \Flagged, \Deleted, shared by every client |
| Fetching part of a message | almost none — RETR takes the whole message; TOP n gets the headers plus the first n body lines, and that is the limit | yes — fetch headers alone, one MIME part alone, or a byte range, so a phone can list 500 subjects without downloading one attachment |
| Searching | on the client only, over what it happens to hold | on the server — SEARCH runs across the whole mailbox |
| Over TLS | 995 | 993 |
Read the first two rows together, because that is the exam answer in one line. POP3 moves mail from the server to one device. IMAP mirrors a mailbox that stays on the server. Everything else in the table is a consequence: if the mail is on one device, there are no folders to synchronise and no flags to share and nothing to search remotely, and equally there is no quota to hit and no network needed to read what you already have. POP3 was designed in an era of one computer per person and a dial-up link paid for by the minute, and for that era it was the right answer.
The detail that catches people out about POP3’s deletion. A POP3 session moves through three states: AUTHORIZATION while you log in, TRANSACTION while you list and retrieve, and UPDATE at the end. DELE during a session does not delete anything; it only marks the message. The deletion actually happens in the UPDATE state, when the client sends QUIT. Drop the connection without a clean QUIT and every mark is discarded and nothing is removed. Note also that "by default it deletes" is the protocol’s design, not an unchangeable law: every real client offers a setting that skips the delete and leaves the server copy in place.
Now FTP, and the shape that makes it worth teaching. One session, two connections, doing two different jobs.
| Control connection | Data connection | |
|---|---|---|
| Server port | 21, always | 20 in active mode only — in passive mode it is a high port the server chooses and announces |
| How many | exactly one per session | one per transfer or listing, opened and closed each time |
| Lifetime | opened at login, held for the whole session | seconds — it exists only while bytes are moving |
| Carries | commands and 3-digit replies — USER, PASS, PASV, RETR, STOR, LIST, QUIT | file bytes and directory listings, and nothing else, ever |
| Who opens it | always the client | the server in active mode, the client in passive mode — this row is the entire lesson |
| End of file marked by | not applicable | the connection closing — there is no length field, so the close is the delimiter |
Active mode, and the exact packet that dies. In active mode the client picks a port, starts listening on it, and sends PORT h1,h2,h3,h4,p1,p2 over the control connection: four bytes of IP address and two bytes of port, so PORT 192,168,1,7,156,64 means connect to 192.168.1.7 on port 156 × 256 + 64 = 40000. The server then opens the data connection inbound, from its own port 20 to that address and port. Put a NAT router in front of the client and that connection is dead twice over. The address in the PORT command is the client’s private RFC 1918 address, which no router on the internet will forward to; and even if the client wrote the router’s public address instead, the arriving SYN matches no translation entry, because NAT builds its table from packets going out. The router has no way to know which machine behind it the packet is for, so it drops it. Unsolicited inbound is precisely what NAT is unable to deliver.
Passive mode, and why it is the default today. The client sends PASV. The server picks a port, starts listening, and replies 227 Entering Passive Mode (203,0,113,10,195,80) — the same six bytes, so port 195 × 256 + 80 = 50000. Now the client opens the data connection outbound, exactly as it opened the control connection. The router creates a translation entry on the way out and happily translates the replies coming back, because they now match something. Note carefully that only the direction of connection setup changed: the file bytes still travel from server to client on a download. Reversing who dialled fixed the problem without reversing who sends. Many routers and firewalls ship an FTP application-layer gateway that reads the control connection in plaintext, spots a PORT command or a 227 reply, and opens a temporary pinhole for the port it names. That is a middlebox reading and rewriting an application’s text to keep a protocol working, and it stops working the moment the control connection is encrypted. Treat it as a workaround, not as a reason to use active mode.
Finally, three names that students blur together, and they are not three versions of one thing.
| Name | What it actually is | Ports | Connections | Credentials on the wire |
|---|---|---|---|---|
| FTP | RFC 959, the original, entirely in plaintext | 21 control, 20 or a negotiated port for data | two | readable by anyone on the path |
| FTPS | The same FTP with TLS wrapped around it. Explicit FTPS starts on 21 and upgrades with AUTH TLS; implicit FTPS is TLS from the first byte. | 21 explicit, 990 implicit, plus data | two | encrypted |
| SFTP | not FTP at all — a different protocol that runs as a subsystem inside an SSH session, sharing nothing with RFC 959 | 22, the SSH port | one | encrypted |
The honest closing sentence on plain FTP. It sends the username and the password as readable text on the control connection, and every byte of every file unencrypted on the data connection. Anyone able to see the traffic reads both, and can rewrite either. It should not be used for anything that matters, and if you are asked to move files today the answer is SFTP over SSH, or HTTPS, or a cloud object store, with FTPS as the option when a counterparty specifically requires FTP semantics. Say that out loud in an interview; being able to name what is wrong with a protocol is worth more than being able to recite it.
05 Cheat sheet
The answers that get asked, and the wrong ones that get given
Every row is something you should be able to state in under ten seconds. The right-hand column is the specific wrong answer that gets written down, not a general caution.
| What they ask | The answer | The trap |
|---|---|---|
| SMTP port, server to server | 25 | giving 25 for a mail client sending — that is 587 |
| SMTP port, client submitting | 587 · 465 for TLS from the first byte | Calling 587 "secure SMTP". It is the submission port; the encryption is a separate matter. |
| POP3 and IMAP ports | 110 and 143 · 995 and 993 over TLS | assuming the TLS pair keeps the same order — in plaintext POP3 is the lower number, 110 against 143, but over TLS it flips: POP3S is 995 and IMAPS is 993 |
| Why a second protocol at all | SMTP can only push toward a mailbox | Saying "because POP3 is for receiving". Name the direction and who dials. |
| POP3 versus IMAP in one line | POP3 moves mail to one device; IMAP keeps it on the server and syncs state | Listing features without naming where the authoritative copy lives. |
| What POP3 is genuinely better at | offline use, and near-zero server storage | Claiming POP3 has no advantages. It has those two, and both are real. |
| What MIME adds | Content-Type and Content-Transfer-Encoding | Saying "MIME sends attachments". It re-encodes them so a 7-bit text protocol can carry them. |
| FTP ports | 21 control, 20 data in active mode | saying data is always 20 — in passive mode the server picks a high port |
| Who opens the data connection | active: the server · passive: the client | memorising the two words with no direction attached |
| Why passive is the default | the client dials out, so NAT and client firewalls pass it | Saying passive is "more secure". It is not; it is more reachable. |
| What ends a file transfer in FTP | the data connection closing | Looking for a length field. There is none. |
| FTPS versus SFTP | FTPS is FTP plus TLS · SFTP is an SSH subsystem on 22 | calling SFTP "secure FTP" — it shares no code and no design with FTP |
| FTP reply codes worth knowing | 220 ready · 230 logged in · 227 passive · 150 opening data · 226 complete · 425 cannot open data | Quoting HTTP codes. FTP has its own, and 425 is the one active mode behind NAT produces. |
06 Where & why
These are configuration lines you will actually edit
None of this is a teaching abstraction. The port numbers and mode names in this lesson are literal values in configuration files and command-line flags on systems you will meet, and each of the four below is somewhere you can watch this lesson’s one question — who dials — decide how software is built.
Postfix is the MTA. Its master.cf has one entry for smtp on port 25, taking relay from other servers, and a separate submission entry on 587 that switches on smtpd_tls_security_level = encrypt and demands SASL authentication. Postfix hands accepted mail to Dovecot, which is the delivery agent and also the POP3 and IMAP server, listening on 110, 143, 995 and 993. Seeing them as two programs makes the split in this lesson concrete: nothing in Postfix can read a mailbox, and nothing in Dovecot can relay a message.
Under Forwarding and POP/IMAP, "Enable POP" comes with a menu reading keep Gmail’s copy, archive it, or delete it — that menu exists purely because of POP3’s default. IMAP is what the phone apps use, and Gmail maps its labels onto IMAP folders, which is why a message with two labels appears in two folders in Thunderbird and why [Gmail]/All Mail looks like a duplicate of everything. The read and starred state you set on the phone appears on the laptop because those are IMAP flags held on the server.
curl ftp://host/file uses passive mode unless you tell it otherwise; curl -P - switches it into active mode and asks curl to work out the address to put in the PORT command. Run the second one from a laptop on home Wi-Fi and it hangs and then fails, which is this lesson’s console reproduced in one command. FileZilla makes the same choice in Settings under Transfer Mode, defaulting to passive, and its "server sent passive reply with unroutable address" warning is a NATed server announcing its own private address in the 227 reply.
SFTP is not a daemon you install. It is a subsystem of the SSH server, switched on by the line Subsystem sftp /usr/lib/openssh/sftp-server in sshd_config, and it runs entirely inside an existing SSH session on port 22. There is no control connection, no data connection, no active or passive choice, and nothing for a NAT device to rewrite, because there is only ever one TCP connection and the client opened it. Firewall rules become one line, which is most of why file transfer moved here.
07 Interview questions
What they ask, and what they follow up with
Two of these come up in almost every application-layer interview: "POP3 or IMAP" and "why does FTP need two connections". Neither is asked once. The follow-up to the first is usually about multiple devices or offline use, and the follow-up to the second is always active versus passive. Name the port number and the direction in your first sentence, every time.
Take me through what happens between Asha pressing send and Ravi seeing the message on his phone.
Why can SMTP not be used to read your mail?
SMTP is one protocol. Why does it have two port numbers?
POP3 or IMAP: what actually differs?
When you press delete in a POP3 client, what has actually happened on the server?
What is MIME, and why did email need it?
Why does FTP use two connections instead of one?
Active mode versus passive mode: which side does what?
Somebody tells you they are using SFTP because it is the secure version of FTP. What do you say?
Is plain FTP acceptable for anything today?
Why do modern services move files over HTTPS instead of any of these?
08 Practice problems
Six to work on paper
For each one, write down which side opens each connection before you write anything else; three of the six turn entirely on that, and two more turn on where the authoritative copy of a mailbox lives. Two of them need arithmetic rather than recall, and neither is arithmetic you can do in your head on the first try.