Я использую почтовый сервер, который в настоящее время настроен на использование TLS, если это возможно, при отправке и получении писем.
Когда вы читаете об этом в документации, есть также возможность принудительно использовать TLS и не принимать передачу сообщений электронной почты в виде обычного текста. Он также предупреждает вас, что некоторые почтовые серверы могут еще не поддерживать шифрование, и принудительное шифрование может заблокировать эти серверы.
Но стоит ли по-прежнему думать об этом, или можно с уверенностью сказать, что принудительное шифрование больше не будет проблемой?
Возможно, есть какой-нибудь крупный провайдер, который уже этим занимается, или что вы считаете передовой практикой в наши дни?
Практическая проблема заключается в том, что не каждый SMTP-совместимый (RFC довольно старый) сервер может передавать TLS вашему серверу, поэтому вы можете пропустить получение некоторых сообщений электронной почты.
Философская проблема заключается в том, что невозможно предсказать, как электронное письмо будет ретранслироваться после (или до) его доставки на ваш сервер.
Это означает, что электронное письмо уже могло быть передано в виде обычного текста через ретранслятор.
Любой, кто серьезно относится к защите содержимого своей электронной почты, должен фактически зашифровать тело. С шифрованием на маршруте всегда вероятно, что он уже был передан в виде обычного текста.
Итак, чтобы ответить на ваш вопрос, принудительное шифрование на уровне SMTP, вероятно, бессмысленно, увеличивает вероятность пропуска электронной почты и не дает гарантированной выгоды.
Изменить: это относится к принудительному применению SMTP для ретрансляции, не отправка электронного письма. При отправке почты следует применять шифрование, поскольку SMTP-диалог (а не фактическое электронное письмо), возможно, содержит учетные данные для аутентификации.
Нет
RFC 821 исполнилось 33 года. Вы воля найти электронные письма, отправленные программами, не поддерживающими STARTTLS. Иногда это будут незавершенные отправители электронной почты (например, внутренние скрипты), иногда полноценные системы, которые устарели, с отключенным / не скомпилированным TLS, системами без достаточной энтропии…
Не так давно я был свидетелем сбоя исходящей электронной почты, потому что на принимающей стороне был настроен только SMTP через TLS. Это была проблема отправителя (он не должен был использовать эту конфигурацию), но показывает, что это действительно происходит.
Я бы ограничил входящие сообщения только с IP-адресов, настроенных вручную. Если обработчик вашей кредитной карты не может запустить STARTTLS, вы, вероятно, предпочтете прервать соединение (и вызвать локального администратора, чтобы он мог их предупредить!), Чем получить эти (потенциально конфиденциальные) данные в незашифрованном виде. Для исходящих сообщений, если вы ранее подключались к этому узлу с помощью STARTTLS, вы можете захотеть больше не делать это небезопасно, вместо этого рассматривая это как потенциальную угрозу. У вас также может быть список известных всегда используемых хостов STARTTLS, таких как gmail или yahoo.
Есть https://www.eff.org/starttls-everywhere проект, содержащий список SMTP-серверов, для которых вы можете (должны?) уверенно принудительно использовать starttls.
Совершенно бессмысленно и, вероятно, вредно отказываться от электронной почты от сверстников, не способных к шифрованию.
Пока ваш сервер настроен для выполнения гибкого шифрования с любым партнером, который его предлагает, вы получаете лучшее из обоих миров: шифрование, когда оно доступно, и электронная почта по обычному тексту, когда его нет.
Пока есть серверы, которые не поддерживают шифрование, его включение просто означает, что они не могут с вами разговаривать; это плохо. Как только все его поддержат, нет разницы между гибким и обязательным шифрованием.
И, как отмечали другие, шифрование по сети и сквозное шифрование - это две совершенно разные вещи, направленные на устранение разных моделей угроз. Не путайте их.
Это вопрос политики.
Обычно, когда TLS применяется для входящей и исходящей почты, это делается для ограниченного набора доменов, которые согласованы сторонами для удовлетворения потребностей (например, деловые партнеры могут иметь соглашение о шифровании всей почты между своими компаниями).
Если такое соглашение не заключено, не включайте принудительный режим.
Нет, это очень плохая идея.
На самом деле, как оказалось, большинство STARTTLS серверы / клиенты не реализуют какой-либо алгоритм повтора без StartTLS, если соединение TLS не удалось согласовать.
Таким образом, даже реклама STARTTLS в качестве опции уже снижает ваши шансы на получение (и отправку) электронных писем!
Просто выполните поиск, и вы обнаружите, что многие люди не могут отправлять ЛЮБУЮ электронную почту на домены Microsoft Outlook, обрабатываемые кластером * .protection.outlook.com:
Сообщения Sendmail отклонены от Microsoft при использовании TLS
причина: 403 4.7.0 подтверждение TLS не удалось
Обобщая проблемы, представленные в двух вышеупомянутых сообщениях:
Аналогичным образом, когда ваш хост действует как сервер, аналогичная ситуация может возникнуть вне вашего контроля, если вы решите включить STARTTLS - когда клиентский сервер видит, что ваш сервер в режиме сервера предлагает STARTTLS, они пытаются согласовать TLS, но если согласование не удается , они просто ждут и повторяют те же шаги снова, продолжая терпеть неудачу, пока сообщение не будет возвращено отправителю!
И это действительно происходит довольно часто с различными доменами в стране STARTTLS!
К сожалению, несмотря на то, что раньше я был сторонником STARTTLS, теперь я очень разочарован тем, что был введен в заблуждение безрисковой рекламой того, что, как я думал, должно было быть оппортунистическим шифрованием.
Вам не только не нужно требовать STARTTLS, но может быть даже разумно полностью отключить его, если вы хотите обеспечить совместимость.
Я должен согласиться с идеей использования гибкого TLS. Хотя мне тоже есть что добавить к этой идее. Некоторые, вероятно, будут обеспокоены этими предложениями, однако, поскольку мои предложения здесь не легкомысленны и без должного рассмотрения, перед вынесением суждения я прошу вас прочитать полное обсуждение по прилагаемой ссылке.
Использование гибкого TLS - безусловно, лучшее решение. Аргумент против MITM - отвлекающий маневр. В конце концов, как MH упомянул в комментарии, даже «законный» SMTP с TLS-соединением может быть MITM'd, и конечный пользователь не будет мудрее из-за того, что подавляющее большинство почтовых клиентов не утруждает себя проверкой сертификатов в сочетании с подавляющим большинством MTA, выполняющих TLS, используют самозаверяющие сертификаты (по крайней мере, если yiur не использует DNSSEC и TLSA / DANE.) В результате этого и, возможно, других факторов, даже можно утверждать, что пока и вы, и остальной мир реализовал DANE / TLSA и DNSSEC, поэтому при использовании гибкого TLS лучше, чем не включать анонимный diffie-hellman (при одновременном использовании PFS). По крайней мере частично, если не в основном, из-за того, что он по-прежнему будет шифровать трафик, защищая от случайного наблюдателя. Для дальнейшей поддержки этой конфигурации (с гораздо более подробным объяснением, чем у меня), пожалуйста, ознакомьтесь с комментариями Виктора Духовного в этом посте на форуме постфиксов: http://postfix.1071664.n5.nabble.com/Disables-Anonymous-Diffie-Hellman-td67965.html
Что касается того, почему можно принять предложения Виктора над предложениями других, ну, он написал код TLS, а также код DNSSEC, TLSA / DANE для Postfix MTA, в дополнение к тому, что он написал черновики IETF для обоих DNSSEC. и TLSA / DANE. Таким образом, я бы сказал, что его слова по этому поводу имеют довольно большой вес, вероятно, больший, чем у большинства.
Надеюсь это поможет.
С точки зрения электронного маркетинга использование TLS является хорошей практикой и безопасностью, если вы знаете, что он реализован на протяжении всей цепочки доставки. Однако, если безопасность является вашим главным требованием, тогда шифрование самого электронного письма перед его отправкой является наиболее безопасным вариантом (например, с помощью PGP).