Deduplicazione negli SMS A2P: come evitare messaggi ripetuti senza bloccare notifiche legittime

Quale problema risolve la deduplicazione e cosa non deve fare

La deduplicazione dei messaggi A2P SMS riduce gli invii ripetuti causati da richieste duplicate, tentativi di rete, eventi concorrenti o incertezza dopo una risposta API incompleta. Il suo obiettivo non è impedire ogni ripetizione: deve evitare che una stessa intenzione di business generi più SMS indesiderati, senza bloccare un reinvio legittimo, un nuovo avviso o una comunicazione basata sul consenso con una finalità diversa.

Il principio tecnico è l'idempotenza. Un'operazione idempotente conserva lo stesso effetto previsto anche se viene elaborata una o più volte. Nella messaggistica, questo richiede che l'applicazione possa riconoscere che due richieste rappresentano la stessa intenzione prima di creare due invii indipendenti.

Una disconnessione prima di ricevere la risposta della piattaforma non dimostra che l'invio non sia stato creato. In questo caso, creare un altro messaggio senza riconciliare lo stato può causare un duplicato. La policy deve conservare un identificatore di idempotenza proprio, renderlo persistente e usarlo per interrogare o riconciliare il risultato prima di emettere un secondo invio.

• Non trattare la deduplicazione come un blocco globale per numero di telefono.
• Non presumere che una conferma API, uno stato in coda o un evento di invio confermi la ricezione sul terminale.
• Applicare la decisione all'intenzione di business e allo stato del ciclo di vita, non solo al testo dell'SMS.
• Definire eccezioni esplicite e verificabili per reinvii richiesti, modifiche sostanziali del contenuto o incidenti.

I tre casi da distinguere

Una policy utile inizia classificando il motivo della ripetizione. I tre casi possono sembrare identici nella cronologia di un destinatario, ma richiedono decisioni diverse.

Il duplicato tecnico si verifica quando la stessa intenzione viene elaborata più di una volta: per esempio, due richieste concorrenti con la stessa chiave, un tentativo dopo la perdita della risposta oppure la ripetizione di un evento da una coda. Normalmente deve essere soppresso se esiste un invio attivo o già creato per la stessa intenzione.

Il tentativo controllato è un'azione deliberata all'interno di una policy definita. Può essere necessario quando lo stato precedente indica errore, mancata consegna o risultato incerto, ma deve usare la stessa correlazione di business, limiti di frequenza e regole di idoneità. Non deve essere confuso con la riesecuzione cieca di una richiesta.

Un messaggio legittimamente ripetuto corrisponde a una nuova finalità, evento, challenge o autorizzazione. Una conferma d'ordine e un avviso successivo relativo a una modifica dell'ordine possono essere diretti allo stesso numero e avere un testo simile, ma non sono lo stesso evento di business.

• Duplicato tecnico: stessa intenzione, stessa chiave, ripetizione indesiderata.
• Tentativo controllato: stessa intenzione, nuova azione consentita da una regola di stato e tempo.
• Ripetizione legittima: nuova intenzione o modifica sostanziale verificabile.

Progettare una chiave di deduplicazione basata sull'intenzione

La chiave deve rappresentare una specifica unità di intenzione di business. Il numero di destinazione è necessario, ma non sufficiente. Deve essere memorizzato e confrontato in una rappresentazione internazionale normalizzata conforme al piano E.164, evitando che differenze di formato locale, spazi, trattini o prefissi producano chiavi diverse per la stessa destinazione.

Come base, una chiave può combinare destinazione normalizzata, finalità, identificatore dell'evento di business, mittente o profilo di invio e un identificatore di correlazione. Il modello o la relativa versione può essere aggiunto quando aiuta a distinguere comunicazioni sostanzialmente diverse. Nei sistemi distribuiti, è opportuno memorizzare anche una chiave di idempotenza generata dall'applicazione e stabile durante i tentativi della stessa operazione.

Non usare il testo dell'SMS come unica chiave. I messaggi dinamici cambiano in base a importi, date, nomi o riferimenti. Nell'autenticazione, il testo può contenere segreti diversi per la stessa transazione o messaggi simili per challenge differenti. Due OTP dall'aspetto simile non devono essere considerati equivalenti senza conoscere la challenge, il tentativo o l'evento di autenticazione a cui appartengono.

• Destinazione normalizzata in formato internazionale.
• Finalità: autenticazione, avviso, conferma, campagna o altro dominio definito.
• Identificatore dell'evento: ordine, incidente, sessione, challenge o transazione.
• Mittente o profilo di invio, quando fa parte dell'intenzione.
• Versione del modello o classificazione del contenuto, se rilevante.
• Identificatore di correlazione e idempotenza persistente.

Applicare finestre temporali per caso d'uso, non una finestra universale

La finestra di deduplicazione è il periodo durante il quale due richieste con la stessa intenzione sono considerate candidate alla soppressione o alla riconciliazione. Non esiste una durata universalmente corretta: deve essere definita in base alla finalità, al rischio, all'esperienza utente e al ciclo di vita previsto del messaggio.

Per gli OTP e altri segreti di autenticazione, la policy deve essere legata alla transazione di autenticazione e al segreto specifico. Un segreto deve essere accettato una sola volta durante la sua validità. NIST stabilisce che un'autenticazione fuori banda deve essere considerata non valida se non viene completata entro 10 minuti; questo limite non obbliga la finestra operativa di soppressione a essere di 10 minuti, ma impedisce di trattare l'autenticazione come un processo aperto indefinitamente.

Per avvisi transazionali, conferme e comunicazioni basate sul consenso, la finestra deve riflettere l'evento. Una conferma ripetuta dello stesso ordine può essere soppressa mentre lo stesso evento e la stessa versione sono in attesa o già elaborati. Tuttavia, un aggiornamento sostanziale dell'ordine, un nuovo incidente o una richiesta verificabile di reinvio devono essere valutati come una nuova condizione, non come un duplicato automatico.

• OTP: collegare la decisione alla challenge e al segreto, non solo al destinatario o al testo.
• Avvisi: utilizzare l'identificatore dell'incidente, dello stato o dell'evento che ha originato la notifica.
• Conferme: distinguere la prima conferma da una modifica successiva dello stesso processo.
• Campagne basate sul consenso: separare eventi e regole di frequenza dalla deduplicazione tecnica.

Usare stati decisionali e una macchina a stati

Una deduplicazione sicura non si limita a restituire sì o no. È opportuno usare stati decisionali espliciti: consentire, sopprimere, mettere in revisione e sostituire un messaggio in attesa. Ogni stato deve essere supportato da una macchina a stati che distingua, come minimo, richieste nuove, messaggi in attesa di invio, inviati, consegnati, non consegnati, non riusciti e con risultato sconosciuto.

Consentire significa che non esiste una corrispondenza equivalente nell'ambito della policy applicabile oppure che un'eccezione autorizzata trasforma la richiesta in una nuova intenzione. Sopprimere significa che esiste già un'operazione equivalente il cui effetto deve essere preservato. La revisione è riservata a conflitti di dati, eccezioni ad alto rischio o risultati ambigui che non devono essere risolti mediante una regola automatica.

Sostituire un messaggio in attesa può essere usato solo quando la policy consente di sostituire un messaggio che non ha ancora lasciato lo stato di attesa e la piattaforma o l'architettura controlla in modo affidabile tale transizione. Non si deve presumere che un messaggio già inviato, neppure uno contrassegnato come inviato da un fornitore, possa essere ritirato o sostituito.

• Consentire: nuova intenzione o eccezione valida.
• Sopprimere: stessa intenzione nella finestra e con stato che impedisce un altro invio.
• Rivedere: conflitto di correlazione, dati incompleti o eccezione di rischio.
• Sostituire in attesa: solo prima dell'invio effettivo e con controllo dello stato.

Gestire concorrenza, incertezza e callback asincroni

Due richieste identiche possono arrivare contemporaneamente da processi diversi. La protezione deve intervenire prima della creazione di due messaggi: usare una prenotazione atomica o un vincolo di unicità sulla chiave di deduplicazione e sulla finestra applicabile. L'operazione deve restituire la decisione e il riferimento al record esistente, quando pertinente.

Quando una risposta API viene persa o si verifica una disconnessione, mantenere il risultato come incerto. Prima di inviare nuovamente, interrogare o riconciliare tramite la chiave di idempotenza, l'identificatore di correlazione o l'identificatore esterno disponibile. Se il risultato non può essere determinato, applicare una regola di rischio documentata invece di presumere che il primo tentativo sia fallito.

I callback di stato sono eventi asincroni del ciclo di vita. Possono arrivare in ritardo o in un ordine diverso da quello previsto. Devono essere convalidati secondo il meccanismo offerto dalla piattaforma ed elaborati in modo tollerante rispetto a cambiamenti di parametri e sequenze. Uno stato in coda indica accettazione per l'elaborazione; anche uno stato inviato non costituisce una conferma uniforme della consegna al terminale. Persino un DLR di consegna deve essere interpretato secondo la semantica contrattuale e tecnica del percorso, senza presentarlo come prova indipendente di lettura da parte dell'utente.

• Prenotare la chiave prima di creare l'invio per evitare condizioni di gara.
• Conservare lo stato sconosciuto quando la risposta è incerta.
• Rendere idempotente l'elaborazione dei callback.
• Non degradare gli stati terminali con eventi in ritardo o riordinati senza una regola esplicita.
• Distinguere accettazione API, elaborazione, invio e consegna segnalata.

Registrare ogni soppressione per poterla spiegare e verificare

Una soppressione che non può essere spiegata diventa un rischio operativo. Il registro deve consentire di ricostruire quale richiesta è stata ricevuta, rispetto a quale messaggio o intenzione è stata confrontata, quale regola ha preso la decisione e quando scadrà la finestra che impedisce una nuova creazione.

Conservare la chiave di idempotenza e di deduplicazione, gli identificatori di correlazione interni ed esterni, la finalità, la destinazione normalizzata, lo stato precedente e quello nuovo, la regola applicata, la marca temporale, la scadenza della finestra e il riferimento al messaggio esistente. Quando interviene un'eccezione o una revisione manuale, registrare il responsabile, la motivazione e l'esito.

I dati di audit devono seguire policy adeguate di accesso, minimizzazione e conservazione. Evitare di registrare segreti di autenticazione in chiaro. Per gli OTP, è particolarmente importante che la tracciabilità permetta di collegare l'evento senza esporre il segreto fuori banda.

• Motivo per consentire, sopprimere, rivedere o sostituire.
• Chiave e correlazione della richiesta e del messaggio esistente.
• Stato del ciclo di vita noto e fonte dello stato.
• Regola, versione della policy e scadenza applicate.
• Responsabile e motivazione per le eccezioni manuali.
• Dati minimi necessari per diagnosi e audit.

Definire eccezioni senza trasformarle in una via di aggiramento

Le eccezioni devono essere predefinite, verificabili e tracciabili. Una modifica sostanziale del contenuto, un nuovo evento di business, un cambio di canale autorizzato, un incidente operativo o una richiesta verificabile di reinvio possono giustificare il fatto che una richiesta non venga trattata come duplicato.

Nell'autenticazione, generare un nuovo segreto e reinviare un segreto esistente sono decisioni diverse. Il segreto accettato deve poter essere utilizzato una sola volta finché è valido. Inoltre, la generazione di un nuovo segreto non deve azzerare il controllo dei tentativi non riusciti quando applicabile. La deduplicazione non deve indebolire i controlli di sicurezza né sostituire la limitazione dei tentativi.

Non usare eccezioni per superare limiti di frequenza, nascondere errori di integrazione o ripetere messaggi commerciali senza una base di consenso e una policy applicabile. La deduplicazione tecnica deve coesistere con le regole di consenso, esclusione, frequenza e contenuto, ma non sostituirle.

• Modifica sostanziale verificabile di contenuto o stato.
• Nuova finalità o nuovo evento di business.
• Cambio di canale autorizzato e tracciabile.
• Reinvio richiesto e verificabile dall'utente.
• Incidente con procedura di approvazione e registrazione.
• Non azzerare mai i controlli sui tentativi solo creando un nuovo OTP.