最後の
Exchange Server に
おやすみを。

いいえ。SMTP セッションをプロキシし、届いたままの形で転送します。メールボックスも、キューも、スプールも、アーカイブもなく、メッセージ自体はヘッダーを含めて変更されずに通過します。Sendman が保持するのは構成だけです。

いいえ。Sendman は、アプリ登録も同意も不要で、テナント側で何も変更することなく、デバイスの資格情報を Microsoft Entra ID に対して検証します。CONTOSO\svc-scan のようなハイブリッドログインもそのまま動作します。

どちらの場合も支障はありません。ボールトの資格情報はディレクトリにまったく触れないため、プロンプトが表示される理由がありません。Entra ID アカウントも同様に動作します。厳しいポリシーを設定していても、多要素認証や条件付きアクセスが妨げになることはなく、デバイスにプロンプトが表示されることもありません。アカウントがどの名義で誰に送信できるかを決めるのは、Exchange Online のメールボックス権限ではなく Sendman のポリシーです。ボールトの資格情報でも Entra ID アカウントでも、送信者と受信者のルールが判断します。

暗号化なしのポートでも接続でき、ID、IP、ポリシーはまったく同じように適用されます。そのデバイスからの最初の区間を暗号化なしで受け入れるかどうかは、お客様の判断です。許可リストによって接続元は自社の送信元アドレスに限定され、Sendman から先は、バックエンドが対応していればセッションが暗号化されます。

これらは送信元ドメインに属し、実際に配信を行うバックエンド、つまり Exchange Online または Azure Communication Services が処理します。Sendman はエンベロープもヘッダーも書き換えないため、そのバックエンド向けに設定してある内容は、現在とまったく同じように機能し続けます。

接続は一時的な「service not available」応答で拒否されます。この応答は、正しく実装された送信側にメッセージを保持して再試行するよう伝えるため、ストレージに一時的な障害があってもメールは失われず、遅れるだけです。

はい。多くの組織が Exchange Online を配信経路として維持し、デバイスに必要な認証とポリシーのレイヤーとして Sendman を使っています。バックエンドは後から、デバイスに一切手を加えずに変更できます。

お客様のテナント専用に分離されたストレージに保存されます。資格情報は書き込まれる前に暗号化されます。ポータルへのアクセスはお客様のプラットフォームテナントを通じて行われ、閲覧者はすべてのルールを参照できますが変更はできず、管理者は構成を変更できます。許可リストのエントリ、ポリシー、資格情報のすべてに作成者が記録されます。

すべての認証失敗とポリシー違反は検索可能なイベントログに記録され、拒否したルールがエントリに明記されます。また、デバイスが受け取る応答から、どのチェックで拒否されたかがわかります。デバイスが提示している送信元アドレス、使用するユーザー名、名乗っている送信者を正確に表示するキャプチャウィンドウ、Sniff Mode はロードマップに掲載されています。