Под "нормально использовать" я имею в виду:
... или лучше придерживаться незашифрованных писем?
Я запускал MTA с самоподписанным сертификатом в течение нескольких лет, пока настоящие не стали достаточно дешевыми, чтобы я больше не беспокоился об этом, и у меня не было ни единого отказа из-за неподписанного сертификата во всем этом время. У меня никогда не было ни одной жалобы на то, что письмо было помечено как спам из-за этого; во всяком случае, использование TLS часто выделяет вас как профессионала, не рассылающего спам.
На мой взгляд, определенно стоит включить SMTP TLS, если вы можете, независимо от того, платите ли вы за сертификат, подписанный третьей стороной.
редактировать в ответ на ваш комментарий: Дело не в том, что кто-то не мог ограничить входящую почту на этом основании; Я никогда с этим не сталкивался, вот и все. Сертификат, подписанный третьей стороной, по-прежнему полезен, чтобы доказать, что атаки «злоумышленник посередине» не происходит; но в настоящее время это не кажется серьезной проблемой в мире MTA. Если это начнет меняться, мы вполне можем обнаружить, что люди начнут настаивать на подписанных сертификатах.
Безопасность существует для устранения угроз, поэтому, если модель угроз изменится, диапазон разумных и соразмерных ответных мер безопасности изменится вместе с ней.
Как сказал Мадхаттер, на данный момент шифрование с использованием самозаверяющего сертификата на самом деле является шагом вперед по сравнению со многими другими небольшими SMTP, если вы говорите о SMTP-ретрансляции.
Однако есть несколько недостатков, но они не такие, как вы ожидаете. Самым важным из них является то, что ваши SMTP-клиенты задыхаются от шифрования. Есть много небольших SMTP-клиентов, развернутых в готовых решениях для типичных бизнес-проблем, которые не любят шифрование SMTP и выходят из строя - часто незаметно! Итак, если вы используете стандартное программное обеспечение со встроенными почтовыми клиентами, проверьте их перед переключением.
В остальном я бы сказал, что если вы обеспокоены тем, что ваша почта будет помечена как спам, подумайте о настройке SPF и DKIM. Это очень помогает.
Вопрос, безусловно, каким-то образом устарел, но он заслуживает повторного рассмотрения и должен получить обновленный ответ.
Относительно влияния на исходящую доставку и фильтрацию спама: согласно Отчет о прозрачности Google при шифровании электронной почты при передаче в / из Google около 90% исходящих и 93% входящих сообщений электронной почты передаются с использованием TLS. Таким образом, с некоторым уважением TLS для электронной почты становится нормой, и, учитывая большой объем спама, просто использование TLS в качестве другого значения оценки в фильтре спама не имеет большого значения. Поскольку сегодня входящие сертификаты TLS обычно не используются для аутентификации исходящих подключений, содержимое сертификата (метаданные, кто подписал сертификат,…) вообще не влияет на фильтры спама в исходящей электронной почте.
Исторически сложилось так, что у MTA есть ограниченные возможности для обработки любых ошибок сертификата: вообще отклонить отправку сообщения или вернуться к отправке сообщения через соединения с открытым текстом. Отклонение сообщения приведет к запросам в службу поддержки пользователей, а возврат к обычному тексту не дает преимуществ безопасности по сравнению с использованием хотя бы «некоторого» уровня шифрования. Соответственно, большинство MTA используют конфигурацию «гибкого TLS»: предпочитают использовать TLS, если он доступен, независимо от точного сертификата для проверки.
Однако за последнее десятилетие в отрасли произошли небольшие сдвиги.
С 2010 года Немецкая ассоциация автомобильной промышленности рекомендует использовать как минимум гибкую TLS для электронной почты и рекомендует обязательный TLS для конфиденциальной электронной почты.
Некоторые поставщики услуг электронной почты также начали вводить необязательный обязательный исходящий TLS, например Немецкий провайдер электронной почты posteo.de сделал это в 2016 году..
Функцию Posteo можно включить для каждого пользователя, и если сообщение не может быть передано с использованием зашифрованного соединения, отправляющий пользователь получит сообщение об ошибке. Затем пользователь может решить (временно) отключить эту функцию (например, попросить получателя обновить его почтовую службу). В течение 2 недель после того, как функция была выпущена, довольно много почтовых сервисов начали поддерживать (гибкую) TLS.
Таким образом, отказ от TLS и использование незашифрованной почты может привести к частичным проблемам с входящими сообщениями у некоторых отправителей. Однако в то время в большинстве случаев с самоподписанными сертификатами все в порядке.
А исследовательский документ по безопасности электронной почты с 2015 года обнаружено, что 64% доменов действительно используют почтовые серверы с поддержкой STARTTLS, чей сертификат действительно прошел проверку в корневом хранилище Mozilla NSS, поэтому 36% используют самозаверяющие, недействительные или просроченные сертификаты.
Совсем недавно строгая транспортная безопасность MTA улучшила общую тенденцию: если домены, размещенные на вашем почтовом сервере, действительно используют строгую транспортную безопасность MTA (RFC 8461), эти домены также согласились обеспечивать соблюдение входящей почты через TLS с использованием доверенных сертификатов. RFC 8461, раздел 4.2 ясно говорит
Сертификат, представленный получающим MTA, НЕ ДОЛЖЕН иметь истекший срок и ДОЛЖЕН быть связан с корневым CA, которому доверяет отправляющий MTA.
Конечно, это относится только к доменам, использующим строгую транспортную безопасность MTA.
В конце концов: на сегодняшний день проблемы с исходящей электронной почтой маловероятны. Что касается входящей электронной почты, вам настоятельно рекомендуется использовать надлежащие сертификаты TLS, выпущенные общедоступным центром сертификации, поскольку в противном случае могут возникнуть проблемы с доставкой. Некоторые из них могут быть адресованы в вашем домене (например, MTA-STS), а другие - нет (например, серверы-отправители, применяющие обязательный исходящий TLS).
Это не.
Центры сертификации бесполезны для SMTP. Серверы не проверяют сертификат. Они не могут. Не существует стандартизированного набора доверенных центров сертификации, и нет человека, который мог бы оценить, что делать при возникновении проблемы с сертификатом, поэтому центры сертификации просто игнорируются. Единственный способ защитить SMTP от SMTP - использовать DANE для SMTP.