Reset SMTP knowledge and discover capabilities again
03Completing TLS resets SMTP to the state just after the original greeting. Old plaintext observations must not silently become trusted TLS-session facts.
With an acceptable TLS result and the fresh EHLO reply, the client begins MAIL FROM:<a@example.com>. A second STARTTLS attempt is prohibited while TLS is active.
Source for this drawing: RFC 3207 · Read RFC section 4.2 ↗
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.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Discard old SMTP knowledge before rebuilding it inside TLS.
- The server MUST discard knowledge from the client that did not come from TLS, such as the earlier EHLO argument. The client MUST discard earlier server knowledge, such as the extension list.
- The client SHOULD send EHLO first after successful TLS negotiation. The new extension list MAY differ from the earlier list; do not assume an extension survived.
- Both parties MUST know whether TLS is active. The client MUST NOT start another TLS session when one is active, and the server MUST NOT advertise STARTTLS after the handshake.
This chosen ESMTP path follows the EHLO recommendation, then starts a fresh mail transaction only after the TLS result is acceptable. Reset means the state after a greeting; the example does not wait for a second SMTP greeting. SIZE numbers and capability changes are illustrative, not required server defaults.
Read the RFC section ↗