発生している事象について、取得できた情報から言えることは主に3点です。

1. #988 が必ずしも TLS 設定そのものの失敗を意味しない場合があります。
   
   InterSystems の SSL/TLS 構成画面の「テスト」は、TLS ハンドシェイク後に GET / HTTP/1.0 を送信して応答を読みに行く実装になっており、相手サーバーがそれを想定していない場合は接続を閉じるため、#988: SSL connection failed のように見えることがあります。一方で、その情報では実際の HTTP リクエスト自体は成功していたとされています。したがって、SSL/TLS構成のテストで #988 が出ても、それだけで Office 365 向け TLS 構成が誤っているとは断定できません。 [1]

2. Office 365 / Microsoft 側の基本認証廃止に対応する方向としては、OAuth 2.0 を使うのが適切です。
   
   取得した情報では、InterSystems は OAuth 2.0 クライアント機能を提供しており、外部の認可サーバー向けに authorization_endpoint、token_endpoint、jwks_uri、TLS/SSL 構成などを設定する形で連携できるとされています。また、Microsoft 向けの事例として、Azure Entra ID でのアプリ登録、リダイレクト URI の登録、/csp/sys/oauth2 の有効化、ログを使ったトラブルシュートが挙げられています。 [2]

3. メール送信で Microsoft 365 を使う場合、少なくとも取得資料上は「アクセストークンを取得して、それを接続処理に渡す」方式が示されています。
   
   取得した情報では、InterSystems 側で不足しがちなのは「アクセストークン取得」であり、そこは外部コードや Embedded Python などで補う実装例が紹介されています。トークン取得後は、そのアクセストークンをメール接続処理に渡すやり方が説明されています。したがって、Microsoft が基本認証を廃止した現在、従来のユーザー名/パスワードだけに依存した SMTP 接続ではなく、OAuth 2.0 前提の構成を検討すべきというのが、取得情報から導ける結論です。 [2][3][4]

補足すると、Outlook/Office 365 の SMTP 接続例に関する別の議論では、ポート 587 を使うなら STARTTLS を使う必要があるという指摘があり、%Net.SMTP を使う場合は SSL/TLS 構成を作成し、smtp.SSLConfiguration を設定し、smtp.UseSTARTTLS = 1 にすることが案内されています。 [5]

したがって、あなたのケースでは次を切り分けるのがよさそうです。

• #988 が SSL/TLS テスト画面だけで起きているのか、実際の送信処理でも起きているのかを分けて確認すること。テスト画面の失敗だけなら、相手サーバーの応答仕様による見かけ上の失敗の可能性があります。 [1]
• SMTP 認証方式がまだ Basic Authentication 前提になっていないか確認すること。Microsoft 365 では OAuth 2.0 利用が推奨方向として示されています。 [2][3][4]
• SMTP/587 を使うなら STARTTLS を有効にする設定になっているか確認すること。 [5]

なお、取得できた資料の中には、**「IRIS 上の smtp.office365.com で #988 が出る特定の TLS パラメータ不備」**を直接特定した情報はありませんでした。そのため、#988 の直接原因が Office 365 固有の証明書チェーン問題なのか、SMTP テスト方法による見かけの失敗なのか、あるいは認証方式の不一致なのかについては、ここで断定はできません。 [1][2][5]

Sources: