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

Check the negotiated protection and peer

02

TLS means Transport Layer Security. The handshake negotiates protection; both SMTP parties must check whether its actual result is acceptable.

DIAGRAMRead RFC section 4.1 ↗
RFC 3207 · § 4.1EXAMPLE
4 / 4
Check the negotiated protection and peerFour security-assessment moments. Client and server exchange abstract TLS handshake records, without choosing obsolete protocol versions. A separate SMTP Submission example applies RFC7817: during negotiation, certificate path validation precedes comparing expected mail.example with a certificate DNS-ID. A matching string alone is not a verified certificate. After handshake completion both sides immediately assess authentication and privacy and a chosen path accepts. Separate inadequate-protection alternative follows client SHOULD and sends QUIT; server refusal would use554for nonQUIT commands. RFC7817 does not apply to MTA-to-MTA SMTP.Check what the handshake actually achievedSMTP clientMail serverQUIT after completed TLSSeparate result: policy not satisfiedClient SHOULD send QUITServer refusal alternative: 554 except QUITNot a TLS-handshake failure code
04
Stop when local policy rejects the result.

In the separate insufficient-protection alternative, the client follows SHOULD and sends QUIT. A server making its own refusal should use 554 for non-QUIT commands; these are alternative roles, not a fabricated handshake failure code.

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

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

RFC 5321 SMTP RFC 8446 TLS 1.3 RFC 5280 X.509 certificates

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.

What changed
RFC 3207 §4.1 original identity discussionRFC 7817 §3 and Appendix A

RFC 7817 replaces the identity-check paragraph with the Submission-client procedure in §3. It explicitly excludes MTA-to-MTA SMTP; it does not replace STARTTLS negotiation or reset rules.

Read the updated RFC section ↗
KEY POINT

Handshake completion alone is not a security-policy decision.

  • After the TLS handshake, both parties MUST immediately decide whether to continue based on the authentication and privacy actually achieved.
  • RFC 7817 updates this section for SMTP Submission clients: during negotiation, check the expected server identity against its certificate only after certification-path validation. Its scope excludes MTA-to-MTA SMTP.
  • If protection is insufficient, the client SHOULD send QUIT immediately after negotiation. A refusing server SHOULD reply 554 to every SMTP command except QUIT.
DETAILS

The chosen exact DNS-ID example assumes certificate-path validation succeeded; it is not a certificate verifier. Full reference-identifier selection and matching are outside this guide; follow RFC 7817 and current TLS guidance rather than using this example as a verifier. MTA-to-MTA means between mail transfer agents, or relaying mail servers. No obsolete TLS version or cipher suite is prescribed; modern configuration guidance is RFC 9325.

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 ↗