Validità dei messaggi SMS A2P: come definire scadenza, tentativi e stati finali senza penalizzare l’utente

La validità di un SMS non coincide con la scadenza del suo contenuto

Negli SMS, il periodo di validità descrive per quanto tempo un messaggio deve essere conservato per tentare la consegna prima della scadenza. È un attributo di trasporto e conservazione nella rete; non determina di per sé se il contenuto sia ancora appropriato per il destinatario.

Questa distinzione è essenziale nel traffico A2P. Un SMS può continuare a essere tecnicamente consegnabile anche se il codice OTP non è più accettabile, l’avviso è già stato risolto o una promozione ha perso la sua opportunità. Mantenere il messaggio in coda in questi casi può generare confusione, richieste di assistenza e decisioni di sicurezza errate.

La politica operativa non deve limitarsi a chiedere se il fornitore o la rete possano ancora consegnare l’SMS. Deve rispondere a una domanda precedente: “L’azione richiesta è ancora corretta, sicura e utile se il destinatario riceve questo messaggio ora?”.

• Validità tecnica: tempo massimo di conservazione e tentativi di consegna nella piattaforma, presso il fornitore o nella rete.
• Scadenza del contenuto: momento dal quale un codice, link o dato incluso non è più valido.
• Finestra di utilità: periodo durante il quale ricevere la comunicazione consente ancora al destinatario di compiere un’azione pertinente.

Usa un limite assoluto di utilità come decisione di controllo

La piattaforma mittente deve calcolare una scadenza assoluta di utilità quando viene creata l’operazione. Tale momento deve accompagnare il messaggio durante l’accodamento, la regolazione tramite TPS, la selezione della connettività, l’invio e i tentativi.

Prima di ogni transizione rilevante, verifica se resta tempo sufficiente perché il messaggio mantenga senso. Se l’attesa interna, il limite di invio o un nuovo tentativo hanno già consumato tale finestra, la decisione corretta è di solito non inviare. Non è opportuno delegare questa decisione esclusivamente al periodo di validità configurabile di una terza parte, poiché tale valore può applicarsi solo al tempo di permanenza nella sua piattaforma.

Il controllo deve essere eseguito prima di accettare il lavoro in una coda di uscita, prima di inviarlo a un fornitore e prima di pianificare ciascun tentativo. In questo modo si evita che un messaggio obsoleto venga inviato soltanto perché esiste ancora capacità tecnica per trasportarlo.

• Definisci un orario di scadenza dell’utilità per ogni operazione.
• Riserva un budget temporale per coda interna, regolazione TPS, accettazione del fornitore e tentativi.
• Sopprimi prima dell’invio se il budget rimanente non consente più una consegna utile.
• Mantieni la scadenza della piattaforma come protezione aggiuntiva, non come unico controllo aziendale.

Definisci politiche diverse per OTP, messaggi transazionali e campagne basate sul consenso

Non esiste un unico periodo adatto a tutte le classi di traffico. La politica deve derivare dall’azione attesa, dalle conseguenze di un messaggio tardivo e dalla possibilità di sostituirlo con informazioni aggiornate. Il periodo deve essere documentato come regola di prodotto e operativa, non come supposizione sulla latenza di una rotta.

Per gli OTP, il riferimento principale è la validità del segreto e il contesto di autenticazione. Per le comunicazioni transazionali, conta se l’evento è ancora aperto o se esiste uno stato più recente. Per le campagne basate sul consenso, sono particolarmente importanti l’opportunità commerciale e l’evitare una ripetizione tardiva che il destinatario non si aspetta.

I periodi specifici devono essere approvati dai team responsabili del flusso, della sicurezza, della privacy o della protezione dei dati, della conformità e dai requisiti normativi o contrattuali locali applicabili. La piattaforma deve implementare tali periodi in modo verificabile e consentire di identificare quale regola sia stata applicata a ogni operazione.

• OTP e recupero: finestra breve e allineata all’accettazione del segreto; sopprimi se scade prima dell’invio.
• Avvisi transazionali: invia finché l’evento resta valido; sostituisci con un aggiornamento se lo stato cambia.
• Conferme: non reinviare un messaggio precedente se una conferma successiva rappresenta meglio lo stato attuale.
• Campagne basate sul consenso: non ritentare automaticamente quando la data, la fascia oraria o l’opportunità dell’offerta sono già trascorse.

OTP: coordina trasporto e segreto, ma non confonderli

Un OTP inviato via SMS deve essere monouso entro il proprio periodo di validità. Il verificatore deve rifiutarlo alla scadenza, anche se l’SMS viene consegnato dopo. Il fatto che il messaggio raggiunga il dispositivo non estende la validità del codice né riattiva l’operazione di autenticazione.

NIST stabilisce, per l’autenticazione fuori banda descritta nella propria guida, che deve essere completata entro una finestra di dieci minuti e che un segreto specifico deve essere accettato una sola volta durante il suo periodo di validità. Questo riferimento non elimina la necessità di una politica specifica per la coda: il mittente deve impedire che un codice che non può più essere utile continui ad avanzare verso la consegna.

Devono inoltre essere limitati i tentativi non riusciti quando il segreto ha meno di 64 bit. L’emissione di un nuovo segreto non deve azzerare tale contatore. Questa regola appartiene al verificatore e non può essere dedotta dallo stato di trasporto dell’SMS.

L’SMS può essere usato come canale fuori banda, ma è opportuno offrire alternative alle persone che non possono usare la PSTN. I team di rischio devono inoltre considerare segnali rilevanti per il caso d’uso, come cambi di SIM, portabilità o cambio di dispositivo.

• Assegna all’OTP una scadenza verificabile nel verificatore.
• Imposta una scadenza dell’utilità di invio che non consenta di spedire codici già scaduti o prossimi alla scadenza.
• Non trattare un DLR come prova che il codice sia stato visto, inserito o accettato.
• Emetti una nuova operazione solo dopo una nuova richiesta o all’interno di un flusso controllato.
• Non azzerare i controlli sui tentativi non riusciti semplicemente generando un nuovo codice.

Coordina code, TPS e tentativi con il tempo rimanente

Una coda può trasformare un messaggio valido al momento della creazione in un messaggio inutile prima dell’invio. Ciò accade quando il lavoro si accumula, vengono applicati limiti TPS, si attende una risposta upstream o viene programmato un tentativo senza verificare la scadenza dell’utilità.

La pianificazione deve basarsi sul tempo rimanente, non solo sull’anzianità o sulla priorità. Un messaggio con una finestra breve richiede una decisione tempestiva: inviarlo se può essere consegnato nel rispetto della politica, dargli priorità quando è legittimo e sicuro, oppure chiuderlo prima di consumare ulteriori risorse. Non è corretto conservarlo indefinitamente solo perché non ha ancora ricevuto una risposta finale.

La specifica SMS contempla tentativi dopo condizioni temporanee e anche una modalità a singolo tentativo. La scelta non deve essere automatica per tutti i casi. Ritentare può essere ragionevole quando l’informazione resta valida e c’è tempo sufficiente; può essere dannoso quando il contenuto dipende da uno stato che cambia rapidamente.

• Calcola il tempo rimanente prima dell’accodamento e prima di ogni tentativo.
• Evita di pianificare un tentativo la cui esecuzione prevista cada dopo la scadenza dell’utilità.
• Applica tentativi solo in presenza di condizioni transitorie e con una politica esplicita per caso d’uso.
• Valuta un singolo tentativo quando il rischio di consegna tardiva supera il beneficio di insistere.
• Interrompi i tentativi quando ricevi una cancellazione dell’operazione, un aggiornamento che sostituisce il messaggio o una scadenza dell’utilità.

Interpreta i DLR come segnali di trasporto, non come prova di utilizzo

Gli stati di consegna sono necessari per l’operatività, ma non devono essere interpretati oltre il loro ambito. I nomi, la fonte della conferma e il significato esatto di ciascuno stato dipendono dall’integrazione, dal fornitore, dall’operatore e dalla rotta. Devono essere interpretati in conformità alla documentazione tecnica e contrattuale applicabile.

Per esempio, alcune integrazioni usano etichette come «queued», «sent», «delivered», «undelivered» o «failed». In tale tassonomia, «queued» può indicare che la richiesta è stata accettata e attende l’invio; «sent» può indicare l’accettazione da parte di un operatore upstream; e «delivered» può riflettere una conferma disponibile nella catena di trasporto. L’ambito e l’affidabilità di questi segnali variano in base all’integrazione, all’operatore e alla rotta.

Un DLR di consegna non dimostra che una persona abbia letto, compreso o utilizzato l’SMS. Negli SMS non esiste un evento di lettura equivalente che consenta di trasformare la consegna in prova di fruizione. Non si deve nemmeno presumere che un DLR consegnato garantisca universalmente che il contenuto fosse visibile sul dispositivo o che abbia prodotto l’azione prevista.

Pertanto, il sistema deve separare lo stato esterno di trasporto dal risultato aziendale. In un OTP, per esempio, gli eventi rilevanti sono almeno la consegna segnalata, il tentativo di convalida e l’accettazione o il rifiuto del segreto. Nessuno di essi deve sostituire gli altri.

• Esempi di stati di integrazione: «queued» può significare richiesta accettata e in attesa di invio nella piattaforma che riporta lo stato.
• «Sent» può indicare l’accettazione da parte di un operatore o fornitore upstream, in base alla semantica documentata dell’integrazione.
• «Delivered» può rappresentare una conferma di consegna disponibile dalla catena di trasporto; non equivale a lettura o utilizzo.
• «Undelivered» o «failed» possono segnalare mancata consegna o impossibilità di invio; conserva il motivo disponibile secondo l’integrazione.
• Risultato aziendale: stato indipendente, come codice accettato, operazione completata, avviso riconosciuto o azione non eseguita.

Quando l’utilità scade, chiudi l’operazione con una causa esplicita

Un messaggio in attesa la cui utilità è scaduta non deve rimanere ambiguamente in coda né essere classificato soltanto con uno stato tecnico esterno. La piattaforma necessita di uno stato interno finale che spieghi la decisione: per esempio, «soppresso per scadenza dell’utilità», insieme all’orario e alla regola che l’hanno determinata.

L’azione successiva dipende dal tipo di traffico. Per OTP o recupero, sopprimi il messaggio in attesa e non prolungare la vita del segreto. Per un avviso che resta rilevante, genera un aggiornamento valido invece di insistere con il testo originale. Per una campagna basata sul consenso, evita di reinviare automaticamente contenuto la cui opportunità è ormai terminata.

Se la piattaforma ha già affidato il messaggio a un fornitore o alla rete, potrebbe non essere in grado di garantire una cancellazione effettiva. Per questo motivo, la soppressione prima dell’invio è il controllo principale. Dopo l’affidamento, registra lo stato noto, conserva l’incertezza ed evita che un DLR successivo modifichi retroattivamente la decisione aziendale.

• Annullare: se l’integrazione e lo stato del lavoro consentono ancora di ritirarlo prima dell’invio.
• Sopprimere: chiudere nella propria coda per utilità scaduta, senza inviarlo al passaggio successivo.
• Riemettere: creare una nuova comunicazione solo se il caso d’uso lo giustifica ancora e con contenuto aggiornato.
• Escalare: indagare accumuli, tentativi insoliti, DLR incoerenti o scadenze ripetute per destinazione, rotta o fornitore.

Registra i dati minimi per verificare ogni decisione

La politica è verificabile solo se ogni messaggio lascia una cronologia sufficiente per ricostruire cosa sia stato deciso e perché. I callback di consegna sono asincroni; pertanto, l’ordine di arrivo di un DLR non deve sostituire le marche temporali di creazione, accettazione, invio e scadenza.

Usa un identificatore di correlazione stabile per collegare l’operazione aziendale a ciascun tentativo di trasporto. Mantieni separati l’identificatore interno, gli identificatori del fornitore quando presenti e gli identificatori di tentativo. Ciò consente di analizzare duplicati, tentativi, soppressioni ed eventi tardivi senza confondere operazioni diverse.

Per l’audit operativo, usa registri con controlli di integrità, tracciabilità delle modifiche, conservazione definita e accesso ristretto. Evita di archiviare più contenuti personali del necessario e applica i requisiti applicabili in materia di privacy, protezione dei dati, conservazione, rettifica e cancellazione. L’importante è poter dimostrare la politica applicata, la sequenza degli stati e il motivo della decisione finale.

• Identificatore di correlazione dell’operazione e tipo di caso d’uso.
• Identificatore interno del messaggio, identificatori del fornitore e di ciascun tentativo quando presenti.
• Ora di creazione, accettazione, ingresso e uscita dalla coda, invio e ricezione di ciascun DLR.
• Scadenza tecnica configurata, scadenza del contenuto e scadenza dell’utilità.
• Stato tecnico riportato, stato interno finale e marca temporale di ogni transizione.
• Decisione di tentativo, annullamento o soppressione, con relativo motivo e regola applicata.
• Risultato aziendale quando pertinente, senza dedurlo da un DLR.