Чи все ще «неправильно» вимагати 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

@kasperd - ви можете ввімкнути TLS або використовувати його як засіб для зменшення спаму, але він не триватиме. Це означає, що клієнт smtp, який вони використовують для надсилання спаму на ваш сервер, не використовує TLS, або, можливо, намагається не використовувати TLS за замовчуванням, але може спробувати сеанс з підтримкою TLS, якщо це потрібно. У кращому випадку ви побачите тимчасове зниження спаму, але я очікую, що воно з часом повернеться до нормального рівня.

— Метт

@Matt Це стосується більшості підходів, які зараз застосовуються проти спаму. Ще одна проблема більшості підходів полягає в тому, що вони блокують занадто багато законних електронних листів. Люди рідко вважають, скільки законних електронних листів прийнятно заблокувати.

— kasperd

Відповіді:

Так, це все-таки погана ідея.

Три причини:

У той час як RFC, який ви цитували ( RFC 2487 ), фактично застарілий чинним стандартом RFC 3207 , чинний стандарт зберігає НЕ ПОВИННУТЬ багатослівний ви, який ви цитували у своєму запитанні.
Клієнти SMTP не вимагають впровадження STARTTLS. Цілком прийнятно не робити цього. Хоча STARTTLS стає все більш поширеним, він абсолютно не є універсальним.
Внаслідок причин 1 і 2, якщо вам потрібні STARTTLS на всіх вхідних з'єднаннях, ви втратите пошту.

Однак:

Ваш сервер - свої правила. Якщо ви хочете довільно відхилити будь-яку пошту з будь-якої причини чи навіть без причини - це ваше право і привілей. (не означає, що це обов'язково чудова ідея, проте)

Бічні нотатки:

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

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

Зважаючи на це, STARTTLS видаляє одну можливу дорогу для перехоплення або MITM, і тому все-таки є хорошою ідеєю використовувати його, коли це можливо, тобто коли інша сторона також підтримує його.

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

Примітка про сертифікати та спам не відповідає. Саме одержувач потребує сертифікату, а не відправник.

— kasperd

це не допоможе запобігти спаму. Навіть якщо ви зробите взаємний STARTTLS auth обов'язковим. Буде оновлений відповідь для уточнення.

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

Повідомлення +1 про спам. Тільки тому, що він зашифрований, це не робить його захищеним.

— Метт

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

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

— Метт сержант
джерело