RFC 3207 / START HERE
SMTP STARTTLS, before the details
SMTP means Simple Mail Transfer Protocol; TLS means Transport Layer Security. STARTTLS is the SMTP command that begins a TLS upgrade on an existing connection.
Two mail-transfer programs begin an SMTP conversation. If the server advertises STARTTLS and accepts the command, they negotiate TLS before speaking more SMTP on that connection.
The idea in one picture
Request upgrade
Check TLS result
Restart SMTP knowledge
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
It adds a negotiated protection boundary to SMTP. Earlier cleartext traffic is not protected retroactively, and old SMTP knowledge must be discarded after the handshake. Each later mail hop has its own protection decision.
A familiar example
A sending relay upgrades a connection before sending mail, checks the TLS result, and asks for SMTP capabilities again. That protects only the selected hop under its policy, not the message author or the whole delivery chain. Email submission also has later TLS guidance.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Negotiate the boundary between SMTP and TLSSMTP means Simple Mail Transfer Protocol. STARTTLS is a command that switches this existing SMTP connection into a TLS handshake; it does not encrypt earlier traffic.→
- Check the negotiated protection and peerTLS means Transport Layer Security. The handshake negotiates protection; both SMTP parties must check whether its actual result is acceptable.→
- Reset SMTP knowledge and discover capabilities againCompleting TLS resets SMTP to the state just after the original greeting. Old plaintext observations must not silently become trusted TLS-session facts.→
- Distinguish command errors from policy choicesA STARTTLS command can be rejected before TLS begins. A ready reply followed by inability to start the handshake is a different failure.→
- Bound protection to a hop and a service policyMail may cross several SMTP connections. Protecting one connection does not protect earlier traffic, every later hop, stored messages or the message author’s identity.→
This introduction explains RFC 3207 (2002). Read the original RFC ↗