POP3 または IMAP の Microsoft Exchange メールアカウント経由で ServiceNow インスタンスにメールが配信されないIssue Microsoft Exchange Server (サーバー = メールアカウントレコードの Outlook.office365.com) を使用するインスタンスで、POP3 または IMAP メールアカウントを構成したとします。 Exchange Server のメールのバックログを観察すると、メールアカウントがアクティブで、インスタンスの接続テストが合格しているにもかかわらず、メールがインスタンスによって読み取られていないことがわかります。この結果、Exchange Server 上のメールのバックログは増え続けます。 インスタンス上のメールリーダーの動作 (POP3 または IMAP プロトコルを使用したメールの読み取り) では、インスタンスは 1 サイクルで 20 件のメール (デフォルトまたはシステムプロパティ com.glide.email.max_read で定義されている別の数) を読み取ります。 これらのメールがインスタンスに読み取られると、メールサーバーに削除コマンドが送信され、読み取られたメールがメールサーバーから削除されます。その後、次の 20 件が読み取られ、それらの削除コマンドが送信され、すべてのメールが処理されるまで繰り返されます。 メールサーバーで削除処理がうまくいかないと、インスタンスは同じ20 件のメールを何度も読み続けることになります。 この問題をデバッグするには、glide.pop3.debug または glide.imap.debug (アカウントが POP3 を使用するか IMAP プロトコルを使用するかによって異なります) を true に設定します。 glide.pop3.debug または glide.imap.debug システムプロパティを有効にすると、wrapper_<data>.log で読み取られたメール (Message-ID で識別される) が削除されることがわかります。 2023-11-10 00:01:13 (609) worker.7 worker.7 txid=8f0891e32984 DEBUG: 日付: Fri, 10 Nov 2023 00:01:13 -0800 (PST)2023-11-10 00:01:13 (609) worker.7 worker.7 txid=8f0891e32984 DEBUG: 差出人: instance@service-now.com2023-11-10 00:01:13 (609) worker.7 worker.7 txid=8f0891e32984 DEBUG: 返信先: <instance@service-now.com>2023-11-10 00:01:13 (609) worker.7 worker.7 txid=8f0891e32984 DEBUG: 宛先: 受信者2023-11-10 00:01:13 (609) worker.7 worker.7 txid=8f0891e32984 DEBUG: Message-ID: <123@app123.ytz3.service-now.com>2023-11-10 00:01:13 (609) worker.7 worker.7 txid=8f0891e32984 DEBUG: 件名: 非常に重要なメール ... ... ... 2023-11-10 00:01:13 (751) worker.7 worker.7 txid=8f0891e32984 DEBUG: .2023-11-10 00:01:13 (834) worker.7 worker.7 txid=8f0891e32984 DEBUG: 250 2.0.0 Ok: B62B22031E40 としてキューに登録2023-11-10 00:01:13 (834) worker.7 worker.7 txid=8f0891e32984 DEBUG: SMTP: メッセージがメールサーバーに正常に配信されました2023-11-10 00:01:13 (859) worker.7 worker.7 txid=8f0891e32984 [AMB] AMBQueue 公開された amb メッセージ, sys_id: 070891e3871a359083d08409cebb352d 2023-11-10 00:01:13 (861) worker.7 worker.7 txid=8f0891e32984 送信にかかった時間: 326ms2023-11-10 00:01:13 (875) worker.7 worker.7 txid=8f0891e32984 チャンクの開放にかかった時間: 13ms2023-11-10 00:01:13 (875) worker.7 worker.7 txid=8f0891e32984 DEBUG: NOOP2023-11-10 00:01:13 (876) worker.7 worker.7 txid=8f0891e32984 DEBUG: 250 2.0.0 Ok 2023-11-10 00:01:13 (875) worker.7 worker.7 txid=8f0891e32984 DEBUG: DELE 12023-11-10 00:01:13 (876) worker.7 worker.7 txid=8f0891e32984 DEBUG: 250 2.0.0 Ok メッセージは DELE 1 コマンドで削除され、メールサーバーから 250 2.0.0 OK 応答による確認応答がありますが、実際には Microsoft Exchange メールサーバー自体からメールは削除されていません。 そのため、メールリーダーが再び実行されると、既に読み取られて処理された同じメールをダウンロードし、同じ Message-ID を持つメールがすでにインスタンス上にあることを示す以下のようなログがシステムノードログに表示されます (この場合も glide.pop3.debug または glide.imap.debug システムプロパティが有効な場合)： 2018-06-01 09:51:29 (695) worker.3 worker.3 Message UID=‘123456' Message-ID='<SN50102MB309B2AB554843DE444A9620@SM44354.prod.sn..com>' は以前に読み取られているため、無視されます。 インスタンスで sys_email レコードを見ると、Message-ID='<SN50102MB309B2AB554843DE444A9620@SM44354.prod.sn..com>' で既にメールがインスタンスに存在していることがわかります。 Releaseこれはどの ServiceNow リリースにも当てはまります。CauseMicrosoft のメールサーバーからメッセージが削除されないのは、メールアカウントが「訴訟ホールド」または「保持ホールド」になっていることが原因である可能性があります。それ自体は、メールサーバー上での削除を阻止するものではありませんが、アカウントが「訴訟ホールド」または「保持ホールド」になっている間、アカウントに対して許可される削除メールの容量は 100GB に制限されます。「訴訟ホールド」または「保持ホールド」中にこの 100GB のしきい値に達した場合、ServiceNow インスタンスによって送信された削除コマンドは Microsoft メールサーバーによって処理されず、この問題が発生します。 また、別の理由として、メールボックスユーザーがメールを自動的にアーカイブに移動するよう設定していないことが考えられます。 そして最後に、メイン受信トレイ (メールリーダーがメールを取得する受信トレイ) から [削除済みアイテム] のサブフォルダーが外れている状態で、メール管理者がそのサブフォルダーに対して長時間の削除処理を手動で開始していたという事例があります。その [削除済みアイテム] サブフォルダーからは何万件ものメールが削除されており、このプロセスがまだ実行中であることが、親の受信トレイでの削除を妨げているようでした。以下の「代替/ワークアラウンドソリューション」を参照してください。 wrapper_<data>.log で、インスタンスによって送信された削除コマンド (DELE) に対して、 Microsoft のメールサーバーから +OK が表示されていても、実際には、メールは Microsoft のメールサーバーから削除されていません。Resolution注意: この問題は ServiceNow 側では修正できません。 「訴訟ホールド/保持ホールド」とアーカイブの設定については、Microsoft サポートが提供する以下のナレッジドキュメントを参照してください。これらのドキュメントで問題が解決しない場合は、Microsoft サポートにお問い合わせください： https://support.office.com/en-us/article/increase-the-recoverable-items-quota-for-mailboxes-on-hold-a8bdcbdd-9298-462f-b889-df26037a990c https://technet.microsoft.com/en-us/library/dn743673(v=exchg.160).aspx https://support.office.com/en-us/article/Delete-items-in-the-Recoverable-Items-folder-of-cloud-based-mailboxes-on-hold-Admin-Help-a85e1c87-a48e-4715-bfa9-d5275cde67b0?ui=en-US&rs=en-US&ad=US https://www.youtube.com/watch?v=8Rar2WJc6Ro 代替/ワークアラウンドソリューション (1) 状況によっては、メールボックスの名前を変更し、元の名前で新しいメールボックスを作成することがワークアラウンドになる可能性があります。たとえば、メールボックス support@<customer.com> の名前を support2@<customer.com> に変更し、新しいメールボックス support@<customer.com> を以前と同じパスワードで再作成します。これは、ServiceNow 側で変更が不要であることを意味します (メールアカウントであっても)。 これは、元のメールボックス (support@<customer.com>) のサブフォルダーに対して長時間実行される削除処理が、その効果を妨げている状況において機能しました。一方、問題の原因が「訴訟ホールド」または「保持ホールド 」である場合、機能しない可能性があります。 (2) システムプロパティ com.glide.email.max_read を作成し、20 より大きな値 (50、100、500 など) に設定します。これにより、より多くのメールがインスタンスに読み取られるようになります。 しかし、これでは未読メールが com.glide.email.max_read の新しい制限に再び到達するまで蓄積され続けるため、問題の解決にはなりません。この場合、メールの読み取りは再び停止されます。 アカウントの問題が解決したら、com.glide.email.max_read プロパティを削除するか、デフォルト値の 20 に戻します。