메시지가 전달된 것으로 보고되지만 사용자가 수신하지 못한 이유는 무엇입니까?

때때로 메시지는 전달된 것으로 보고되지만 다음과 같은 이유로 사용자에게 전달되지 않습니다.

• 통신회사에 의해 거부되었습니다. 동일한 메시지가 일정 기간 동안 반복되는 경우, 메시지는 운영자에 의해 스팸 메시지로 분류됩니다.

해결 방법은 메시지 본문에 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-구독이 더 이상 올바르지 않습니다.

  자세한 정보는 웹 푸시 프로토콜 을 참조하십시오.

푸시 디바이스에 대한 태그 구독과 토픽 구독 간의 차이점은 무엇입니까?

• Event Notifications 토픽 구독:

  토픽 구독의 경우 토픽 을 작성하여 시작하고 해당 토픽에 대한 조건을 작성하십시오. 이 주제는 주제 조건을 충족하는 수신 알림의 라우팅을 담당합니다.

  이메일, SMS, 웹훅, 슬랙 및 Microsoft팀과 같은 여러 Event Notifications 대상에 등록할 수 있습니다. 또한 안드로이드와 같은 푸시형 대상을 구독할 수 있으며, iOS, Firefox, 크롬, 사파리.

  수신 알림이 주제 (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 속성이 추가되어 토픽 조건에 대해 일치하고 ibmenpushto 가 Android및 iOS 디바이스를 사용하여 고객을 대상으로 지정합니다.
  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 Bank 유지보수는 일반적으로 한 번에 한 지역에서 수행됩니다.

  ACME Bank는 지역별 태그 아래에 각 고객의 Android및 iOS 디바이스를 등록하려고 합니다.

  1. 이를 수행하기 위해 은행은 Event Notifications Android Client SDK및 iOS Client SDK를 사용하여 AP 태그 아래의 Asia Pacific 고객의 Android및 iOS 디바이스에 등록할 수 있습니다.

     Event Notifications 클라이언트 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 알림이 표시되지 않는 이유는 무엇입니까?

이메일 및 SMS는 IBM 관리 소스 (IBM Cloud 서비스) 에 대해서만 지원됩니다. API 소스에서 이메일 및 SMS를 제외한 다른 모든 대상으로 알림을 전송할 수 있습니다.

Slack 대상 구성에서 Slack 채널 이름을 지정하는 위치는 어디입니까?

Event Notifications 는 Slack의 " 수신 Webhook 기능을 사용하여 Slack 대상을 지원합니다. 수신 웹훅은 Slack 채널에 직접 링크됩니다. 따라서 Slack 채널을 별도로 지정할 필요가 없습니다.

IBM Cloud 서비스 (IBM Cloud 소스) 에서 생성되는 메시지를 사용자 정의할 수 있습니까?

IBM Cloud 서비스 (IBM Cloud 소스) 에서 생성되는 메시지를 사용자 정의할 수 없습니다. 이러한 알림은 Secrets Manager및 Security and Compliance Center와 같은 각 IBM Cloud 서비스에 의해 생성됩니다. 메시지 컨텐츠는 대상으로 전송되기 전에 일반 사용자가 수정할 수 없습니다.

알림 전송 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 (Domain-based Message Authentication, Reporting, and Conformance) 와 같은 기타 이메일 인증 메커니즘은 종종 보다 포괄적인 이메일 인증 및 피싱 방지 전략을 위해 SPF와 함께 사용됩니다.

DKIM 검증의 개념

DKIM (DomainKeys 식별된 메일) 검증은 이메일 메시지의 인증 및 무결성을 검증하는 데 사용되는 이메일 인증 방법입니다. DKIM은 이메일 수신인이 승인된 소스에서 이메일 메시지가 전송되었는지 여부 및 전송 중에 변경되었는지 여부를 확인할 수 있도록 하여 이메일 스푸핑, 피싱 및 변조를 방지하는 데 도움을 줍니다.

DKIM 검증은 발신인의 ID를 암호로 확인하고 이메일의 무결성을 확인하므로 이메일 인증을 위한 강력한 메커니즘을 제공합니다. 이는 종종 포괄적인 이메일 보안 프레임워크를 제공하기 위해 SPF (Sender Policy Framework) 및 DMARC (Domain-based Message Authentication, Reporting, Conformance) 와 같은 다른 이메일 인증 방법과 함께 사용됩니다.

도메인 소유자는 DKIM을 구현하여 이메일 통신의 신뢰성을 높이고 피싱 공격에 사용되는 도메인의 가능성을 줄이며 이메일 전달성을 향상시킬 수 있습니다.

SPF 검증은 어떻게 작동합니까?

1. 송신자가 SPF 레코드 공개: 도메인 소유자 (송신자) 가 도메인의 DNS (Domain Name System) 레코드에 SPF 레코드를 공개합니다. 이 SPF 레코드는 해당 도메인을 대신하여 이메일을 발송할 수 있는 권한이 부여된 메일 서버를 지정합니다.

2. 이메일 발송: 해당 도메인에서 이메일이 발송되면 수신인의 메일 서버가 발신인 도메인에 대한 SPF 레코드를 검색하여 SPF 검사를 수행할 수 있습니다.

3. SPF 레코드 검사: 수신인의 메일 서버는 발송 메일 서버의 IP 주소가 SPF 레코드에 권한이 있는 발신인으로 나열되어 있는지 확인합니다. 올바른 경우 이메일은 합법적인 것으로 간주됩니다. 그렇지 않으면 의심스러운 것으로 표시되거나 거부될 수 있습니다.

4. 결과: SPF 검사는 다음 세 가지 결과 중 하나를 생성합니다.

   • 패스: 발송 서버의 IP 주소가 SPF 레코드에 나열되어 이메일이 합법적임을 표시합니다.
   • 실패: 발송 서버의 IP 주소가 SPF 레코드에 나열되지 않습니다. 이는 이메일에 권한이 없을 수 있음을 나타냅니다.
   • 소프트 실패: SPF 레코드는 주의를 제안하지만 이메일이 즉시 거부되지 않습니다.

DKIM 검증은 어떻게 작동합니까?

1. 메시지 서명: DKIM을 사용할 수 있는 도메인에서 이메일을 보내면 발송 메일 서버가 개인 키를 사용하여 이메일 메시지에 디지털로 서명합니다. 이 서명에는 이메일의 컨텐츠 및 발신인 도메인에 대한 정보가 포함되어 있습니다.

2. DNS 레코드: 송신자의 도메인이 해당 DNS (Domain Name System) 레코드에 DKIM 공개 키를 공개합니다. 이 공개 키는 1단계에서적용된 서명을 확인하기 위해 메일 서버를 수신하는 데 사용됩니다.

3. 이메일 전송: 이메일이 수신인의 메일 서버로 전송됩니다.

4. DKIM 검증: 전자 우편을 수신하면 받는 사람의 메일 서버가 전자 우편의 "보낸 사람" 헤더에 있는 도메인을 사용하여 보내는 사람의 DNS 레코드에서 DKIM 공용 키를 검색하여 DKIM 검증을 수행합니다.

5. 서명 확인: 받는 사람의 메일 서버는 DKIM 공용 키를 사용하여 전자 우편의 디지털 서명을 확인합니다. 서명이 유효한 경우 이는 이메일이 전송 중에 변조되지 않았으며 권한이 부여된 소스에서 시작되었음을 의미합니다.

6. 결과: DKIM 검증 프로세스의 결과는 다음 결과 중 하나입니다.

   • 패스: 이메일의 DKIM 서명이 올바릅니다. 이는 이메일이 합법적이고 변조되지 않았음을 표시합니다.
   • 실패: DKIM 서명이 올바르지 않거나 누락되어 이메일이 의심스럽거나 위조되었을 수 있음을 나타냅니다.

이메일 개인화란 무엇입니까?

이메일 개인화는 환경 설정, 동작, 인구 통계 또는 기타 데이터를 기반으로 개별 수신인 또는 특정 수신인 그룹에 이메일 컨텐츠 및 메시징을 사용자 조정하는 사례를 참조합니다. 이메일 개인화의 목표는 수신인에 대해 더 관련성이 높고 참여하는 이메일 경험을 작성하는 것입니다. 이로 인해 더 높은 공개 요금, 클릭률 및 전환이 발생할 수 있습니다.

두 가지 유형의 템플리트는 무엇입니까?

두 가지 유형의 템플리트 (초대 템플리트 및 알림 템플리트) 를 사용할 수 있습니다. 초대 템플리트는 등록에 추가된 모든 사용자에게 사용자 정의된 이메일 초대를 발송하는 데 사용되는 반면, 알림 템플리트는 이벤트에 대한 이메일을 발송할 때 사용됩니다. 여기에는 HTML 태그, 핸들바 지원 및 개인화 지원이 포함될 수 있습니다.

클라이언트 타임아웃이란 무엇인가요?

클라이언트 제한시간은 클라이언트 (예: 웹 브라우저 또는 애플리케이션) 가 서버의 응답을 기다리는 기간을 의미합니다. 서버가 이 지정된 시간 프레임 내에 응답하지 못하면 제한시간 초과가 발생하여 연결이 끊어졌거나 서버가 응답하지 않음을 표시합니다.

클라이언트 제한시간 초과가 발생하는 이유는 무엇입니까?

클라이언트 제한시간 초과는 느린 네트워크 연결, 서버 과부하, 잘못된 구성 또는 클라이언트 측 애플리케이션 문제와 같은 다양한 이유로 인해 발생할 수 있습니다. 클라이언트가 정의된 제한시간 내에 서버에서 응답을 수신하지 못하면 문제가 있다고 가정하고 연결을 종료합니다.

클라이언트 제한시간 초과가 발생하는지 여부를 판별하는 방법은 무엇입니까?

웹 사이트, 애플리케이션 또는 서비스에 액세스하려고 시도할 때 클라이언트 제한시간 초과가 발생할 수 있습니다. 공통 표시기에는 Connection Timed Out 또는 Request Timed Out 와 같은 오류 메시지가 포함됩니다. 서버 측의 모니터링 도구 및 로그는 제한시간 초과 발생에 대한 통찰을 제공할 수도 있습니다.

클라이언트 제한시간 초과 문제점을 해결하는 방법

• 인터넷 연결 확인: 인터넷 연결이 안정적이고 중단되지 않았는지 확인하십시오.
• 서버 상태 확인: 이벤트 알림 서비스가 사용 가능하고 인시던트가 보고되지 않았는지 확인하십시오.
• 제한시간 설정 조정: 일부 애플리케이션에서는 사용자가 제한시간 설정을 조정할 수 있습니다. 가능하면 잠재적인 지연을 수용하도록 제한시간 지속 기간을 연장하는 것을 고려하십시오.

개발자가 애플리케이션에서 클라이언트 제한시간 초과를 해결할 수 있는 방법은 무엇입니까?

개발자는 더 나은 성능을 위한 코드 최적화, 비동기 프로그래밍 활용 및 재시도 메커니즘 구현을 포함하여 다양한 전략을 구현할 수 있습니다. 또한 사용자에게 명확한 오류 메시지 및 문제점 해결에 대한 안내를 제공하면 전반적인 사용자 경험을 향상시킬 수 있습니다.

클라이언트 제한시간 초과가 항상 서버 문제의 결과입니까?

반드시 그렇지는 않습니다. 서버 관련 문제점이 클라이언트 제한시간 초과의 일반적인 원인이기는 하지만 클라이언트 측의 문제점 (예: 네트워크 문제점 또는 잘못 구성된 설정) 도 제한시간 초과에 영향을 줄 수 있습니다. 제한시간 문제를 해결할 때 클라이언트 및 서버 측면을 모두 조사하는 것이 중요합니다.

클라이언트 제한시간 초과가 자주 발생하는 경우 어떻게 해야 합니까?

클라이언트 제한시간 초과가 지속적으로 발생하는 경우 지원 팀에 연락하는 것을 고려하십시오.