Я собираюсь предварить это заявлением, что я не эксперт в sendmail. Я редко им пользуюсь, но в данной ситуации я вынужден использовать для своего клиента.
Задний план:
У моего клиента есть почтовый сервер под управлением Debian 7.7, Sendmail 8.14.4 и OpenSSL 1.0.1e. Он генерирует электронные письма (например, сброс учетной записи) и отправляет их клиентам. Я назову его «Сервер А».
Сообщения, отправленные с сервера A на любой почтовый сервер в домене * .outlook.com (который, как ни странно, не включает сообщения @ outlook.com, они обрабатываются hotmail), откладывались из-за неудачного рукопожатия 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-адресов нужно поддерживать вручную, что беспокоит.
Добро пожаловать в Serverfault! :-)
Вы явно настроили SendMail для использования TLS? В противном случае SendMail по-прежнему будет пытаться выполнять гибкие операции TLS с нулевым байтовым сертификатом клиента. Я полагаю, это то, что вы видите? Для получения дополнительной информации об этом (странности?) Ознакомьтесь с отличным ответом @ MadHatter здесь: https://serverfault.com/a/514180/21875
Итак, с учетом сказанного, я отвечу на ваши вопросы в том порядке, в котором они были заданы:
- Почему 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.com).
Вариант №2: Реализуйте правило обхода для всех доменов. Это можно сделать, добавив Try_TLS: NO в вашу таблицу доступа (IP-адреса указывать не нужно).
Технически, вы также можете взломать файл sendmail.mc, чтобы sendmail вообще не проверял возможности TLS. Я бы не рекомендовал делать это, поскольку это требует тонких изменений.
Перенести решение из вопрос для ответа в разделе.
Для всех, у кого есть эта проблема, и я не могу ее понять, я нашел первопричину и решение.
Я не мог предотвратить отправку клиентского сертификата в Microsoft, поэтому единственным выходом было выяснить, почему Microsoft отклоняет сервер. При создании сертификата мы использовали другое имя сервера, чем было указано в ehlo. например mx1.example.com на вертолете и mx.example.com в сертификате. Несоответствие заставляло Microsoft разрывать соединения без объяснения причин.