Perché i messaggi vengono riportati come consegnati ma non ricevuti dall'utente?

A volte i messaggi vengono riportati come recapitati ma non vengono ricevuti dall'utente per i motivi riportati di seguito:

• Essi sono respinti dall'operatore di telecomunicazioni. Se lo stesso messaggio viene ripetuto in un periodo di tempo, i messaggi vengono classificati come messaggio SPAM dall'operatore.

Una risoluzione consiste nell'aggiungere qualsiasi TransactionID o ReferenceID al corpo del messaggio. Questi ID classificano SMS come transazionale e non sono bloccati dall'operatore.

• L'utente decide di non eseguire l'opzione. Se l'utente rinuncia alla messaggistica inviando un testo di esclusione come Opt Out, Stop o Exit, i messaggi non raggiungono tale utente e il report di stato lo indica. L'utente può inviare un messaggio Opt in alla stessa origine per riavviare la ricezione dei messaggi.

Perché alcuni dispositivi sono contrassegnati come non validi ed eliminati dal database?

A volte, i dispositivi vengono contrassegnati come non validi ed eliminati dal database, se soddisfano queste condizioni non valide:

• Dispositivi FCM o Android:

  • invalidRegistration- potrebbe essere dovuto a un formato del token di registrazione non corretto passato al server.
  • MismatchSenderID- una mancata corrispondenza nel senderID che non fa parte del gruppo utenti collegato a un token di registrazione.
  • NotRegistered- un token di registrazione non valido per vari motivi (come l'annullamento della registrazione dell'applicazione client con FCM, i token non sono validi, il token di registrazione scade, l'applicazione client che viene aggiornata ma la nuova versione che non è configurata per ricevere messaggi).

  Per ulteriori informazioni, consultare Codici di risposta di errore FCM per i messaggi downstream.

• Dispositivi APNS o Safari:

  • Unregistered- il token del dispositivo non è attivo per l'argomento specificato.
  • BadDeviceToken- il token dispositivo specificato non è valido.
  • DeviceTokenNotForTopic- il token del dispositivo non corrisponde all'argomento specificato (ID bundle).

  Per ulteriori informazioni su come gestire le risposte di notifica dalle applicazioni, vedi qui.

• Dispositivi Chrome o Firefox:

  • NotFound- la sottoscrizione è scaduta e non può essere utilizzata.
  • Gone- la sottoscrizione non è più valida.

  Per ulteriori informazioni, vedi protocollo push web.

Qual è la differenza tra sottoscrizioni di argomenti e sottoscrizioni di tag ai dispositivi push?

• Sottoscrizioni argomento Event Notifications:

  Per le sottoscrizioni argomento, iniziare creando un Argomento e condizioni di scrittura su tale argomento. Questo argomento è responsabile dell'instradamento della notifica in entrata che soddisfa le condizioni dell'argomento.

  Puoi sottoscrivere più destinazioni Event Notifications come email, SMS, webhooks, slack e team Microsoft. Inoltre, puoi iscriverti a destinazioni di tipo push come Android, iOS, Firefox, cromo e safari.

  Se le notifiche in entrata soddisfano la condizione scritta per l'argomento (T), instrada la notifica a tutte le destinazioni sottoscritte o connesse all'argomento (T) indipendentemente dal tipo di destinazione.

  Ad esempio, ACME Bank desidera instradare notifiche di evento di manutenzione per i clienti utilizzando dispositivi Android e iOS. Acme Bank sta seguendo questi passi:

  1. Creare un argomento denominato ACME-Maintenance.
  2. Condizione di avanzamento scrittura $.notification-type == 'maintenance'.
  3. Sottoscrivi android push e destinazioni iOS al tuo argomento.
  4. Successivamente, invia una notifica evento con un payload contenente l'attributo "notification-type":"maintenance"e "ibmenpushto": "{\"platforms\":[\"push_android\",\"push_ios\"]]}", viene aggiunto l'attributo notification-type in modo che corrisponda alla condizione dell'argomento e ibmenpushto per il targeting dei clienti con dispositivi Android e iOS .
  5. Event Notifications verrà instradato ai clienti con android e dispositivi iOS , poiché il suo payload contiene "notification-type":"maintenance" che corrisponde alla condizione per l'argomento ACME-Maintenance e "ibmenpushto": "{\"platforms\":[\"push_android\",\"push_ios\"]]}" poiché ibmenpushto è obbligatorio per destinazioni di tipo push Event Notifications .

  Tutti i dispositivi push verranno registrati sotto la destinazione Event Notifications di tipo push. Ad esempio, push-android, push-ios e altri.

• Event Notifications sottoscrizioni di tag ai dispositivi di push:

  Ad esempio, ACME Bank desidera instradare notifiche di evento di manutenzione per i clienti utilizzando dispositivi Android e iOS. La manutenzione della banca ACME di solito avviene in una regione alla volta.

  ACME Bank desidera registrare ciascuno dei dispositivi Android e iOS del proprio cliente con tag specifiche della regione.

  1. Per ottenere ciò, la banca può utilizzare l'SDK client Android Event Notifications e l'SDK client iOS per sottoscrivere i dispositivi android e iOS dei clienti Asia Pacific nella tag AP.

     Utilizza i seguenti link per ulteriori informazioni su come sottoscrivere i dispositivi push utilizzando gli SDK client Event Notifications:

     • Notifiche push Android (FCM)
     • Notifiche push iOS (APNs)
     • Notifiche push Chrome
     • Notifiche push Firefox
     • Notifiche Push di Safari

  2. Successivamente, la banca invia una notifica con un payload contenente attributi "notification-type":"maintenance" e "ibmenpushto": "{\"tags\":[\"AP\""]]}", notification-type vengono aggiunti in modo che corrispondano alla condizione dell'argomento e ibmenpushto poiché il messaggio è per i clienti push di destinazione con dispositivi android e iOS nella regione Asia Pacifico AP.

Perché non vedo le notifiche email o SMS che ho inviato dopo aver configurato Event Notifications per email e SMS?

Email e SMS sono supportati soltanto per i servizi IBM Managed Sources (IBM Cloud ). È possibile inviare una notifica dall'API source a tutte le altre destinazioni, ad eccezione di Email e SMS.

Dove posso specificare il nome del canale Slack nella configurazione di destinazione Slack?

Event Notifications supporta la destinazione Slack utilizzando la funzione "Webhook in entrata" di Slack. Un webhook in ingresso è collegato direttamente a un canale Slack. Pertanto, non è necessario specificare separatamente il canale Slack.

È possibile personalizzare il messaggio generato dai servizi IBM Cloud (originiIBM Cloud )?

Non puoi personalizzare i messaggi generati dai servizi IBM Cloud (IBM Cloud origini). Queste notifiche sono generate dal rispettivo servizio IBM Cloud come Secrets Managere Compliance Manager. Il contenuto del messaggio non può essere modificato dall'utente finale prima che venga inviato a una destinazione.

Perché ricevo una risposta di errore 422 per la chiamata dell'API di invio notifiche?

Il servizio Event Notifications non è in grado di elaborare la richiesta. Ciò si verifica di solito quando non vi sono condizioni o filtri associati all'argomento a cui viene inviata la notifica. Controllare l'argomento e verificare che sia connesso all'origine corretta, con le condizioni desiderate.

Perché le mie notifiche email inviate non hanno raggiunto i clienti anche se nei log posso vedere le notifiche inviate correttamente?

Ciò potrebbe essere dovuto al fatto che la tua istanza Event Notifications ha una sottoscrizione creata per la destinazione smtp_ibm e non ha alcun ID email aggiunto come destinatario all'elenco per la sottoscrizione.

Assicurarsi che la propria istanza Event Notifications abbia una sottoscrizione creata per la destinazione smtp_ibm e abbia almeno un ID email aggiunto come destinatario all'elenco per la sottoscrizione.

È possibile inviare notifiche a più di una destinazione utilizzando Event Notifications?

Sì. È possibile inviare notifiche a più di una destinazione.

Qual è la differenza tra una destinazione email del dominio personalizzata e una destinazione email IBM Cloud per notifiche di evento?

Le email inviate tramite una destinazione email IBM Cloud vengono inviate per conto di IBM Cloud da una fonte (ad esempio, il dominio e-mail del mittente avrà sempre ".event-notifications.cloud.ibm.com"). D'altra parte, una destinazione di posta elettronica personalizzata consente di aggiungere il tuo proprio indirizzo di dominio attraverso il quale un mittente può inviare email.

Inoltre, le origini API non possono inviare notifiche alla destinazione email IBM Cloud, a causa dei motivi di sicurezza, d'altra parte, una destinazione email di dominio personalizzata può ricevere notifiche da qualsiasi origine.

Quali estensioni di file sono bloccate per gli allegati di posta elettronica?

Per motivi di sicurezza, alcune estensioni di file sono bloccate quando si inviano allegati di posta elettronica attraverso destinazioni di posta elettronica di dominio personalizzate. Queste estensioni vengono bloccate per impedire la trasmissione di file eseguibili, script e file di sistema potenzialmente dannosi che potrebbero rappresentare un rischio per la sicurezza dei destinatari.

La tabella seguente elenca le estensioni di file bloccate:

Se si tenta di inviare un allegato con un'estensione bloccata, la richiesta verrà rifiutata con un errore 400 Bad Request.

Che cosa è la verifica SPF?

La verifica SPF (Sender Policy Framework) è un metodo di autenticazione email progettato per impedire lo spoofing e il phishing di email consentendo ai destinatari di email di verificare che un messaggio email abbia origine da un'origine autorizzata. SPF funziona definendo un elenco di server di posta autorizzati (indirizzi IP) per un particolare dominio. Quando si riceve un'email, il server di posta del destinatario può controllare se l'indirizzo IP del server di posta mittente è nell'elenco dei server autorizzati per il dominio del mittente.

SPF consente di impedire alle fonti non autorizzate di inviare email per conto di un dominio, riducendo la probabilità di attacchi di phishing e spam. Tuttavia, è importante notare che SPF da solo non fornisce la sicurezza delle email end to end. Altri meccanismi di autenticazione email, come DKIM (DomainKeys Identified Mail) e DMARC (Domain - based Message Authentication, Reporting, and Conformance), sono spesso utilizzati in combinazione con SPF per un'autenticazione email più completa e una strategia anti - phishing.

Cos' è la verifica DKIM?

La verifica DKIM (DomainKeys Identified Mail) è un metodo di autenticazione email utilizzato per verificare l'autenticità e l'integrità dei messaggi email. DKIM aiuta a prevenire lo spoofing, il phishing e la manomissione delle email consentendo ai destinatari delle email di controllare se un messaggio email è stato inviato da un'origine autorizzata e se è stato modificato durante il transito.

La verifica DKIM fornisce un forte meccanismo per l'autenticazione email perché verifica crittograficamente l'identità del mittente e garantisce l'integrità dell'email. È spesso utilizzato in combinazione con altri metodi di autenticazione email come SPF (Sender Policy Framework) e DMARC (Domain - based Message Authentication, Reporting, and Conformance) per fornire un framework di sicurezza email completo.

Implementando DKIM, i proprietari dei domini possono aumentare l'attendibilità delle loro comunicazioni email, ridurre la probabilità che il loro dominio venga utilizzato per attacchi di phishing e migliorare la capacità di recapito delle email.

Come funziona la verifica SPF?

1. Il mittente pubblica un record SPF: il proprietario di un dominio (il mittente) pubblica un record SPF nei record DNS (Domain Name System) del dominio. Questo record SPF specifica quali server di posta sono autorizzati a inviare email per conto di tale dominio.

2. Email inviata: quando un'email viene inviata da quel dominio, il server di posta del destinatario può eseguire un controllo SPF ricercando il record SPF per il dominio del mittente.

3. SPF Record Check: il server di posta del destinatario controlla se l'indirizzo IP del server di posta mittente è elencato nel record SPF come mittente autorizzato. Se lo è, l'email è considerata legittima; in caso contrario, può essere contrassegnata come sospetta o rifiutata.

4. Risultato: il controllo SPF produce uno dei tre risultati:

   • Passaggio: l'indirizzo IP del server mittente è elencato nel record SPF, indicando che l'email è legittima.
   • Errore: l'indirizzo IP del server di invio non è elencato nel record SPF, suggerendo che l'email potrebbe non essere autorizzata.
   • Errore lieve: il record SPF suggerisce cautela, ma l'email non viene immediatamente rifiutata.

Come funziona la verifica DKIM?

1. Firma messaggio: quando un'email viene inviata da un dominio con DKIM abilitato, il server di posta mittente firma digitalmente il messaggio email utilizzando una chiave privata. Questa firma include le informazioni sul contenuto dell'email e sul dominio del mittente.

2. Record DNS: il dominio del mittente pubblica una chiave pubblica DKIM nei suoi record DNS (Domain Name System). Questa chiave pubblica viene utilizzata dalla ricezione dei server di posta per verificare la firma applicata nel passo 1.

3. Trasmissione email: l'e-mail viene trasmessa al server di posta del destinatario.

4. Verifica DKIM: dopo aver ricevuto l'email, il server di posta del destinatario esegue la verifica DKIM recuperando la chiave pubblica DKIM dai record DNS del mittente utilizzando il dominio trovato nell'intestazione "Da" dell'email.

5. Verifica firma: il server di posta del destinatario utilizza la chiave pubblica DKIM per verificare la firma digitale sull'email. Se la firma è valida, significa che l'email non è stata manomessa durante il transito e che è stata originata da un'origine autorizzata.

6. Risultato: il processo di verifica DKIM risulta in uno dei seguenti risultati:

   • Passaggio: la firma DKIM dell'email è valida, a indicare che l'email è legittima e non è stata manomessa.
   • Errore: la firma DKIM non è valida o manca, suggerendo che l'email potrebbe essere sospetta o contraffatta.

Cos'è la personalizzazione dell'e-mail?

La personalizzazione delle email si riferisce alla pratica di personalizzare il contenuto e la messaggistica delle email per singoli destinatari o gruppi specifici di destinatari in base alle preferenze, ai comportamenti, ai dati demografici o ad altri dati. L'obiettivo della personalizzazione delle email è creare esperienze email più pertinenti e coinvolgenti per i destinatari, che possono portare a tassi di apertura più elevati, tassi di click-through e conversioni.

Quali sono due tipi di modelli?

Esistono due tipi di modelli: modelli di invito e modelli di notifica. Un modello di invito viene utilizzato per inviare inviti email personalizzati a tutti quelli aggiunti alle sottoscrizioni, mentre un modello di notifica viene utilizzato quando si invia un'email per un evento. Può includere tag HTML, supporto di manubrio e supporto di personalizzazione.

Che cos'è il timeout del client?

Un timeout client fa riferimento al periodo durante il quale un client (ad esempio un browser Web o un'applicazione) attende una risposta da un server. Se il server non riesce a rispondere entro questo intervallo di tempo specificato, si verifica un timeout, che indica che la connessione è stata persa o che il server non risponde.

Perché si verificano i timeout del client?

I timeout del client possono verificarsi a causa di vari motivi, ad esempio una connettività di rete lenta, un sovraccarico del server, configurazioni errate o problemi con l'applicazione lato client. Quando un client non riceve una risposta dal server entro il periodo di timeout definito, presume che ci sia un problema e termina la connessione.

Come è possibile determinare se si verifica un timeout del client?

È possibile che si verifichino dei timeout del client quando si tenta di accedere a un sito Web, un'applicazione o un servizio. Gli indicatori comuni includono messaggi di errore come Connection Timed Out o Request Timed Out. Anche gli strumenti di monitoraggio e i log sul lato server possono fornire informazioni dettagliate sulle ricorrenze di timeout.

Come è possibile risolvere i problemi dei timeout del client?

• Controlla la tua connessione Internet: assicurati che la tua connessione Internet sia stabile e non subisca interruzioni.
• Verificare lo stato del server: confermare che il servizio di notifica eventi sia disponibile e che non sia stato segnalato alcun incidente.
• Regolare le impostazioni di timeout: alcune applicazioni consentono agli utenti di modificare le impostazioni di timeout. Se possibile, considerare l'estensione della durata del timeout per far fronte a potenziali ritardi.

In che modo gli sviluppatori possono risolvere i timeout del client nelle loro applicazioni?

Gli sviluppatori possono implementare varie strategie, tra cui l'ottimizzazione del codice per migliorare le prestazioni, l'utilizzo della programmazione asincrona e l'implementazione dei meccanismi di nuovi tentativi. Inoltre, fornire agli utenti messaggi di errore chiari e indicazioni per la risoluzione dei problemi può migliorare l'esperienza utente complessiva.

I timeout del client sono sempre dovuti a problemi del server?

Non necessariamente. Anche se i problemi relativi al server sono cause comuni dei timeout del client, i problemi sul lato client, come i problemi di rete o le impostazioni non configurate correttamente, possono contribuire ai timeout. È essenziale analizzare sia gli aspetti client che server quando si risolvono i problemi di timeout.

Cosa devo fare se si verificano frequentemente i timeout del cliente?

Se si riscontrano costantemente dei timeout del client, prendere in considerazione la possibilità di raggiungere il team di supporto.

Posso usare Terraform IBM Modules per fare il provisioning di Event Notifications?

Sì, è possibile utilizzare moduli Terraform IBM(TIM) precostituiti e pronti per l'impresa per il provisioning e la configurazione delle istanze Event Notifications. Il modulo Event Notifications fornisce un approccio standardizzato e testato alla distribuzione di Event Notifications, con le migliori pratiche integrate.

Event Notifications supporta l'integrazione di più account?

Event Notifications supporta l'integrazione tra conti. I passi seguenti indicano la procedura per eseguire l'integrazione tra conti:

1. Creare un'istanza di Event Notifications nel primo account A.

2. Creare un'istanza Secrets Manager in un altro account B.

3. Eseguire l'autorizzazione da servizio a servizio sul conto A e fornire il numero di conto di B quando viene richiesto di selezionare un conto sorgente.

4. Creare una chiave API e generare un token di accesso.

curl --request POST \
  --url https://iam.cloud.ibm.com/identity/token \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data apikey=<api-key> \
  --data response_type=cloud_iam \
  --data grant_type=urn:ibm:params:oauth:grant-type:apikey

Per creare l'integrazione tramite API:

Eseguire un comando curl per integrare l'istanza Event Notifications con l'istanza Secrets Manager.

curl -X POST \
  -H "Authorization: Bearer <iam_token>" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{
    "event_notifications_instance_crn": "<crn of the event notifications instance>",
    "event_notifications_source_description": "Optional description of this source in an Event Notifications instance.",
    "event_notifications_source_name": "My Secrets Manager"
  }' \
  "https://<secrets-manager instance id>.<region>.secrets-manager.appdomain.cloud/api/v2/notifications/registration"

Per creare l'integrazione tramite CLI:

ibmcloud secrets-manager notifications-registration-create --instance-id 0a497fc8-4389-4fee-86ec-ab4b364524de \
  --event-notifications-instance-crn <crn of the event notifications instance> \
  --event-notifications-source-name 'My Secrets Manager' \
  --event-notifications-source-description 'Optional description of this source in an Event Notifications instance.'

Per creare l'integrazione con Terraform:

resource "ibm_sm_en_registration" "sm_en_registration" {
  instance_id   = <secrets-manager instance id>
  region        = <region>
  event_notifications_instance_crn = <crn of the event notifications instance>
  event_notifications_source_description = "Optional description of this source in an Event Notifications instance."
  event_notifications_source_name = "My Secrets Manager"
}