Почему я должен убедить разработчиков использовать порт 587 для всех коммуникаций SMTP?
Существует растущая тенденция использовать порт 587 для всех соединений клиента с MTA. Это в стандарте RFC: http: //www.ietf. org / rfc / rfc2476.txt
Мой вопрос: «Почему?». Почему 2 экземпляра SMTP-сервера работают на одном и том же сервере, если они оба выполняют одно и то же? Какую функцию безопасности он предоставляет, помимо того, что дает мне две вещи для устранения неполадок в качестве администратора.
Это просто кажется ненужным усложнением, которое не нужно, если только провайдер не блокирует порт 25. Даже тогда, если провайдер блокирует порт 25 для предотвращать спам, это просто означает, что потребуется еще немного времени, пока порт 587 также не будет заблокирован, и нам придется использовать совсем другой порт.
Просто кажется, что мы создаем больше работы для себя, а не решаем проблему и аутентификация SMTP для начала
2 ответа
Пожалуйста, посмотрите.
http://www.uceprotect.net/downloads/MAAWGPort25English.pdf
Я думаю, вам не хватает только того, что порт 587 аутентифицирован. Вы не должны принимать неаутентифицированную электронную почту через порт 587, независимо от того, является ли получатель локальным или нет. Мы (как интернет-провайдеры) блокируем исходящий порт 25, чтобы предотвратить прямую передачу спама на mx. Например, с компьютеров с ботами. Блокирование нашей постоянной / динамической базы пользователей от отправки исходящих сообщений на порт 25 (мы по-прежнему разрешаем ретрансляцию без аутентификации из нашего IP-пространства на порт 25) привело к падению количества сообщений о злоупотреблениях на 85 +%.
ISPS не собираются начинать блокировку 587 (ну, они не должны, поскольку MTA не использует MTA, а только MUA для MTA, поскольку это порт отправки). И это позволяет значительно упростить управление. Также на стороне MTA принудительная аутентификация всех ваших локальных пользователей упрощает борьбу со спамом. Когда их ящик становится владельцем, и переманивает их кредиторы smtp. Все, что вам нужно сделать, это отключить их учетную запись / пароль. При использовании relay по IP вам необходимо заблокировать их подключение к почтовому серверу (мы делаем это, днямично применяя ACL к их DSL / кабельному соединению).
Если вы пишете либо MUA, либо MTA, вам необходимо поддерживать и то, и другое, а в случае MUA или чего-то, что отправляет электронное письмо, по умолчанию должно быть 587 попыток TLS и smtp auth, и только сбой будет 465. , 25, если это не удается.
Я быстро прочитал RFC, и они думают, что мир SMTP разделен на две области: транспортировка почты (для этого был разработан SMTP) и отправка писем.
Авторы утверждают, что SMTP не предназначался для использования почтовым клиентом (MUA, Message User Agent), а только почтовыми серверами, направляющими почту по назначению. Они думают, что если вы разделите мир SMTP таким образом, вы можете написать SMTP-сервер, предназначенный для доступа только MUA, который затем сможет делать что-то и делать предположения, что «нормальный» SMTP-сервер должен / не может делать. «Обычный» SMTP-сервер всегда назывался MTA, агент передачи сообщений. Авторы предлагают назвать новый тип SMTP-сервера MSA - Message Submission Agent.
Похоже, они думают, что это упростит реализацию двух типов серверов и, возможно, даже сделает их более безопасными. RFC объясняет, что должно отличаться в MSA от MTA. Например, RFC требует использования авторизации, в то время как в исходном протоколе SMTP этого не было (SMTP AUTH был добавлен позже, похоже, самим RFC 2476; однако сам SMTP AUTH позже определен в RFC 2554, который был заменен по RFC 4954).
MTA, которому необходимо ретранслировать сообщения из разных источников в разные места назначения, не может использовать аутентификацию для каждого сообщения (как другой сервер должен аутентифицироваться на вашем сервере?). Но MSA, который является отправной точкой вашего сообщения, может и должен требовать аутентификации от своего партнера, почтового клиента.И хотя MTA должен ретранслировать сообщение в неизменном виде, за исключением добавления заголовка Received , MSA может «дезинфицировать» электронное письмо, например путем заполнения недостающих заголовков и тому подобного.