- ホーム
- /
- 投稿記事
コメントありがとうございます。
この記事の内容
フィードバックがある場合Control Hub でメールのデジタルアセットを作成して認証し、Webex Connect や Webex コンタクトセンターなどの Webex サービスに割り当てます。
概要
Control Hub のデジタルアセットを使用して、 Webex サービスがメールでのやり取りに使用するメールボックスと OAuth 2.0 認証を設定します。 Control Hub でアセットを管理し、承認された Webex ワークロードが共有デジタルアセットサービスを通じてアセットにアクセスします。
アセットを作成したら、それを使用する Webex サービスに割り当ててください。 認証が成功すると、Control Hubは受信メールの転送アドレスを生成します。 Webex Contact Centerでは、その後、アセットをメールエントリポイントに関連付けることができます。 別のWebexワークロードの場合は、アセットを作成した後、そのワークロードでセットアップを続行してください。
始める前に
- 組織のデジタル資産を管理できる管理者、顧客管理者、またはパートナー管理者としてControl Hubにサインインしてください。
- サポートされているメールプロバイダーを使用してください。 Webex Webex Connect コンタクトセンターとのインテグレーションでは、Gmail と Microsoft 365 がサポートされているプロバイダです。 プロバイダー固有の詳細については、電子メール-WXCCを参照してください。
- 設定したいメールボックスを用意してください。 サービスアカウントを使用している場合は、メールが送信され、そのメールボックスにアクセスできることを確認してください。
- IDプロバイダーの管理者と協力して、OAuthアプリケーションを登録し、 同意を付与し、SMTP AUTHや外部転送などのプロバイダー設定を有効にしてください。
- コールバックURLをコントロールハブからOAuthアプリケーションのリダイレクトURLにコピーし、メールアセット用に生成されたアドレスへの自動転送を設定する準備をしてください。
GmailをOAuth 2.0に対応させる準備をしてください
メールアセット用にGmailアカウントを準備するには：
| 1 |
Google Cloudコンソールにログインして、プロジェクトを作成するか、既存のプロジェクトを選択してください。 |
| 2 |
APIとサービス > OAuth同意画面に進み、「外部」を選択して、アプリ名、ユーザーサポートメール、開発者の連絡先情報を入力します。 |
| 3 |
アプリが「テスト中」のままの場合は、メールボックスまたはトークン生成IDをテストユーザーとして追加してください。 1つのプロジェクトには最大100人のテストユーザーが参加できます。 |
| 4 |
APIとサービス > 認証情報に進み、Webアプリケーション用のOAuthクライアントIDを作成し、クライアントIDとクライアントシークレットをコピーします。 |
| 5 |
Control HubにコールバックURLが表示されたら、OAuthクライアントに戻り、その値を承認済みリダイレクトURIとして追加してください。 |
| 6 |
本番環境で使用する場合は、OAuthアプリを公開し、要求された範囲に必要なGoogle検証をすべて完了してください。 |
| 7 |
コントロールハブの構成には、次のプロバイダーの値を記録してください。
テスト中の外部Google OAuthアプリの場合、 テストユーザーの認証と更新トークンは同意の7日後に期限切れになります。 アプリを本番用に公開してください。 Googleが更新トークンを返さない場合は、同意フローをもう一度実行して、そのオプションがある場合は、 認証に同意する前に明示的に確認したいを選択します。 グーグルのSMTP OAuthドキュメントでは、GmailのSMTP OAuthの範囲について説明しています。GoogleのOAuthオーディエンスガイダンスでは、 社内外のオーディエンスと公開状況に関する行動について説明しています。 |
マイクロソフト365をOAuth 2.0に備えましょう
メールアセット用にMicrosoft 365メールボックスを準備するには：
| 1 |
Microsoft Entra管理センターで、「アプリの登録」に移動し、「新規登録」を選択して、組織が許可しているアカウントタイプのアプリケーションを登録します。 |
| 2 |
アプリケーション（クライアント）IDとディレクトリ（テナント）IDを記録します。 |
| 3 |
認証に、Webプラットフォームを追加してください。 Control HubにコールバックURLが表示されたら、その値をリダイレクトURIとして追加します。 |
| 4 |
「証明書とシークレット」で、クライアントシークレットを作成し、その値をコピーしてからページを終了してください。 |
| 5 |
「 トークンを生成」を選択したときに使用される対話型認証コードフローについては、委任されたOffice 365 Exchange Online SMTP.Send権限 （https://outlook.office.com/SMTP.Send）を追加して、 offline_accessスコープをリクエストしてください。 組織の同意ポリシーで義務付けられている場合は、 管理者の同意を与えてください。 |
| 6 |
Microsoft 365管理センターで、「ユーザー」>「アクティブユーザー」に移動し、メールボックスユーザーを選択し、「メール」>「メールアプリの管理」を選択し、そのメールボックスの認証済みSMTPを有効にして、変更を保存します。 |
| 7 |
次のプロバイダーの値を記録してください。 {tenant-id} をアプリ登録のディレクトリ (テナント) IDに置き換えてください。
このインタラクティブなトークンフローには、委任された https://outlook.office.com/SMTP.Send スコープとoffline_accessを使用してください。 SMTP AUTHは、 それを必要とするメールボックスでのみ有効にしてください。 組織が最近Microsoft Entraの同意設定を変更した場合は、 変更が有効になるのを待ってからトークンを生成してください。 マイクロソフトのSMTP OAuthガイダンスは、 委任されたSMTP.Sendとoffline_accessを対象としています。 マイクロソフトのSMTP認証設定では、特定のメールボックスのSMTP認証を有効にする方法を説明しています。 |
コントロールハブでメールアセットを設定します
メールアセットを設定するには：
| 1 | |
| 2 |
「サービス」>「デジタル資産」に移動します。 |
| 3 |
[アセットを作成] を選択します。 |
| 4 |
「資産の詳細の設定」セクションで、次のフィールドに値を入力します。
|
| 5 |
メールプロバイダー > メールボックスに、アセットが使用するメールボックスのメールアドレスを入力します。 |
| 6 |
OAuth 2.0認証セクションで、次のフィールドに値を入力します。
|
| 7 |
IDプロバイダーで、Control HubからのコールバックURLをOAuthアプリケーションに追加し、プロバイダーの設定を保存して、リダイレクトURIが完全に一致することを確認します。 |
| 8 |
同意した人がメールボックスとは異なるメールアドレスを使用している場合は、「メールボックスのアドレスとは異なるメールアドレスを使用してトークンを生成する」を選択し、そのIDを入力します。 共有メールボックス:共有メールボックスには、 独自のサインイン認証情報はありません。 共有メールボックスにアクセスでき、 送信権限のあるユーザーと一緒にトークンを生成します。ユーザーは管理者権限を必要としません。 ユーザーのアドレスがメールボックスと異なる場合は、「 メールボックスのアドレスとは異なるメールアドレスを使用してトークンを生成する」を選択します。 |
| 9 |
[トークンを生成] を選択し、IDプロバイダーのサインインと同意フローを完了して、Control Hubに戻ります。 トークンの生成が成功すると、「アクセストークン」、「更新トークン」、「有効性」フィールドが自動的に入力されます。 同意制限：プロバイダーがユーザーの同意をブロックしている場合は、 認証に同意する前に、「明示的に確認したい」 をクリアしてください。 このオプションでは、 ユーザーが要求された同意を与えることができないため、認証が失敗する可能性があります。 代わりに、 プロバイダーの管理者に必要な同意を与えるよう依頼してください。 トークンの生成が機能しない場合：Gmailの場合は、 ユーザーがアプリを承認でき、アプリの公開ステータスが正しいことを確認してください。 Microsoft 365の場合は、offline_accessスコープ、同意ポリシー、リダイレクトURI、およびSMTP認証設定を確認してください。 プロバイダーの設定を修正して、トークンを再度生成してください。 トークンの更新:このサービスは、有効期限が切れる前にトークンを更新します。 テナントオーナーにトークンの再生を求める自動メールが届いたら、 アセットを開いて、もう一度 [トークンを生成] を選択してください。 |
| 10 |
トークンの生成が成功したら、「作成」を選択します。 資産が Webex コンタクトセンターに割り当てられている場合は、「エントリーポイントに移動」を選択し、コンタクトセンターの設定を続けてください。 別のWebexワークロードの場合は、確認ページを閉じて、そのワークロードの設定を続行してください。 |
インバウンドメール転送を設定する
まず、その資産用に生成された転送先住所をコピーします。
| 1 |
デジタルアセットで、メールアセットを開いて [設定] を選択します。 |
| 2 |
メールプロバイダー > メールボックスで、メールボックスのメールアドレスに関連付けられている転送アドレスをコピーします。 |
Gmailで転送を設定する
受信したGmailメッセージをメールアセットに転送するには：
| 1 |
Google Workspaceを使用している場合は、管理者が [アプリ] > [Googleワークスペース] > [Gmail] > [エンドユーザーアクセス] でメールボックスの組織単位の自動転送を許可していることを確認してください。 |
| 2 |
Gmailのサポートメールボックスにサインインして、[設定] > [すべての設定を表示] > [転送とPOP/IMAP] に移動します。 |
| 3 |
「転送先アドレスを追加」を選択し、Control Hubから転送先アドレスを貼り付けて、確認プロンプトを完了します。 Gmailは、生成されたアドレスに確認リンクまたはコードを送信します。 |
| 4 |
受信メールのOutbound Webhookペイロードから、またはメールアセットの復号化されたデバッグログのメール本文全体から、Webex Connect検証リンクまたはコードを取得します。 次に、Gmailの認証を完了してください。 |
| 5 |
Gmailの転送設定に戻り、ページを更新して、[受信メールのコピーを転送する] を選択し、Gmailがそのコピーに対して何をするかを選択して、[変更を保存] を選択します。 |
マイクロソフト365で転送を設定してください
受信したMicrosoft 365メッセージをメールアセットに転送するには：
| 1 |
新しいメッセージがControl Hubから転送先アドレスに送信されるように、 メールボックスの転送またはサポートメールボックスの受信トレイのルールを設定します。 |
| 2 |
Microsoft Defenderポータルで、メールボックスに適用される送信スパムポリシーを確認してください。 自動転送ルールをオンに設定してください -セキュリティ管理者が承認した範囲が狭いポリシーで転送が有効になっています。 |
| 3 |
Exchange Onlineで、該当するリモートドメイン設定で、転送先アドレスドメインへの自動転送が許可されていることを確認してください。 |
| 4 |
Exchangeのメールフロールールを見直して、自動的に転送されたメッセージをブロックするルールがないことを確認してください。 例外が必要な場合は、サポートメールボックスと承認された宛先に限定してください。 |
| 5 |
転送設定を保存して、Microsoft 365ポリシーの変更が有効になるまで待ってください。 必須:転送が有効になるまで 、受信メールは割り当てられた Webex ワークロードに届きません。 Microsoft 365では、送信スパムをブロックするポリシー、 リモートドメイン設定、またはメールフロールールが、転送を許可する設定よりも優先されます。 添付ファイル制限：受信メールの添付ファイルは25 MBに制限されています。 添付ファイルが大きすぎるためにメッセージが失敗した場合、 送信者は配信失敗メッセージを受け取り、小さい添付ファイルで再送信する必要があります。 インライン画像：インライン画像は、エージェントのデスクトップに添付ファイルとして届きます。 PCIスキャンが有効になっていると、それらの画像はブロックされます。 Microsoft Outlook添付ファイル：制限により、.msgファイルが添付された受信メールは、 その.msgにファイルが埋め込まれていない状態で届くことがあります。Microsoft Outlook |
メール資産をテストしてください
完全なメールパスを確認するには：
| 1 |
外部のメールアカウントから、設定されたサポートメールボックスにメッセージを送信し、メッセージが割り当てられたWebexワークロードに届くことを確認します。 |
| 2 |
割り当てられたWebexワークロードから、新しいメッセージを送信するか、インバウンドメッセージに返信して、外部の受信者が受信していることを確認します。 配信ステータス： SMTPチャネルを介して送信されるメールには配信追跡が含まれていません。また、 サービスは配信失敗の通知を受け取りません。 テスト中に受信者のメールボックスからの配信を確認します。 |
| 3 |
インバウンド配送が機能しない場合は、プロバイダーの転送先住所の確認、転送ルール、組織の転送ポリシーを確認してください。 |
| 4 |
アウトバウンド送信が機能しない場合は、SMTPサーバーとポート、プロバイダーの権限、クライアントの資格情報、同意、Microsoft 365 SMTP AUTH設定、およびトークンの状態を確認してください。 問題を解決し、必要に応じてトークンを再生成してください。 |
