Наскільки широко підтримується примусовий TLS на вхідних SMTP-з'єднаннях?

Я запускаю 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-з'єднаннях, не блокуючи половину світових провайдерів?

— Крейг Уотсон
джерело

Стандарти створюються комітетами, члени яких, мабуть, ніколи не працювали систематиком жодного року у своєму житті, і це цілком видно практично у всіх стандартних специфікаціях Інтернету. У випадку з RFC це трохи краща ситуація, але RFC - це не стандарт. Вони є протягами (" r equest f or c omments"). І: ви отримуєте зарплату не з паперу, а від компанії.

— петерх

Цей RFC був застарілий RFC 3207 . І його автор пробув набагато довше, ніж, здається, один коментатор тут думає.

— Майкл Хемптон

Для вихідної електронної пошти, ось кілька статистичних даних з Facebook: Поточний стан розгортання SMTP STARTTLS

— masegaloeh

Невідома причина єдиного потоку. Дякую Мішелю та Пітеру за ваші погляди, дуже цінуємо.

— Крейг Уотсон

Це дуже складне питання, враховуючи те, що постачальники пошти світу не охоче надають статистику на своїх поштових серверах.

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

Щоб визначити відповідь на своє запитання на основі власних аналогів сервера / домену, ви можете включити протокол SSL:

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

postconf
postfix reload

Це передбачає, що ви деякий час зберігаєте повідомлення електронної пошти. Якщо ні, можливо, встановіть стратегію архівації системного журналу та напишіть сценарій оболонки, щоб узагальнити використання TLS на вашому сервері. Можливо, вже є сценарій для цього.

Як тільки вам буде зручно, що всі ваші колеги підтримують TLS та на шифр та протокол, які ви готові застосувати, ви можете прийняти обгрунтоване рішення. У кожного середовища різне. Немає жодної відповіді, яка б відповідала вашим потребам.

Мій власний особистий досвід

Мені власний персональний поштовий сервер застосовує TLS. Це має дивний побічний ефект відкидання більшості спам-ботів, оскільки більшість з них не підтримує TLS. (До цієї зміни я покладався на методологію regexp S25R)

Оновлення

Минув рік, як я відповів на це, і єдині проблеми, з якими я мав отримувати електронну пошту з TLS, змушені бути з веб-серверів на передньому кінці Blizzard (батьківський контроль) та системи управління Linode. Всі інші, з якими я взаємодію, схоже, підтримують TLS із сильними шифрами.

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

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

postconf -d smtp_tls_policy_maps

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

— Аарон
джерело