Visual RFC.
ALL RFCs / RFC 3207
Read the RFC ↗
RFC 3207 / SMTP STARTTLS

Distinguish command errors from policy choices

04

A STARTTLS command can be rejected before TLS begins. A ready reply followed by inability to start the handshake is a different failure.

RFC 3207 · § 4EXAMPLE
4 / 4
Distinguish command errors from policy choicesFour distinct failures are explicitly separate. STARTTLS extra gets501because parameters are forbidden and no TLS starts. Wellformed STARTTLS may get454temporary unavailable, still without TLS. A chosen selected-peer policy requiring TLS withholds plaintext MAIL and defers or fails under local timeout policy, with no invented retry interval; other local policies may differ. Another case first received220but cannot start any TLS handshake and follows SHOULD by aborting connection. This is not a failed-handshake fallback algorithm or permission for plaintext commands after220.Separate reply codes from the policy choiceSMTP clientSMTP serverSeparate case: 220 receivedSMTP instead of starting TLSCannot begin handshake → SHOULD abortChosen result: connection closed
04
Abort if the handshake cannot start after 220.

This separate case received 220, but the client cannot start TLS at all. The client follows SHOULD and closes the connection instead of sending the next SMTP command.

Source for this drawing: RFC 3207 · Read RFC section 4 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

A refusal is not permission to downgrade automatically.

  • An invalid parameter gets 501 Syntax error; STARTTLS takes no parameters. A temporary inability to use TLS gets 454.
  • After 454, the client decides according to local policy: continue without TLS, retry later, or give up and notify the sender. RFC 3207 supplies no universal retry interval.
  • After 220 the TLS handshake must come before any other SMTP command. If the client cannot begin it, the client SHOULD abort the connection; do not continue by sending plaintext mail.
DETAILS

The illustrated policy requires TLS for the chosen peer, so the 454 branch defers delivery rather than sending unprotected content. Other policies may make different choices under this RFC; that is not a recommendation for cleartext email submission. No actual message or credentials are transmitted.

Read the RFC section ↗

All chapters in RFC 3207

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗