Port 25: SMTP — The Mail Carrier of the Internet

Port 25 is the original mail carrier of the Internet. Every email you have ever sent, every password reset, every newsletter, every late-night confession typed into a glowing screen has passed through this port. It speaks SMTP, the Simple Mail Transfer Protocol, and it has been delivering the world's messages since 1982.

What Port 25 Does

Port 25 is the default port for SMTP, the protocol that moves email between servers.¹ When you hit "send" on an email, your mail client hands the message to a mail server. That server looks up the recipient's domain, finds the destination mail server, connects to port 25, and delivers your message.

The protocol itself is beautifully simple. Two servers connect, introduce themselves, and have a conversation in plain text:

S: 220 mail.example.com SMTP service ready
C: HELO sender.example.org
S: 250 Hello sender.example.org, pleased to meet you
C: MAIL FROM:<alice@example.org>
S: 250 OK
C: RCPT TO:<bob@example.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Subject: Hello
C: 
C: This is a test message.
C: .
S: 250 OK: Message queued
C: QUIT
S: 221 Bye

That's it. HELO. MAIL FROM. RCPT TO. DATA. A period on a line by itself to say "I'm done." QUIT. This conversation happens 376 billion times a day.²

The Key Mechanism: Store and Forward

SMTP uses a "store and forward" model.³ Your message doesn't travel directly from your computer to the recipient's inbox. It hops between Mail Transfer Agents (MTAs), each one accepting responsibility for delivering it to the next hop, until it reaches its destination.

Each hop is a formal handoff. When a server accepts a message with "250 OK," it is promising to either deliver that message or properly report the failure.⁴ This is the social contract of email: once you accept a letter, you're responsible for it.

The system checks DNS MX (Mail eXchange) records to find where to deliver messages for a given domain. If multiple MX records exist with different priorities, the sender tries them in order, providing redundancy. Email was designed to survive partial network failures, to find a way through.

The History

Before SMTP: Email Over FTP

Email predates the Internet. In the early 1970s, programmers on time-sharing systems could leave messages for each other in shared mailboxes. But these were isolated islands. You could only message people on your own machine.

In 1971, Ray Tomlinson at BBN had an idea. The ARPANET was connecting computers across the country. Tomlinson wrote a program that could send a file to a remote computer and combined it with the local mailbox system.⁵ He introduced the @ sign to separate the username from the machine name. The first networked email was born.

For the next decade, email traveled over FTP, the File Transfer Protocol. It worked, but it was awkward. FTP wasn't designed for mail. It sent separate copies to each recipient. It couldn't handle the specific needs of message delivery.

Jon Postel and RFC 821

Jon Postel, sometimes called the "god of the Internet," had been working on ARPANET protocols since 1969.⁶ He was the RFC Editor, the person who maintained the canonical specifications of Internet protocols. He was also one of the people who saw that email needed its own dedicated protocol.

In November 1981, Postel published RFC 788, the first SMTP specification.⁷ In August 1982, he published RFC 821, the definitive version.⁸ This document specified port 25 as the contact socket for SMTP:

This protocol is assigned the contact socket 25 (31 octal), that is L=25.

RFC 821 borrowed commands from FTP but reimagined them for mail. MAIL FROM and RCPT TO came from FTP's mail handling, but now they had a dedicated protocol with a dedicated port.

Sendmail: The First Major Implementation

In 1983, Eric Allman at UC Berkeley released Sendmail, one of the first Mail Transfer Agents to implement SMTP.⁹ It shipped with BSD 4.1c, the same BSD release that included TCP/IP. By 1996, approximately 80% of the mail servers on the Internet ran Sendmail.¹⁰

Allman's work solved a practical problem: the ARPANET consisted of many smaller networks with different email formats. Sendmail could translate between them all, routing messages through the growing patchwork of connected networks.

The Open Relay Problem

SMTP was designed in an era of trust. The ARPANET was a small community of researchers and engineers who knew each other. The protocol assumed good faith.

Port 25 was open by default. Any server could connect, say HELO, and send mail. There was no authentication, no verification. If a server accepted your connection, it would relay your message onward.

In the 1990s, spammers discovered this.¹¹ They could connect to any mail server with an open port 25, send millions of messages, and disappear. The "open relay" feature became the primary vector for spam. Someone else's server paid the bandwidth costs while the spammer collected the profits.

The response came in layers. Server administrators learned to close their relays, requiring authentication before accepting mail for delivery. In 1998, RFC 2476 proposed separating mail submission from mail relay.¹² Port 587 would handle authenticated submission from users to their own mail servers. Port 25 would be reserved for server-to-server relay.

Today, many ISPs block outbound port 25 for residential customers entirely.¹³ This isn't censorship; it's spam prevention. Your phone doesn't need port 25. Only mail servers need port 25.

Security Considerations

SMTP was designed when the Internet was a trusted network of colleagues. It has the security properties of a postcard: anyone handling the message can read it.

No native encryption. SMTP traffic on port 25 travels in plaintext by default. The STARTTLS extension, introduced later, allows servers to upgrade to encrypted connections, but it's opportunistic. A sophisticated attacker can strip the encryption offer and read messages in transit.

No sender verification. The MAIL FROM address can say anything. The protocol doesn't verify that the sender owns the address they claim. This is why email spoofing exists, and why we've built additional systems like SPF, DKIM, and DMARC to verify senders after the fact.

Open to enumeration. Commands like VRFY and EXPN can be used to probe a server for valid email addresses. Most modern servers disable these commands, but older or misconfigured servers may still expose them.¹⁴

Target for attacks. Notable vulnerabilities include Exim CVE-2019-10149 and OpenSMTPD CVE-2020-7247, which allowed remote code execution through carefully crafted email messages.¹⁵

Postel's Law

Jon Postel embedded a philosophy in his protocols. RFC 1122 states it directly:¹⁶

Be liberal in what you accept, and conservative in what you send.

This became known as Postel's Law or the Robustness Principle. It meant that SMTP servers should try to make sense of malformed messages rather than rejecting them outright. It prioritized getting mail through over enforcing strict compliance.

This principle helped email grow. Servers could interoperate even when they didn't implement the protocol identically. But it also created security problems. Being "liberal in what you accept" meant accepting things that should have been rejected. Attackers exploited the gap between what the specification said and what servers actually accepted.¹⁷

Related Ports

• Port 587 — SMTP Submission. This is where your email client connects to send mail. Unlike port 25, it requires authentication.¹²
• Port 465 — SMTPS. Originally registered for SMTP over SSL in 1997, then deprecated, then resurrected in RFC 8314 (2018) for implicit TLS.¹⁸
• Port 110 — POP3. Retrieves email from a server to your local client.
• Port 143 — IMAP. Accesses email stored on a remote server, keeping it synchronized across devices.
• Port 993 — IMAPS. IMAP with implicit TLS encryption.
• Port 995 — POP3S. POP3 with implicit TLS encryption.