Submission and delivery
Protect and authenticate submission
Separate transport encryption, certificate validation, and user authentication in an SMTP connection.
8 minute lesson
TLS encrypts a connection and lets the client validate the server certificate. Authentication proves which account is submitting mail. They solve different problems.
On port 587, a client can issue STARTTLS, complete a TLS handshake, and send EHLO again because the protected connection has a fresh capability state. It should authenticate only after encryption is active.
On port 465, TLS begins immediately. Modern clients should not send passwords over a cleartext connection, and they should not ignore certificate errors just to make setup appear to work.
A protected submission exchange looks like this:
C: EHLO laptop.example
S: 250-STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
... TLS handshake ...
C: EHLO laptop.example
S: 250-AUTH PLAIN OAUTHBEARERThe second EHLO is not optional cleanup. TLS resets the SMTP capability knowledge, and the server may advertise authentication only inside the protected channel.
An AUTH mechanism defines how credentials or tokens are exchanged. It does not encrypt the connection. Even a base64-looking credential is readable without TLS. Prefer short-lived tokens when the provider supports them, and never place secrets in transcripts or URLs.
Certificate validation checks that the certificate chains to a trusted authority, is valid for the submission hostname, and is within its validity period. A successful encryption handshake with the wrong host is not a safe connection.
Draw the state before TLS, during the handshake, and after the second EHLO. Mark the earliest point where authentication is allowed.
Lesson completed