Почему я должен убеждать разработчиков использовать порт 587 для всех SMTP-коммуникаций?

Существует тенденция к использованию порта 587 для всех клиентов для сообщений MTA. Это в стандартном треке RFC: http://www.ietf.org/rfc/rfc2476.txt

Мой вопрос: "Почему?". Почему на одном сервере есть два экземпляра SMTP-сервера, если они оба делают то же самое? Какую функцию безопасности он предоставляет, помимо того, что мне нужно 2 вопроса для устранения неполадок в качестве администратора.

Это похоже на ненужное осложнение, которое не требуется, если ISP не блокирует порт 25. Даже тогда, если интернет-провайдер блокирует порт 25 для предотвращения спама, это просто означает, что просто потребуется немного больше времени, пока порт 587 не будет заблокирован, и нам придется использовать другой порт.

Просто кажется, что мы создаем больше работы для себя, а не решаем проблему и аутентифицируем SMTP, чтобы начать с

Ответ 1

Пожалуйста, смотрите.

http://www.uceprotect.net/downloads/MAAWGPort25English.pdf

Я думаю, что вам не хватает только порт 587. Вы не должны принимать неавторизованную электронную почту на порт 587, независимо от того, является ли получатель локальным или нет. Мы (как провайдеры) блокируем исходящий порт 25 для предотвращения прямого спама. Например, с ботов компьютеров. Блокируя нашу жилую/динамическую базу пользователей от отправки исходящего трафика на порт 25 (мы по-прежнему разрешаем не аутентифицированное ретрансляцию из нашего IP-пространства на 25-м порту), это привело к сокращению количества сообщений о злоупотреблениях на 85%.

ISPS не собирается блокировать 587 (ну, они не должны, так как это не для MTA для использования MTA, только MUA для MTA, так как это порт представления). И это позволяет значительно упростить управление. Также на стороне MTA принуждение всех ваших локальных пользователей к аутентификации облегчает смягчение спама. Когда их ящик становится владельцем, и берет их smtp creditionals. Все, что вам нужно сделать, это отключить их учетную запись/пароль. При использовании relay by ip вам необходимо заблокировать их от подключения к почтовому серверу (мы делаем это путем днямического применения ACL к их DSL/кабельному соединению).

Если вы пишете и MUA или MTA, вам необходимо поддерживать оба, а в случае MUA или что-то отправляет электронную почту, он должен по умолчанию выполнить 587 попыток TLS и smtp auth и только сработает до 465, 25, если это не удается.

Ответ 2

Я быстро просмотрел RFC, и их мышление состоит в том, чтобы разделить мир SMTP на две области: транспортировку писем (для чего SMTP был разработан) и отправка писем.

Авторы утверждают, что SMTP не предназначен для использования почтовым клиентом (MUA, User User Agent), а только почтовыми серверами, маршрутизируя почту в пункт назначения. Они думают, что если вы разделите мир SMTP таким образом, тогда вы можете написать SMTP-сервер, доступ к которому должен получить только MUA, который затем может делать что-то и делать предположения "нормальным", перенаправляющим SMTP-сервером, который должен/не может быть выполнен. "Обычный" SMTP-сервер всегда назывался агентом передачи сообщений MTA. Авторы предлагают назвать новый тип SMTP-сервера MSA, агента представления сообщений.

Кажется, они думают, что это упростит реализацию двух типов серверов и, возможно, еще более безопасно. RFC объясняет, что должно отличаться в MSA по сравнению с MTA. Например, RFC обязуется использовать авторизацию, в то время как у исходного протокола SMTP это не было (SMTP AUTH был добавлен позже, это похоже на самый RFC 2476, однако сам SMTP AUTH является более поздним, указанным в RFC 2554, который был заменен по RFC 4954).

MTA, которому необходимо ретранслировать сообщения из разных источников в разные адресаты, не может использовать аутентификацию для каждого сообщения (как должен аутентифицировать другой сервер на вашем сервере?). Но MSA, являющаяся отправной точкой вашего сообщения, может и должна требовать аутентификации от своего однорангового почтового клиента. И хотя MTA должен передать сообщение неизменным, сохранить для добавления заголовка Received, и MSA может "дезинфицировать" электронную почту, например. заполняя отсутствующие заголовки и тому подобное.