![](https://habrastorage.org/webt/pj/a_/os/pja_osqbo80fknqvjnkwxjfdqma.png)
При настройке сервера исходящей почты на почтовом клиенте вы видите 3 опции для шифрования — без шифрования, SMTPS и STARTTLS, а также 3 возможных порта — 25, 465, 587. Что тут выбрать и для чего — давайте разбираться.
Видео
Previous < Режимы работы почтовых серверов
Next > DNS записи для почтовых серверов
![](https://habrastorage.org/webt/xd/iz/0b/xdiz0b5aiuipl9f9oylqxannogi.png)
Когда вы отправляете кому-то сообщение, ваш почтовый клиент использует протокол ESMTP для передачи этого сообщения, а затем ваш почтовый сервер использует тот же протокол, если ему нужно передать это сообщение на другой сервер. И хотя все говорят и пишут SMTP, речь обычно идёт про ESMTP – тот же самый SMTP, но с набором расширений, таких как авторизация и шифрование. Да, когда-то SMTP не поддерживал даже авторизацию.
![](https://habrastorage.org/webt/q8/zz/xc/q8zzxcz0tpk86ealobs3ghe6hd4.png)
Теперь немного про SMTPS. Когда-то интернет был настолько простым, что всё в нем передавалось в открытом виде. Потом появились криптографические протоколы шифрования, тот же самый SSL. И сервисы, которые раньше передавали информацию в открытом виде, начали заворачивать трафик в SSL.
![](https://habrastorage.org/webt/vi/ly/sg/vilysgbdveruivjlnd6bx00uk2o.png)
Но сделать это на тех же стандартных портах оказалось непросто – клиент и сервер должны договориться о методе шифрования, а чтобы сервис на одном порту одновременно работал для одних с шифрованием, а для других без – требовало бы изменений в протоколах. И чтобы не усложнять всё, начали лепить отдельные порты для шифрованных соединений – так появился 443 для HTTPS и 465 для SMTPS. Но тут спохватились – выделенных портов мало, количество сервисов растёт, а если еще каждый для своих целей будет использовать по несколько портов с шифрованием и без – беда.
![](https://habrastorage.org/webt/se/qs/ku/seqskuovnrhned_eis83hcbf9x0.png)
И в итоге решили немного доработать протоколы. В некоторых случаях это не очень получилось, например для HTTP, а в случае с SMTP получился вполне себе годный вариант. Для этого в SMTP добавили расширение STARTTLS. Вообще, расширение STARTTLS используется не только для SMTP, в целом это команда для начала переговоров о шифровании. В отличие от SMTPS, который использует выделенный порт 465 и сразу шифрует соединение, STARTTLS лишь расширение для SMTP, а значит сессия инициируется как обычная SMTP сессия. Почтовые сервера приветствуют друг друга, а потом предлагают начать шифроваться и выбирают доступные криптографические протоколы.
![](https://habrastorage.org/webt/3-/md/bw/3-mdbw0y7amg4gvwt2vh6e_csdy.png)
В итоге с появлением STARTTLS из стандартов решили убрать SMTPS на 465 порту как отдельный сервис. Из стандартов убрали, но сервис остался, и до сих пор используется. Насчёт шифрования я еще сделаю отдельную тему, а пока поговорим про STARTTLS.
![](https://habrastorage.org/webt/bv/-v/pi/bv-vpiqh-9bsozbp7cu7ajr1vfq.png)
Ранее я сказал, что при STARTTLS почтовые сервера или клиент/сервер открывают соединение без шифрования, а потом договариваются о шифровании. Для шифрования они используют тот же самый SSL/TLS. Но что, если они не смогут договориться? Получится, они будут общаться в незашифрованном виде? По интернету? А между тем, договариваются они без какого-либо шифрования, тем самым легко обмануть сервер или клиент отсутствием доступных методов шифрования. И в своё время уличили одного из провайдеров в такой атаке. И нафиг тогда такое шифрование нужно, спросите вы. Не всё так безнадёжно. На самом деле, администратор может отключить возможность передачи почты, если не удалось договориться о шифровании, а почтовые клиенты обязаны предупреждать о том, что сервер не поддерживает шифрования.
![](https://habrastorage.org/webt/jk/jd/yr/jkjdyrfzt3wgtv8rq35xchtqa3c.png)
И так, мы разобрались с тем, что есть SMTP, который работает по 25 порту, есть SMTPS, который работает по 465, но есть еще один порт – 587, который также используется почтовым сервером.
![](https://habrastorage.org/webt/qw/di/er/qwdiersbgizdugoml737dpbiihq.png)
Как вы заметили, почтовые клиенты подключаются к серверам по SMTP. И почтовые сервера подключаются друг к другу тоже по SMTP. Также я говорил в прошлой части, что есть такие сервера – релей хосты, которые пересылают почту. По определённым причинам, в основном человеческим, в интернете есть релей хосты, которые позволяют неавторизованным пользователям перенаправлять сообщения с любого адреса. И эти хосты появляются каждый раз, когда нерадивый админ поднимает почтовый сервер, а это бывает нередко. Как итог, злоумышленники поднимают временные сервера или заражают компьютеры пользователей, которые рассылают спам через эти релей хосты без авторизации.
![](https://habrastorage.org/webt/ft/im/ml/ftimml9dpl0jriux1qzfyk4vxkm.png)
Как итог, некоторые интернет провайдеры блокируют любые подключения пользователей к 25 порту.
![](https://habrastorage.org/webt/f2/zd/w9/f2zdw98_ws_lxyyldagtxnhuaf0.png)
Между серверами в интернете этот порт открыт, а вот для пользователей сделали отдельный сервис – MSA (message submission agent – агент отправки почты), тем самым отделив подключения пользователей от подключения серверов, которые общаются по прежнему по MTA. Вообще, даже на 25 порту работает MSA, но официальный порт для него – 587. Так что мешает спамерам использовать этот порт? То что на MSA, как правило, обязательна авторизация пользователей. Это не единственная причина существования MSA – так как он работает с почтовыми клиентами, он лучше оптимизирован под работу клиентов – сразу предупреждает о каких-либо ошибках в сообщениях, например, отсутствии доменного адреса получателя.
![](https://habrastorage.org/webt/nk/in/xg/nkinxgm7k5y9--jpyllipbfbej4.png)
И напоследок, давайте проследим за процессом отправки почтового сообщения. Для этого используем wireshark, почтовый клиент и gmail аккаунт. Всё начинается со стандартного TCP хэндшейка, после чего запускается SMTP сессия. В рамках сессии почтовый клиент и сервер приветствуют друг друга, после чего почтовый клиент предлагает зашифровать сессию, сервер даёт согласие, после чего происходит обмен ключами и начинается зашифрованная сессия TLSv1.3, после чего в зашифрованном виде клиент авторизуется и передаёт сообщение, которое не видно для перехватчика трафика.