Просто хотел обратить на это внимание, поскольку, похоже, это стало распространённым заблуждением: порт 587 — это не «будущее», а невидимый TLS через порт 465.
Меня привела к этому революционная статья.
После прочтения актуального RFC от 2018 года всё становится ясно: дело не в том, что STARTTLS — это путь вперёд, а в том, что SMTPS — это не путь вперёд. Администраторам следует выбирать невидимый TLS через порт 465 (или 587) для будущего.
Поддержка TLS через порт 587 не должна классифицироваться (и, вероятно, должна быть деприоритизирована) как «обеспечение обратной совместимости» или что-то подобное.
Механизм STARTTLS на порту 587 распространён относительно широко из-за ситуации с портом 465 (обсуждается в разделе 7.3). Это отличается от сервисов IMAP и POP, где невидимый TLS развёрнут на серверах более широко, чем STARTTLS. Желательно со временем перейти на использование невидимого TLS для основных протоколов, используемых программным обеспечением MUA, как для обеспечения единообразия, так и по дополнительным причинам, обсуждаемым в Приложении A. Однако для максимального использования шифрования при отправке сообщений желательно поддерживать оба механизма для передачи сообщений через TLS в течение переходного периода в несколько лет. В результате клиенты и серверы ДОЛЖНЫ реализовать как STARTTLS на порту 587, так и невидимый TLS на порту 465 в течение этого переходного периода. Обратите внимание, что если реализации корректны и если как клиент, так и сервер настроены на требование успешного согласования TLS перед отправкой сообщений, то между свойствами безопасности STARTTLS на порту 587 и невидимого TLS на порту 465 нет существенной разницы.
Переход происходит не к submissions через порт 587 с использованием STARTTLS, а к submissions через невидимый TLS на порту 465 (в отличие от SMTPS через порт 465, который теперь устарел).