Все еще «неправильно» требовать STARTTLS для входящих SMTP-сообщений

Согласно разделу 5 спецификации STARTTLS :

Общедоступный SMTP-сервер НЕ ДОЛЖЕН требовать использования
расширения STARTTLS для локальной доставки почты. Это правило
предотвращает повреждение расширения STARTTLS функциональной совместимостью инфраструктуры SMTP в Интернете. SMTP-сервер, на который имеются публичные ссылки, - это SMTP-сервер, который работает на порту 25 узла Интернета, указанного в записи MX (или записи A, если запись MX отсутствует) для имени
домена справа от адреса электронной почты Интернета. ,

Однако эта спецификация была написана в 1999 году, и, учитывая, что это 2014 год, я ожидаю, что большинство SMTP-клиентов, серверов и ретрансляторов будут иметь какую-то реализацию STARTTLS.

Сколько электронной почты я могу потерять, если мне потребуется STARTTLS для входящих сообщений?

email smtp starttls

— jackweirdy
источник

Хороший вопрос. Включение TLS не предотвратит спам.

— Мэтт

Я не ожидаю этого, я просто хочу шифрование (которое я, похоже, получаю из 90% входящих сообщений без необходимости) :)

— jackweirdy

@Matt Я проверил недавно полученные письма на одном конкретном почтовом сервере и нашел это. Из писем, полученных с помощью TLS, было 4% спама, из писем, полученных без TLS, было 100% спама. Я бы не стал полностью блокировать почту без TLS, основываясь на этом, но это, безусловно, сильный сигнал, который можно использовать при фильтрации спама.

— Касперд

@kasperd - вы можете включить TLS или использовать его как средство для уменьшения спама, но это не продлится долго. На самом деле все это означает, что клиент smtp, который они используют для рассылки спама на ваш сервер, не использует TLS или, возможно, пытается не использовать TLS по умолчанию, но может попробовать сеанс с поддержкой TLS, если это необходимо. В лучшем случае вы увидите временное сокращение СПАМа, но я ожидаю, что со временем оно вернется к нормальному уровню.

— Мэтт

@Matt Это относится к большинству подходов, применяемых в настоящее время против спама. Другая проблема с большинством подходов состоит в том, что они блокируют слишком много законных электронных писем. Люди редко задумываются над тем, сколько законных писем можно заблокировать.

— Касперд

Ответы:

Да, это все еще плохая идея.

Три причины:

В то время как RFC, на который вы ссылались ( RFC 2487 ), фактически устарел в соответствии с действующим стандартом RFC 3207 , текущий стандарт НЕ ДОЛЖЕН содержать слов, которые вы цитировали в своем вопросе.
Клиенты SMTP не обязаны реализовывать STARTTLS. Вполне допустимо не делать этого. Хотя STARTTLS становится все более распространенным явлением, оно не является универсальным.
По причинам 1 и 2, если вам требуется STARTTLS для всех входящих подключений, вы потеряете почту.

Тем не мение:

Ваш сервер - ваши правила. Если вы хотите произвольно отклонить любую почту по любой причине или даже без причины - это ваше право и привилегия. ( однако это не значит, что это хорошая идея)

Примечания стороны:

Вы не предотвратите спам, требуя STARTTLS, даже если вам требуется взаимная аутентификация STARTTLS. Спамеры тоже могут получать сертификаты или создавать самозаверяющие. Отказ от самозаверяющих клиентских сертификатов также приведет к потере законной почты.

STARTTLS - это двухточечное шифрование. Система подключения все еще может читать содержимое письма. Если вам нужна настоящая конфиденциальность, вам нужно что-то сквозное, например OpenPGP или S / MIME.

Тем не менее, STARTTLS действительно удаляет один возможный путь для перехвата или MITM, и поэтому все еще будет хорошей идеей использовать его, когда это возможно, то есть, когда другая сторона также поддерживает его.

— Джо Снайдерман
источник

Примечание о сертификатах и спаме неуместно. Сертификат нужен получателю, а не отправителю.

— Касперд

это не поможет предотвратить спам. Даже если вы сделаете взаимную авторизацию STARTTLS обязательной. Обновлю ответ, чтобы уточнить.

— Джо Снайдерман

+1 на заметку о спаме. То, что он зашифрован, не делает его безопасным.

— Мэтт

Google ведет открытую статистику по процентам зашифрованной почты, как входящей, так и исходящей. Эта информация должна быть чрезвычайно полезной для вас, чтобы определить, стоит ли это реализовывать:

http://www.google.com/transparencyreport/saferemail/

— Мэтт сержант
источник