web-dev-qa-db-ja.com

TLSの使用時にMicrosoftから拒否されたSendmailメッセージ

私はこれの前に、私がsendmailの専門家ではないことを述べます。私はめったにそれを使用しませんが、この状況では私はクライアントのためにしなければなりません。

背景：

私のクライアントには、Debian 7.7、Sendmail 8.14.4、およびOpenSSL 1.0.1eを実行するメールサーバーがあります。メール（アカウントのリセットなど）を生成し、顧客に送信します。これを「サーバーA」と呼びます。

サーバー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=<[email protected]>, 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に送信することはできません。

私の限られた知識から、サーバーAのsendmailが義務付けている、Outlook.comが検証のためにクライアント証明書を要求している（または少なくともsendmailが証明書を要求していると考える）と推測します。 Outlook.comは、証明書が無効であるか、予期していたものではないため、接続を切断しています。

2つの質問：

  1. Sendmailがクライアント証明書をSTARTTLSの一部としてOutlook.comに送信するのはなぜですか？

  2. サーバーが要求した場合でも、sendmailがクライアント証明書をドメイン外のサーバーに送信しないようにする方法はありますか？私が行った実験から、証明書の要求を単に無視してメッセージを送信すると、Outlook.comはメッセージを受け入れます。

だれかがそれを示唆する前に、Microsoftに関連付けられた一部のIPアドレスとの接続からTLSを防ぐアクセスマップを既に作成しました。私はTLSを使用することを好み、IPアドレスのリストは手動で維持する必要があるため、これは良い永続的な解決策ではありません。

sendmailopenssl
6
Eric J

Serverfaultへようこそ！ :-)

TLSを使用するようにSendMailを明示的に構成しましたか？そうでない場合、SendMailはそのまま、ゼロバイトのクライアント証明書を使用して便宜的なTLS操作を実行しようとします。これはあなたが見ているものだと思いますか？これの詳細については（奇妙ですか？）@MadHatterの優れた応答をここで確認してください： https://serverfault.com/a/514180/21875

だから、それが言われて、私は彼らが尋ねられた順にあなたの質問に答えます：

  1. Sendmailがクライアント証明書をSTARTTLSの一部としてOutlook.comに送信するのはなぜですか？

2つのMTAがSTARTTLSの安全なトンネルを確立しようとしているとき、それらがセキュリティ情報を互いに安全に暗号化できるように、セキュリティ情報をネゴシエートし、公開証明書を交換するのが普通です。 sendmailがクライアント証明書をOutlook.comに提供しなかった場合、Outlook.comメールサーバーはsendmailへの応答/確認を暗号化する方法がありません。

  1. サーバーが要求した場合でも、sendmailがクライアント証明書をドメイン外のサーバーに送信しないようにする方法はありますか？私が行った実験では、証明書の要求を無視してメッセージを送信するだけで、Outlook.comはメッセージを受け入れます。

いくつかのオプションがあります。

オプション＃1：サーバーごと/ドメインごとの例外ルールを実装します。これは、アクセステーブルにTry_TLS:<broken.server> NOを追加することで実行できます。既にこれを行っているようですが、「broken.server」の部分はIP、MXレコード（Microsoft-com.mail.protection.Outlook.com）、またはpartialMXレコード（Outlook.com）。

オプション＃2：すべてのドメインにバイパスルールを実装します。これは、アクセステーブルにTry_TLS: NOを追加することで実行できます（指定する必要はありません） IP）。

技術的に、sendmail.mcファイルをハッキングして、sendmailがTLS機能をチェックしないようにすることもできます。微妙な変更が必要なため、これを行うことはお勧めしません。

3
Mike B

ソリューションを question から回答セクションに転送します。

この問題があり、それを理解できない人のために、根本的な原因と解決策を見つけました。

クライアント証明書がMicrosoftに送信されるのを防ぐことができなかったので、私の唯一の選択肢は、Microsoftがサーバーを拒否した理由を見つけることでした。証明書を作成するとき、ehloで提示されたものとは異なるサーバー名を使用していました。例えばmx1.example.comはheloおよびmx.example.com証明書内。不一致により、Microsoftは説明なしに接続を切断していました。

1
masegaloeh