為何使用者會將訊息報告為已遞送但未收到?

有時會將訊息報告為遞送，但使用者未收到訊息，原因如下:

• 他們被電信運營商拒絕。 如果在一段時間內重複相同的訊息，則操作員會將訊息分類為 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 目的地，例如電子郵件、SMS、Webhook、Slack 及 Microsoft 團隊。 此外，您還可以訂閱推送類型的目的地，例如 android、iOS,Firefox、chrome 和 safari。

  如果送入通知滿足為 Topic (T) 撰寫的條件，則不論目的地類型為何，都會將通知遞送至所有訂閱或連接至 Topic (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 屬性，以便它符合主題條件及 ibmenpushto ，以使用 android 及 iOS 裝置將客戶設為目標。
  5. Event Notifications 將遞送至具有 android 及 iOS 裝置的客戶，因為其有效負載包含 "notification-type":"maintenance" ，其符合主題 ACME-Maintenance 及 "ibmenpushto": "{\"platforms\":[\"push_android\",\"push_ios\"]]}" 的條件，因為 ibmenpushto 是推送類型 Event Notifications 目的地的必要項目。

  所有推送裝置將在類型為 push 的 Event Notifications 目的地下登錄。 例如，push-android、push-ios 及其他。

• 要推送裝置的 Event Notifications 標籤訂閱:

  例如，ACME Bank 想要使用 android 及 iOS 裝置將維護事件通知遞送給客戶。 ACME Bank 維護通常一次在一個地區進行。

  ACME Bank 想要在地區特定標籤下登錄其客戶的每個 android 和 iOS 裝置。

  1. 為了達到此目的，銀行可以使用 Event Notifications Android Client SDK 和 iOS Client SDK 來訂閱 AP 標籤下的 Asia Pacific 客戶 android 和 iOS 裝置。

     使用下列鏈結，以進一步瞭解如何使用 Event Notifications Client SDK 來訂閱推送裝置:

     • Android 推送通知 (FCM)
     • iOS 推送通知 (APN)
     • Chrome 推送通知
     • Firefox 推送通知
     • Safari 推送通知

  2. 接下來，銀行會傳送有效負載包含屬性 "notification-type":"maintenance" 及 "ibmenpushto": "{\"tags\":[\"AP\""]]}" 的通知，並新增 notification-type 屬性，使其符合主題條件及 ibmenpushto，因為訊息是針對亞太地區具有 Android 及 iOS 裝置的推送客戶 AP。

為電子郵件和 SMS 配置 Event Notifications 之後，為何看不到我所傳送的電子郵件或 SMS 通知?

只有 IBM 受管理來源 (IBM Cloud 服務) 才支援電子郵件和 SMS。 您可以將通知從 API 來源傳送至所有其他目的地，但電子郵件和 SMS 除外。

在「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。 在將訊息內容傳送至目的地之前，一般使用者無法修改訊息內容。

為何我收到「傳送通知」API 呼叫的 422 錯誤回應?

Event Notifications 服務無法處理您的要求。 當沒有條件或過濾器與通知傳送至的主題相關聯時，通常會看到此情況。 請檢查您的主題，並驗證它已連接至具有預期條件的正確來源。

即使在我可以看到已順利傳送通知的日誌中，為何我傳送的電子郵件通知未送達客戶?

這可能是因為您的 Event Notifications 實例已針對 smtp_ibm 目的地建立訂閱，且未將電子郵件 ID 作為收件者新增至訂閱清單。

請確定您的 Event Notifications 實例已建立 smtp_ibm 目的地的訂閱，且至少已新增一個電子郵件 ID 作為訂閱清單的收件者。

是否可以使用 Event Notifications將通知傳送至多個目的地?

是。 您可以將通知傳送至多個目的地。

事件通知的自訂網域電子郵件目的地與 IBM Cloud 電子郵件目的地之間有何差異?

透過 IBM Cloud 電子郵件目的地傳送的電子郵件是代表 IBM Cloud 從來源傳送 (亦即，寄件者的電子郵件網域一律會有 ".event-notifications.cloud.ibm.com")。 另一方面，自訂電子郵件目的地可讓您新增自己的網域位址，寄件者可以透過該位址傳送電子郵件。

此外，由於安全原因，API 來源無法將通知傳送至 IBM Cloud 電子郵件目的地，另一方面，自訂網域電子郵件目的地可以從任何類型的來源接收通知。

何謂 SPF 驗證?

SPF (Sender Policy Framework) 驗證是一種電子郵件鑑別方法，設計為容許電子郵件收件者驗證電子郵件訊息源自授權來源，以防止電子郵件盜用及網路釣魚。 SPF 透過定義特定網域的授權郵件伺服器 (IP 位址) 清單來運作。 當收到電子郵件時，收件者的郵件伺服器可以檢查傳送郵件伺服器的 IP 位址是否在寄件者網域的授權伺服器清單上。

SPF 可協助防止未獲授權的來源代表網域傳送電子郵件，減少網路釣魚攻擊及垃圾郵件的可能性。 不過，請務必注意，僅 SPF 並不會提供端對端電子郵件安全。 其他電子郵件鑑別機制 (例如 DKIM (DomainKeys 已識別郵件) 及 DMARC (網域型訊息鑑別、報告及相符性)) 通常與 SPF 一起使用，以取得更完整的電子郵件鑑別及反網路釣魚策略。

何謂 DKIM 驗證?

DKIM (DomainKeys 已識別郵件) 驗證是一種電子郵件鑑別方法，用來驗證電子郵件訊息的確實性及完整性。 DKIM 可讓電子郵件收件者檢查電子郵件訊息是否從授權來源傳送，以及在傳送期間是否已變更，以協助防止電子郵件盜用、網路釣魚及竄改。

DKIM 驗證提供強大的電子郵件鑑別機制，因為它會以加密方式驗證寄件者的身分，並確保電子郵件的完整性。 它通常與其他電子郵件鑑別方法 (例如 SPF (傳送端原則架構) 及 DMARC (網域型訊息鑑別、報告及相符性)) 一起使用，以提供綜合性的電子郵件安全架構。

透過實作 DKIM，網域擁有者可以提高其電子郵件通訊的可信度，減少其網域用於網路釣魚攻擊的可能性，並提高電子郵件遞送能力。

SPF 驗證如何運作?

1. 寄件人會發佈 SPF 記錄: 網域的擁有者 (寄件人) 會在其網域的 DNS (網域名稱系統) 記錄中發佈 SPF 記錄。 此 SPF 記錄指定授權哪些郵件伺服器代表該網域傳送電子郵件。

2. 已傳送電子郵件: 從該網域傳送電子郵件時，收件者的郵件伺服器可以透過查閱寄件者網域的 SPF 記錄來執行 SPF 檢查。

3. SPF 記錄檢查: 收件者的郵件伺服器會檢查傳送郵件伺服器的 IP 位址是否在 SPF 記錄中列為授權寄件者。 如果是，則電子郵件視為合法; 如果不是，則可能會標示為可疑或拒絕。

4. 結果: SPF 檢查會產生下列三個結果之一:

   • 通過: 傳送伺服器的 IP 位址會列在 SPF 記錄中，指出電子郵件是合法的。
   • 失敗: 傳送伺服器的 IP 位址未列在 SPF 記錄中，建議電子郵件可能未獲授權。
   • 正常失敗: SPF 記錄建議謹慎，但不會立即拒絕電子郵件。

DKIM 驗證如何運作?

1. 訊息簽署: 從已啟用 DKIM 的網域傳送電子郵件時，傳送郵件伺服器會使用私密金鑰數位簽署電子郵件訊息。 此簽章包括電子郵件內容及寄件者網域的相關資訊。

2. DNS 記錄: 傳送者的網域會在其 DNS (網域名稱系統) 記錄中發佈 DKIM 公開金鑰。 接收郵件伺服器會使用此公開金鑰來驗證步驟 1 中套用的簽章。

3. 電子郵件傳輸: 電子郵件會傳輸至收件者的郵件伺服器。

4. DKIM 驗證: 在接收電子郵件時，收件者的郵件伺服器會使用電子郵件的「寄件者」標頭中找到的網域，從寄件者的 DNS 記錄中擷取 DKIM 公開金鑰，以執行 DKIM 驗證。

5. 簽章驗證: 收件者的郵件伺服器使用 DKIM 公開金鑰來驗證電子郵件上的數位簽章。 如果簽章有效，則表示電子郵件在傳輸期間未遭竄改，且源自授權來源。

6. 結果: DKIM 驗證處理程序會產生下列其中一個結果:

   • 通過: 電子郵件的 DKIM 簽章有效，指出電子郵件合法且未遭竄改。
   • 失敗 :DKIM 簽章無效或遺漏，表示電子郵件可能可疑或偽造。

什麼是電子郵件個人化？

電子郵件個人化是指根據個別收件者或特定收件者群組的喜好設定、行為、個人背景資訊或其他資料來自訂電子郵件內容和傳訊的作法。 電子郵件個人化的目標是為收件者建立更相關且更吸引人的電子郵件體驗，這可能導致更高的開啟率、點閱率及轉換率。

何謂兩種類型的範本?

範本有兩種類型: 邀請範本和通知範本。 「邀請」範本是用來將自訂的電子郵件邀請傳送給所有新增至訂閱的人員，而在傳送事件的電子郵件時則會使用「通知」範本。 它可以包括 HTML 標籤、handlebar 支援及個人化支援。

什麼是用戶端超時？

用戶端逾時是指用戶端 (例如 Web 瀏覽器或應用程式) 等待伺服器回應的期間。 如果伺服器無法在這個指定的時間範圍內回應，則會發生逾時，指出連線已中斷或伺服器沒有回應。

為何發生用戶端逾時?

用戶端逾時可能因各種原因而發生，例如網路連線功能緩慢、伺服器超載、配置錯誤，或用戶端應用程式發生問題。 當用戶端在定義的逾時期間內未收到來自伺服器的回應時，它會假設發生問題並終止連線。

如何判斷是否發生用戶端逾時?

嘗試存取網站、應用程式或服務時，您可能會遇到用戶端逾時。 一般指示器包括錯誤訊息，例如 Connection Timed Out 或 Request Timed Out。 伺服器端上的監視工具及日誌也可能提供逾時事件的見解。

如何疑難排解用戶端逾時?

• 檢查您的網際網路連線: 請確定您的網際網路連線穩定且未發生任何中斷。
• 驗證伺服器狀態: 確認「事件通知服務」可用，且未報告任何突發事件。
• 調整逾時設定: 部分應用程式容許使用者調整逾時設定。 可能的話，請考慮延長逾時持續時間，以容納可能的延遲。

開發人員如何在其應用程式中處理用戶端逾時?

開發人員可以實作各種策略，包括最佳化程式碼以取得更好的效能、利用非同步程式設計，以及實作重試機制。 此外，為使用者提供清楚的錯誤訊息及疑難排解指引，可以加強整體使用者體驗。

用戶端逾時一律是伺服器問題的結果嗎?

不必然。 雖然伺服器相關問題是用戶端逾時的常見原因，但用戶端上的問題 (例如網路問題或配置錯誤的設定) 也可能導致逾時。 在疑難排解逾時問題時，必須同時調查用戶端和伺服器層面。

如果我經常遇到客戶逾時，該怎麼辦?

如果您持續遇到客戶逾時，請考慮聯絡支援團隊。