Сообщения Sendmail, отклоненные от Microsoft при использовании TLS
Я собираюсь предварить это заявлением о том, что я не эксперт по sendmail. Я редко использую это, но в этой ситуации я должен для своего клиента.
Фон:
Мой клиент имеет почтовый сервер под управлением Debian 7.7, Sendmail 8.14.4 и OpenSSL 1.0.1e. Он генерирует электронные письма (например, сброс учетной записи) и отправляет их клиентам. Я назову это "Сервер А".
Сообщения, отправленные с сервера A на любой почтовый сервер в домене *.outlook.com (который, как ни странно, не включает сообщения @ outlook.com, обрабатываются горячей почтой), были отложены из-за неудачного рукопожатия TLS. Это проблема только для серверов, принадлежащих Microsoft; все остальное работает. Ошибка в журнале выглядела примерно так:
sendmail[22213]: ruleset=tls_server, arg1=SOFTWARE, relay=mail.protection.outlook.com, reject=403 4.7.0 TLS handshake
sendmail[22213]: s2L9EakQ022098: to=<blah@microsoft.com>, delay=00:00:55, xdelay=00:00:31, mailer=esmtp, pri=181653, relay=mail.protection.outlook.com. [145.123.225.25], dsn=4.0.0, stat=Deferred
Примечание. Эти журналы составлены потому, что мой клиент не хочет, чтобы что-то копировалось и вставлялось, они случайно пропускают важные данные. Информация есть, я просто набрал ее вручную, поэтому игнорирую опечатки и т. Д.
Это было все, что я мог получить из журналов, даже с журналами 15 (Кроме того, система стала привязываться к диску).
Проблема:
Tcpdump из рукопожатия показал, что сервер A подключался к outlook.com, EHLO успешно прошел, сервер A инициировал STARTTLS, outlook.com затем ответил цепочкой сертификатов. Все это прошло нормально.
Затем, после того как сервер A получил цепочку сертификатов Microsoft, сервер A отправил свой собственный клиентский сертификат. Затем Outlook.com разорвал соединение.
Наши клиентские сертификаты являются самозаверяющими сертификатами, которые мы используем для внутриорганизационной проверки и не должны выходить на outlook.com.
Из моих ограниченных знаний я могу предположить, что outlook.com запрашивает сертификат клиента для проверки (или, по крайней мере, sendmail считает, что запрашивает сертификат), что обязывает sendmail на сервере A. Затем Outlook.com разрывает соединение, либо потому, что сертификат недействителен, либо не соответствует ожидаемому.
Два вопроса:
Почему sendmail отправляет клиентский сертификат на outlook.com как часть STARTTLS?
Есть ли способ, которым я могу запретить sendmail отправлять клиентские сертификаты на серверы за пределами нашего домена, даже если сервер запрашивает это? После проведенных экспериментов outlook.com примет сообщение, если я просто проигнорирую запрос сертификата и отправлю сообщение.
Прежде чем кто-либо предложит это, я уже создал карту доступа, которая запрещает TLS-соединениям с некоторыми IP-адресами, связанными с Microsoft. Это не очень хорошее постоянное решение, потому что я бы предпочел использовать TLS, и список IP-адресов должен поддерживаться вручную, что беспокоит.
2 ответа
Добро пожаловать в Serverfault!:-)
Вы явно настроили SendMail для использования TLS? Если нет, то из почтового ящика SendMail по-прежнему будет пытаться выполнить условные операции TLS с нулевым байтовым сертификатом клиента. Я полагаю, это то, что вы видите? Для получения дополнительной информации об этом (странность?) Проверьте превосходный ответ @MadHatter здесь: /questions/151906/podderzhivaet-li-sendmail-ishodyaschee-shifrovanie-tls-bez-dopolnenij-k-fajlu-se/151916#151916
Итак, с учетом сказанного, я отвечу на ваши вопросы в том порядке, в котором они были заданы:
- Почему sendmail отправляет клиентский сертификат на outlook.com как часть STARTTLS?
Когда два MTA пытаются установить безопасный туннель для STARTTLS, для них является нормальным согласовывать информацию о безопасности и обмениваться открытыми сертификатами, чтобы они могли безопасно шифровать информацию друг другу. Если sendmail не предоставит сертификат клиента для outlook.com, почтовые серверы outlook.com не смогут зашифровать ответы / подтверждения обратно в sendmail.
- Есть ли способ, которым я могу запретить sendmail отправлять клиентские сертификаты на серверы за пределами нашего домена, даже если сервер запрашивает это? После проведенных экспериментов outlook.com примет сообщение, если я просто проигнорирую запрос сертификата и отправлю сообщение.
У вас есть несколько вариантов:
Вариант № 1: Реализация правила исключения для каждого сервера / домена. Это можно сделать, добавив Try_TLS:<broken.server> NO к вашей таблице доступа. Похоже, вы уже делаете это, но важно отметить, что часть "broken.server" может быть IP, MX-записью (microsoft-com.mail.protection.outlook.com) или частичной MX-записью (outlook. ком).
Вариант № 2: Реализация правила обхода для всех доменов. Это можно сделать, добавив Try_TLS: NO к вашей таблице доступа (не нужно указывать IP-адреса).
Технически, вы также можете взломать файл sendmail.mc, чтобы запретить sendmail вообще проверять возможности TLS. Я не рекомендовал бы делать это, хотя, поскольку это требует деликатных изменений.
Перенести решение из раздела вопросов в ответ.
Для тех, кто имеет эту проблему и не может понять ее, я нашел основную причину и решение.
Я не мог предотвратить отправку сертификата клиента в Microsoft, поэтому единственной возможностью было выяснить, почему Microsoft отклонила сервер. При создании сертификата мы использовали другое имя сервера, чем было представлено в ehlo. например mx1.example.com в аду и mx.example.com в сертификате. Несоответствие заставляло Microsoft разрывать соединения без объяснения причин.