Networking

SMTP

An IoT gateway that emails an alert when a sensor crosses a threshold, or a web app that sends a password-reset link, is doing exactly one thing: handing a message to an SMTP server and trusting it to relay that message onward, hop by hop, until it reaches the recipient's mailbox.

SMTP only sends — a common mix-up

SMTP moves mail forward — from a client to its outgoing server, and from server to server toward the destination. It has no concept of "check my inbox." Retrieving mail from a mailbox is a completely separate pair of protocols, POP3 (downloads and typically removes messages from the server) or IMAP (keeps mail on the server, syncing state like read/unread across multiple devices) — an email client uses SMTP to send and one of those two to receive, and mixing the two up is a very common source of confusion.

The command sequence

A session is a short, readable sequence of plain-text commands:

EHLO

Client greets the server and announces itself (the modern form of the older HELO).

MAIL FROM

Declares the sender's address.

RCPT TO

Declares one recipient — sent once per recipient for a multi-recipient message.

DATA

Everything that follows, until a line with just a single period, is the message headers and body.

QUIT

Ends the session.

Relaying, hop by hop

A message often crosses more than one SMTP server before reaching its destination mailbox — each server along the way is only responsible for handing it to the next one, not for guaranteeing end-to-end delivery in the way TCP guarantees byte delivery. If a hop ultimately fails, the sender doesn't find out inline — a separate bounce message arrives later, asynchronously, itself sent back over SMTP.

Why port 587 exists alongside port 25

Port 25 was SMTP's original port, meant for server-to-server relay — and because that made it a favorite target for spam, most residential and many cloud ISPs now block outbound port 25 entirely for ordinary customers. Port 587 ("submission") exists specifically for a legitimate client authenticating and submitting its own outbound mail — it's expected to require a username/password and TLS, which is why an application sending alert emails almost always connects to port 587, not port 25.

Real-world applications

• IoT/monitoring alert emails — a device or backend service emailing "sensor X crossed threshold Y" is a direct SMTP submission, typically on port 587.
• Transactional email services — providers that handle account-notification, password-reset, and receipt emails on behalf of an application expose an SMTP relay (or an HTTP API that does the same job) so the application never has to run its own mail server.
• Server-to-server mail delivery — every email provider (Gmail, Outlook, and everything else) still ultimately exchanges messages with other providers over SMTP on port 25.

Gotchas