Насколько широко поддерживается принудительный TLS на входящих SMTP-соединениях?


10

Я запускаю MTA, состоящий из стандартных проверок Postfix, SpamAssassin, ClamAV, SPF / DKIM и т. Д. Этот MTA используется только для входящей электронной почты, не содержит учетных записей и пересылает любую почту, которая передает указанные проверки общему веб-хосту.

Мне известно, что некоторые почтовые сервисы начинают пытаться установить TLS-соединения перед открытым текстом при попытке доставить почту на мой сервер.

Я понимаю, что не все сервисы будут поддерживать TLS, но мне интересно, насколько он хорошо принят, чтобы удовлетворить требования безопасности OCD моего мозга (да, я знаю, что SSL не так безопасен, как мы когда-то думали, что это так). ...)

Документация Postfix для smtpd_tls_security_levelгосударств, RFC 2487 декреты , что все публично упоминаться Почтовые (т.е. MX) не принуждают TLS:

Согласно RFC 2487 это НЕ ДОЛЖНО применяться в случае SMTP-сервера, на который имеются публичные ссылки. Поэтому эта опция по умолчанию отключена.

Итак: Насколько применима / актуальна документация (или 15-летний RFC в этом отношении), и могу ли я безопасно принудительно использовать TLS на всех входящих SMTP-соединениях, не блокируя половину мировых провайдеров?


1
Стандарты создаются комитетами, члены которых, вероятно, никогда не работали в качестве системного администратора даже один год в своей жизни, и это вполне заметно практически во всех спецификациях интернет-стандартов. В случае RFC ситуация немного лучше, но RFC не являются стандартами. Они являются проекты ( " г Equest F или C omments"). И еще: вы получаете зарплату не с бумаги, а с компании.
Петер - Восстановить Монику

7
Этот RFC был устаревшим RFC 3207 . И его автор был намного дольше, чем один комментатор здесь, кажется, думает.
Майкл Хэмптон

6
Для исходящей электронной почты, вот некоторые статистические данные из Facebook: Текущее состояние развертывания SMTP STARTTLS
masegaloeh

Не уверен в причине единственного понижения голосов. Спасибо Мишель и Питер за ваши взгляды, высоко ценится.
Крейг Уотсон,

Ответы:


7

Это очень сложный вопрос, учитывая, что почтовые провайдеры всего мира не предоставляют статистику на своих почтовых серверах.

Самодиагностика

Чтобы определить ответ на ваш вопрос на основе ваших собственных серверов / доменов, вы можете включить протоколирование SSL:

postconf -e \
    smtpd_tls_loglevel = "1" \
    smtpd_tls_security_level = "may"

postconf
postfix reload

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

Как только вы почувствуете, что все ваши одноранговые узлы поддерживают TLS, а уровень шифра и протокола, который вы готовы применить, вы можете принять, вы можете принять обоснованное решение. Каждая среда отличается. Там нет ни одного ответа, который будет отвечать вашим потребностям.

Мой личный опыт

Как бы то ни было, мой личный почтовый сервер использует TLS. Это имеет забавный побочный эффект, сводящий на нет большинство спам-ботов, так как большинство из них не поддерживают TLS. (До этого изменения я полагался на методологию регулярного выражения S25R)

Обновить

С тех пор, как я ответил на этот вопрос, прошел один год, и единственные проблемы, с которыми я сталкивался при получении электронной почты с принудительным включением TLS, были с интерфейсных веб-серверов Blizzard (родительский контроль) и системы управления Linode. Все остальные, с кем я общаюсь, прекрасно поддерживают TLS с сильными шифрами.

Корпоративная среда

В корпоративной среде я настоятельно рекомендую вам включить ведение журнала TLS и оставить его включенным достаточно долгое время, прежде чем применять TLS. Вы всегда можете применить TLS для определенных доменных имен в файле tls_policy.

postconf -d smtp_tls_policy_maps

На сайте postfix есть отличная документация по использованию карт политик tls. Вы можете по крайней мере гарантировать, что определенные домены, которые предоставляют конфиденциальную информацию, зашифрованы, даже если интернет-провайдер пытается отключить поддержку TLS в начальном соединении с сервером.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.