メッセージが配信済みとして報告されているが、ユーザーが受信していないのはなぜですか。

メッセージが配信済みとして報告されても、以下の理由でユーザーによって受信されない場合があります。

• 通信オペレーターによって拒否されます。 同じメッセージが一定期間にわたって繰り返されると、メッセージはオペレーターによって SPAM メッセージとして分類されます。

解決策としては、メッセージ本文に TransactionID 、 ReferenceID。 これらの ID は SMS をトランザクションとして分類し、オペレーターによってブロックされることはありません。

• ユーザーがオプトアウトします。 Opt Out、 Stop、 Exit のようなオプトアウト・テキストを送信してユーザーがメッセージングをオプトアウトした場合、メッセージはそのユーザーに届かず、ステータスレポートにはその旨が記載されます。 ユーザーは、Opt inメッセージを同じソースに送信して、メッセージの受信を再開できます。

一部のデバイスが無効としてマークされ、データベースから削除されるのはなぜですか?

場合によっては、デバイスが以下の無効な条件を満たすと、無効としてマークされ、データベースから削除されることがあります。

• FCM または Android デバイス:

  • invalidRegistration-誤った登録トークン・フォーマットがサーバーに渡されたことが原因である可能性があります。
  • MismatchSenderID-登録トークンに結合されているユーザー・グループの一部ではない senderID の不一致。
  • NotRegistered-さまざまな理由 (クライアント・アプリケーションが FCM で登録抹消された、トークンが無効である、登録トークンの有効期限が切れた、更新されたがメッセージを受信するように構成されていない新しいバージョンのクライアント・アプリケーションなど) による無効な登録トークン。

  詳しくは、 ダウンストリーム・メッセージの FCM エラー応答コードを参照してください。

• APNS デバイスまたは Safari デバイス:

  • Unregistered-指定されたトピックのデバイス・トークンがアクティブではありません。
  • BadDeviceToken-指定された装置トークンが無効です。
  • DeviceTokenNotForTopic-デバイス・トークンが、指定されたトピック (バンドル ID) と一致しません。

  アプリからの通知応答を処理する方法について詳しくは、 ここを参照してください。

• Chrome または Firefox デバイス:

  • NotFound-サブスクリプションは有効期限が切れており、使用できません。
  • Gone-サブスクリプションは無効になりました。

  詳しくは、 Web プッシュ・プロトコル を参照してください。

プッシュ・デバイスに対するトピック・サブスクリプションとタグ・サブスクリプションの違いは何ですか?

• Event Notifications トピック・サブスクリプション:

  トピック・サブスクリプションの場合は、まず トピック を作成し、そのトピックに条件を記述します。 このトピックは、トピック条件を満たす着信通知のルーティングを担当します。

  複数の Event Notifications 宛先 (E メール、SMS、Webhook、Slack、Microsoft チームなど) をサブスクライブできます。 また、Androidなどのプッシュタイプの宛先を購読することもできます。 iOS,Firefox、Chrome、Safari です。

  着信通知がトピック (T) に対して作成された条件を満たす場合、宛先のタイプに関係なく、サブスクライブまたはトピック (T) に接続されたすべての宛先に通知をルーティングします。

  例えば、 ACME Bank は、Android デバイスおよび iOS デバイスを使用して、保守イベント通知をお客様に送付したいと考えています。 Acme Bank は、以下のステップを実行しています。

  1. ACME-Maintenance という名前のトピックを作成します。
  2. 書き込み拡張条件 $.notification-type == 'maintenance'。
  3. プッシュ android をサブスクライブし、 iOS 宛先をトピックにプッシュします。
  4. 次に、属性 "notification-type":"maintenance"および "ibmenpushto": "{\"platforms\":[\"push_android\",\"push_ios\"]]}"を含むペイロードを持つイベント通知を送信します。これにより、 notification-type 属性が追加され、トピック条件と一致するようになります。また、Android デバイスおよび iOS デバイスを使用するお客様をターゲットにするために、 ibmenpushto が追加されます。
  5. Event Notifications は、Android デバイスと iOS デバイスを持つお客様にルーティングされます。これは、プッシュ・タイプ Event Notifications の宛先には ibmenpushto が必須であるため、そのペイロードには、トピック ACME-Maintenance および "ibmenpushto": "{\"platforms\":[\"push_android\",\"push_ios\"]]}" の条件に一致する "notification-type":"maintenance" が含まれているためです。

  すべてのプッシュ・デバイスは、プッシュ・タイプの Event Notifications 宛先に登録されます。 例えば、 push-android、 push-ios、その他です。

• プッシュ・デバイスへの Event Notifications タグ・サブスクリプション:

  例えば、 ACME Bank は、Android デバイスおよび iOS デバイスを使用して、保守イベント通知をお客様に送付したいと考えています。 ACME 銀行の保守は通常、一度に 1 つの地域で行われます。

  ACME Bank は、お客様の Android デバイスと iOS デバイスのそれぞれを地域固有のタグの下に登録したいと考えています。

  1. これを実現するために、銀行は Event Notifications Android Client SDK および iOS Client SDK を使用して、 AP タグの下で Asia Pacific お客様の Android デバイスおよび iOS デバイスをサブスクライブできます。

     Event Notifications クライアント SDK を使用してプッシュ・デバイスをサブスクライブする方法について詳しくは、以下のリンクを使用してください。

     • Android プッシュ通知 (FCM)
     • iOS プッシュ通知 (APNs)
     • Chrome プッシュ通知
     • Firefox プッシュ通知
     • Safari プッシュ通知

  2. 次に、銀行は、属性 "notification-type":"maintenance" および "ibmenpushto": "{\"tags\":[\"AP\""]]}" を含むペイロードを持つ通知を送信します。 notification-type 属性が追加されて、トピック条件に対して突き合わせが行われます。また、 ibmenpushto メッセージは、アジア太平洋地域の Android デバイスおよび iOS デバイス AP を持つプッシュ顧客をターゲットにするためのものであるため、この属性が追加されます。

Event Notifications を E メールおよび SMS 用に構成した後に送信した E メール通知または SMS 通知が表示されないのはなぜですか?

E メールおよび SMS は、 IBM 管理対象ソース (IBM Cloud サービス) でのみサポートされます。 E メールと SMS を除く他のすべての宛先に API ソースから通知を送信できます。

Slack 宛先構成の Slack チャネル名はどこで指定できますか?

Event Notifications は、Slack の「着信 Webhook」機能を使用して Slack 宛先をサポートします。 着信 Webhook は、Slack チャネルに直接リンクされます。 そのため、Slack チャネルを個別に指定する必要はありません。

IBM Cloud サービス (IBM Cloud ソース) から生成されるメッセージをカスタマイズできますか?

IBM Cloud サービス (IBM Cloud ソース) から生成されるメッセージをカスタマイズすることはできません。 これらの通知は、それぞれの IBM Cloud サービス ( Secrets Manager、および Security and Compliance Centerなど) によって生成されます。 メッセージの内容は、宛先に送信される前にエンド・ユーザーが変更することはできません。

「通知の送信 (Send Notifications)」API 呼び出しに対して 422 エラー応答が表示されるのはなぜですか?

Event Notifications サービスが要求を処理できません。 これは通常、通知の送信先のトピックに関連付けられた条件またはフィルターがない場合に表示されます。 トピックを調べて、意図した条件で正しいソースに接続されていることを確認してください。

正常に送信された通知がログに表示されても、送信された E メール通知が顧客に届かなかったのはなぜですか?

これは、 Event Notifications インスタンスに smtp_ibm 宛先用に作成されたサブスクリプションがあり、サブスクリプションのリストに受信者として追加された E メール ID がないことが原因である可能性があります。

Event Notifications インスタンスに、smtp_ibm 宛先用に作成されたサブスクリプションがあり、少なくとも 1 つの E メール ID がサブスクリプションのリストに受信者として追加されていることを確認します。

Event Notificationsを使用して複数の宛先に通知を送信できますか?

はい。 複数の宛先に通知を送信できます。

イベント通知のカスタム・ドメイン E メール宛先と IBM Cloud E メール宛先の違いは何ですか?

IBM Cloud E メール宛先を介して送信される E メールは、 IBM Cloud の代わりにソースから送信されます (つまり、送信者の E メール・ドメインは常に「.event-notifications.cloud.ibm.com」を持ちます)。 一方、カスタム E メール宛先を使用すると、送信者が E メールの送信に使用できる独自のドメイン・アドレスを追加できます。

また、セキュリティー上の理由により、API ソースは IBM Cloud E メール宛先に通知を送信できません。一方、カスタム・ドメイン E メール宛先は、あらゆる種類のソースから通知を受け取ることができます。

SPF 検証とは何ですか?

SPF (Sender Policy Framework) 検証は、E メール・メッセージの発信元が許可されたソースであることを E メール受信者が確認できるようにすることで、E メールのスプーフィングやフィッシングを防止するように設計された E メール認証方式です。 SPF は、特定のドメインの許可メール・サーバー (IP アドレス) のリストを定義することによって機能します。 E メールが受信されると、受信者のメール・サーバーは、送信メール・サーバーの IP アドレスが送信者のドメインの許可サーバーのリストにあるかどうかを検査できます。

SPF は、無許可の送信元がドメインに代わって E メールを送信することを防止し、フィッシング攻撃やスパムの可能性を低減します。 ただし、SPF のみではエンドツーエンドの E メール・セキュリティーが提供されないことに注意してください。 DKIM (DomainKeys Identified Mail) や DMARC (Domain-based Message Authentication, Reporting, and Conformance) などのその他の E メール認証メカニズムは、多くの場合、より包括的な E メール認証とアンチフィッシング戦略のために SPF と組み合わせて使用されます。

DKIM 検証とは何ですか?

DKIM (DomainKeys Identified Mail) 検証は、E メール・メッセージの認証性と保全性を検証するために使用される E メール認証方式です。 DKIM は、E メール・メッセージが許可されたソースから送信されたかどうか、および転送中に変更されたかどうかを E メール受信者が確認できるようにすることで、E メールのスプーフィング、フィッシング、および改ざんを防止するのに役立ちます。

DKIM 検証は、送信者の ID を暗号的に検証し、E メールの整合性を保証するため、E メール認証の強力なメカニズムを提供します。 多くの場合、包括的な E メール・セキュリティー・フレームワークを提供するために、SPF (Sender Policy Framework) や DMARC (Domain-based Message Authentication, Reporting, and Conformance) などの他の E メール認証方式と組み合わせて使用されます。

DKIM を実装することにより、ドメイン所有者は E メール通信の信頼性を高め、ドメインがフィッシング攻撃に使用される可能性を減らし、E メールの配信到達性を向上させることができます。

SPF 検証はどのように機能しますか?

1. 送信者は SPF レコードを公開します。ドメインの所有者 (送信者) は、ドメインの DNS (ドメイン・ネーム・システム) レコードに SPF レコードを公開します。 この SPF レコードは、そのドメインの代わりに E メールを送信する権限があるメール・サーバーを指定します。

2. 送信済み E メール: そのドメインから E メールが送信されると、受信者のメール・サーバーは、送信者のドメインの SPF レコードを検索して SPF チェックを実行することができます。

3. SPF レコード検査: 受信側のメール・サーバーは、送信メール・サーバーの IP アドレスが SPF レコードに許可送信側としてリストされているかどうかを検査します。 正当である場合、E メールは正当であると見なされます。正当でない場合、疑わしいとしてマークされたり、拒否されたりする可能性があります。

4. 結果: SPF チェックは、以下の 3 つの結果のいずれかを生成します。

   • Pass: 送信サーバーの IP アドレスが SPF レコードにリストされ、E メールが正当であることを示します。
   • 失敗: 送信サーバーの IP アドレスが SPF レコードにリストされていません。これは、E メールが許可されていない可能性があることを示しています。
   • ソフト失敗: SPF レコードは注意を示していますが、E メールは即時に拒否されません。

DKIM 検証はどのように機能しますか?

1. メッセージ署名: DKIM が有効になっているドメインから E メールが送信されると、送信メール・サーバーは秘密鍵を使用して E メール・メッセージにデジタル署名します。 この署名には、E メールのコンテンツと送信者のドメインに関する情報が含まれます。

2. DNS レコード: 送信側のドメインは、DNS (ドメイン・ネーム・システム) レコードに DKIM 公開鍵を公開します。 この公開鍵は、ステップ 1 で適用した署名を検証するためにメール・サーバーを受信することによって使用されます。

3. E メール送信: E メールは受信者のメール・サーバーに送信されます。

4. DKIM 検証: E メールを受信すると、受信者のメール・サーバーは、E メールの「From」ヘッダーにあるドメインを使用して送信者の DNS レコードから DKIM 公開鍵を取得することにより、DKIM 検証を実行します。

5. 署名検証: 受信者のメール・サーバーは、DKIM 公開鍵を使用して、E メール上のデジタル署名を検証します。 署名が有効な場合は、転送中に E メールが改ざんされていないこと、および許可された送信元から送信されたことを意味します。

6. 結果: DKIM 検証プロセスの結果は、以下のいずれかになります。

   • 合格: E メールの DKIM 署名は有効であり、E メールが正当であり、改ざんされていないことを示します。
   • 失敗: DKIM 署名が無効であるか、欠落しています。これは、E メールが疑わしいか、偽造されている可能性があることを示しています。

メールのパーソナライズとは何ですか?

E メールのパーソナライズとは、個々の受信者または特定の受信者グループに対して、その好み、行動、人口統計、またはその他のデータに基づいて E メールの内容とメッセージを調整することを意味します。 E メールのパーソナライズの目的は、受信者に対してより関連性の高い魅力的な E メール・エクスペリエンスを作成することです。これにより、開封率、クリックスルー率、およびコンバージョンが向上する可能性があります。

2 つのタイプのテンプレートとは何ですか?

テンプレートには、招待テンプレートと通知テンプレートの 2 つのタイプがあります。 招待テンプレートは、サブスクリプションに追加されたすべてのユーザーにカスタマイズされた E メール招待を送信するために使用されます。一方、通知テンプレートは、イベントの E メールを送信するときに使用されます。 HTML タグ、ハンドル・バー・サポート、およびパーソナライズ・サポートを組み込むことができます。

クライアントのタイムアウトとは何ですか？

クライアント・タイムアウトとは、クライアント (Web ブラウザーやアプリケーションなど) がサーバーからの応答を待機する期間のことです。 この指定された時間フレーム内にサーバーが応答に失敗すると、接続が失われたか、サーバーが応答しないことを示すタイムアウトが発生します。

クライアント・タイムアウトが発生する理由

クライアント・タイムアウトは、ネットワーク接続の遅延、サーバーの過負荷、構成の誤り、クライアント・サイド・アプリケーションの問題など、さまざまな理由で発生する可能性があります。 定義されたタイムアウト期間内にクライアントがサーバーから応答を受信しない場合、クライアントは問題があると想定し、接続を終了します。

クライアント・タイムアウトが発生しているかどうかを判別するにはどうすればよいですか?

Web サイト、アプリケーション、またはサービスにアクセスしようとすると、クライアント・タイムアウトが発生することがあります。 共通標識には、 Connection Timed Out や Request Timed Out などのエラー・メッセージが含まれます。 サーバー・サイドのモニター・ツールおよびログも、タイムアウトの発生に関する洞察を提供する場合があります。

クライアントのタイムアウトをトラブルシューティングするにはどうすればよいですか?

• インターネット接続を確認してください。インターネット接続が安定しており、中断が発生していないことを確認してください。
• サーバー状況の確認: イベント通知サービスが使用可能であり、インシデントが報告されていないことを確認します。
• タイムアウト設定の調整: 一部のアプリケーションでは、ユーザーがタイムアウト設定を調整することができます。 可能な場合は、潜在的な遅延に対応するためにタイムアウト期間を延長することを検討してください。

開発者はアプリケーションでのクライアント・タイムアウトにどのように対処できますか?

開発者は、パフォーマンスを向上させるためのコードの最適化、非同期プログラミングの使用、再試行メカニズムの実装など、さまざまな戦略を実装できます。 さらに、ユーザーに明確なエラー・メッセージとトラブルシューティングに関するガイダンスを提供することで、全体的なユーザー・エクスペリエンスを向上させることができます。

クライアント・タイムアウトは常にサーバーの問題の結果ですか?

必ずしもそうではありません。 サーバー関連の問題はクライアント・タイムアウトの一般的な原因ですが、クライアント・サイドの問題 (ネットワークの問題や設定の構成の誤りなど) もタイムアウトの原因となる可能性があります。 タイムアウトの問題をトラブルシューティングする際には、クライアントとサーバーの両方の側面を調査することが重要です。

クライアントのタイムアウトが頻繁に発生する場合はどうすればよいですか?

クライアントのタイムアウトが常に発生する場合は、サポート・チームに連絡することを検討してください。