I'm trying to understand how the command STARTTLS in IMAP works exactly and what becomes different when it's sent. After I've sent the command "STARTTLS" before login process and received the response "OK Begin TLS negotiation now" as a client, does anything change for me as a client in the futher communication, that is, the format of the requests and responses, some additional information, etc? I mean the API level, not the lower levels.
closed as off-topic by Stephen Harris, ilkkachu, Michael Homer, Julie Pelletier, Scott Aug 14 '16 at 6:47
- This question does not appear to be about Unix or Linux within the scope defined in the help center.
STARTLS process tells the client and server to start negotiating an encrypted connection, so all further data will be TLS (SSL, close enough) encrypted. This will prevent people from sniffing your traffic (eg usernames, passwords).
Now some servers can be configured to provide different services; for example an IMAP server may refuse to allow the LOGIN command over a plain connection but will allow it over a TLS encrypted connection.
We can see the difference. In this example, for a normal IMAP connect we are shown:
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED] Dovecot ready.
Note the "LOGINDISABLED" part.
If we connect to the same server via TLS
* CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN
Now we can see "AUTH" is available, so I can attempt a login.
IMAP isn't the only service that may work this way; eg SMTP with plain connections:
250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN
And with TLS
250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-AUTH PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN
Again there's a new
AUTH command available.