Я пытаюсь понять, как именно работает команда STARTTLS в IMAP и что меняется при ее отправке. После того, как я отправил команду «STARTTLS» перед процессом входа в систему и получил ответ «ОК, начать согласование TLS сейчас» в качестве клиента, что-либо изменится для меня как клиента в последующих командах API, то есть формат запросов и ответы, некоторая дополнительная информация, которую я должен обработать, и т. д.? Я имею в виду уровень API, а не низкий уровень.
Проверьте RFC на предмет такого рода вещей. Они могут ответить на многие ваши вопросы.
https://tools.ietf.org/rfc/index
Это то, что вам нужно:
RFC3501 ПРОТОКОЛ ДОСТУПА К ИНТЕРНЕТ-СООБЩЕНИЯМ - ВЕРСИЯ 4rev1
https://tools.ietf.org/html/rfc3501
Abstract
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
allows a client to access and manipulate electronic mail messages on
a server. IMAP4rev1 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local
folders. IMAP4rev1 also provides the capability for an offline
client to resynchronize with the server.
IMAP4rev1 includes operations for creating, deleting, and renaming
mailboxes, checking for new messages, permanently removing messages,
setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching,
and selective fetching of message attributes, texts, and portions
thereof. Messages in IMAP4rev1 are accessed by the use of numbers.
These numbers are either message sequence numbers or unique
identifiers.
IMAP4rev1 supports a single server. A mechanism for accessing
configuration information to support multiple IMAP4rev1 servers is
discussed in RFC 2244.
IMAP4rev1 does not specify a means of posting mail; this function is
handled by a mail transfer protocol such as RFC 2821.
Что будет после STARTTLS
6.2.1. STARTTLS Command
Arguments: none
Responses: no specific response for this command
Result: OK - starttls completed, begin TLS negotiation
BAD - command unknown or arguments invalid
A [TLS] negotiation begins immediately after the CRLF at the end
of the tagged OK response from the server. Once a client issues a
STARTTLS command, it MUST NOT issue further commands until a
server response is seen and the [TLS] negotiation is complete.
The server remains in the non-authenticated state, even if client
credentials are supplied during the [TLS] negotiation. This does
not preclude an authentication mechanism such as EXTERNAL (defined
in [SASL]) from using client identity determined by the [TLS]
negotiation.
Once [TLS] has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue the
CAPABILITY command. This is necessary to protect against man-in-
the-middle attacks which alter the capabilities list prior to
STARTTLS. The server MAY advertise different capabilities after
STARTTLS.
Example: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under [TLS] layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed