Every time you hit "Send" in your email client, your message leaves on port 587 — not port 25. This seemingly minor distinction is the entire contribution of RFC 4409, and it fundamentally changed how email works on the internet. Before this RFC, the act of a user composing and submitting a message was conflated with the act of a server relaying that message to its destination. Separating these two operations turned out to be one of the most consequential anti-spam decisions ever made.

The Problem: One Port to Rule Them All

In the original email architecture, port 25 handled everything. Your Outlook client connected to port 25 to send mail. Your company's mail server connected to port 25 on Gmail's server to deliver that mail. A spammer's botnet also connected to port 25 to blast millions of messages. There was no protocol-level way to distinguish a legitimate user submitting a new message from a random server relaying traffic. This created a cascade of problems:

• ISPs couldn't block outbound spam without also blocking legitimate mail submission
• Servers couldn't enforce authentication for submission without breaking relay
• There was no clean place to apply policy differences — submission needs authentication and identity checks; relay needs routing and loop detection

The Solution: Port 587 and the MSA

RFC 4409 (updating the earlier RFC 2476) formalized the Mail Submission Agent (MSA) as a distinct role from the Mail Transfer Agent (MTA). The MSA listens on port 587 and has fundamentally different responsibilities:

• Authentication is required. The MSA MUST offer and SHOULD enforce SMTP AUTH. This is the single biggest difference — relay doesn't require auth, submission does.
• Message fixup is permitted. The MSA can add missing Date: headers, fill in the sender's domain, and normalize addresses. An MTA doing relay should not modify messages this way.
• Policy enforcement is expected. The MSA can reject messages with invalid From: headers, enforce size limits per user, and apply rate limiting — things that make no sense for relay.
• TLS is strongly encouraged. The RFC pushes for STARTTLS on the submission channel, protecting credentials in transit.

Why the Split Mattered for Spam

Once submission had its own port, ISPs could do something revolutionary: block outbound port 25 for residential customers. If your laptop can't connect to port 25 on arbitrary servers, a botnet running on your machine can't relay spam directly. You can still send mail normally through your provider's MSA on port 587 with your credentials. This single firewall rule — dropping outbound port 25 — eliminated a staggering volume of spam from compromised home machines. By the late 2000s, most major ISPs had implemented this block.

Modern Relevance

Today, every major email provider enforces the submission/relay split. When you configure an email client, the "outgoing server" settings are always port 587 (or 465 for implicit TLS, revived by RFC 8314). Cloud providers like AWS, GCP, and Azure block outbound port 25 by default on new instances — a direct descendant of this RFC's architecture. If you've ever wondered why your freshly provisioned VM can't send email, RFC 4409 is the reason. The separation also laid groundwork for modern email authentication standards like SPF, DKIM, and DMARC, which all depend on being able to distinguish submission from relay in policy.

The RFC itself is a concise, readable 20 pages — a model of practical protocol engineering that solved a real operational crisis without requiring a new protocol, just a clear separation of roles on an existing one.