Gültigkeit von A2P-SMS: Ablauf, Wiederholungsversuche und Endstatus ohne Nachteile für Nutzer

Die Gültigkeit einer SMS ist nicht dasselbe wie die inhaltliche Gültigkeit

Bei SMS beschreibt die Gültigkeitsdauer, wie lange eine Nachricht zur Zustellung vorgehalten und Zustellversuche unternommen werden sollen, bevor sie abläuft. Sie ist ein Merkmal von Transport und Aufbewahrung im Netz; sie bestimmt nicht selbst, ob der Inhalt für den Empfänger weiterhin angemessen ist.

Diese Unterscheidung ist bei A2P-Verkehr wesentlich. Eine SMS kann technisch weiter zustellbar sein, obwohl der OTP-Code nicht mehr akzeptiert wird, eine Warnung bereits erledigt wurde oder ein Angebot seine Aktualität verloren hat. Wird die Nachricht in solchen Fällen in der Warteschlange gehalten, kann dies Verwirrung, Supportanfragen und falsche Sicherheitsentscheidungen verursachen.

Die Betriebsrichtlinie sollte sich nicht darauf beschränken zu fragen, ob der Anbieter oder das Netz die SMS noch zustellen kann. Sie muss zunächst eine frühere Frage beantworten: „Ist die angeforderte Aktion noch korrekt, sicher und nützlich, wenn der Empfänger diese Nachricht jetzt erhält?“

• Technische Gültigkeit: maximale Aufbewahrungszeit und Dauer der Zustellversuche auf der Plattform, beim Anbieter oder im Netz.
• Inhaltliche Gültigkeit: Zeitpunkt, ab dem ein enthaltener Code, Link oder Wert nicht mehr gültig ist.
• Nutzungsfenster: Zeitraum, in dem der Empfang der Mitteilung dem Empfänger noch eine relevante Handlung ermöglicht.

Nutzen Sie ein absolutes Nutzbarkeitsende als Steuerungsentscheidung

Die sendende Plattform muss beim Erstellen des Vorgangs einen absoluten Zeitpunkt für das Ende der Nutzbarkeit berechnen. Dieser Zeitpunkt muss die Nachricht durch Warteschlangeneinreihung, TPS-Drosselung, Auswahl der Anbindung, Versand und Wiederholungsversuche begleiten.

Prüfen Sie vor jedem relevanten Übergang, ob noch ausreichend Zeit verbleibt, damit die Nachricht sinnvoll bleibt. Wenn interne Wartezeiten, Versandlimits oder ein neuer Versuch dieses Fenster bereits aufgebraucht haben, ist die richtige Entscheidung meist, nicht zu senden. Diese Entscheidung sollte nicht allein einer konfigurierbaren Gültigkeitsdauer eines Dritten überlassen werden, da dieser Wert möglicherweise nur für die Verweildauer auf dessen eigener Plattform gilt.

Die Kontrolle muss vor der Annahme der Arbeit in einer Ausgangswarteschlange, vor der Übergabe an einen Anbieter und vor der Planung jedes Wiederholungsversuchs erfolgen. So wird verhindert, dass eine veraltete Nachricht nur deshalb versendet wird, weil technisch noch Transportkapazität vorhanden war.

• Legen Sie für jeden Vorgang einen Zeitpunkt fest, zu dem seine Nutzbarkeit endet.
• Reservieren Sie Zeitbudget für interne Warteschlangen, TPS-Drosselung, Annahme durch den Anbieter und Wiederholungsversuche.
• Unterdrücken Sie den Versand, wenn das verbleibende Budget keine sinnvolle Zustellung mehr zulässt.
• Nutzen Sie den Plattformablauf als zusätzlichen Schutz, nicht als einzige fachliche Kontrolle.

Definieren Sie unterschiedliche Richtlinien für OTP, Transaktionsnachrichten und einwilligungsbasierte Kampagnen

Es gibt keine einheitliche angemessene Frist für alle Verkehrsarten. Die Richtlinie muss aus der erwarteten Handlung, den Folgen einer verspäteten Nachricht und der Möglichkeit abgeleitet werden, sie durch aktuelle Informationen zu ersetzen. Die Frist sollte als Produkt- und Betriebsregel dokumentiert werden, nicht als Annahme über die Latenz einer Route.

Bei OTP ist die Gültigkeit des Geheimnisses und des Authentifizierungskontexts maßgeblich. Bei Transaktionskommunikation ist entscheidend, ob das Ereignis noch offen ist oder ein neuerer Status vorliegt. Bei einwilligungsbasierten Kampagnen sind insbesondere der geschäftliche Zeitpunkt und die Vermeidung unerwarteter verspäteter Wiederholungen wichtig.

Konkrete Fristen müssen von den für Ablauf, Sicherheit, Datenschutz, Compliance sowie die jeweils geltenden lokalen regulatorischen oder vertraglichen Anforderungen zuständigen Teams genehmigt werden. Die Plattform muss diese Fristen überprüfbar umsetzen und erkennen lassen, welche Regel für jeden Vorgang angewendet wurde.

• OTP und Wiederherstellung: kurzes Fenster, abgestimmt auf die Akzeptanz des Geheimnisses; unterdrücken, wenn es vor dem Versand abläuft.
• Transaktionswarnungen: senden, solange das Ereignis gültig bleibt; durch ein Update ersetzen, wenn sich der Status geändert hat.
• Bestätigungen: keine alte Nachricht erneut senden, wenn eine spätere Bestätigung den aktuellen Status besser abbildet.
• Einwilligungsbasierte Kampagnen: nicht automatisch wiederholen, wenn Datum, Zeitfenster oder Angebotsgelegenheit bereits vorbei sind.

OTP: Stimmen Sie Transport und Geheimnis aufeinander ab, verwechseln Sie sie aber nicht

Wenn der Anwendungsfall den von NIST beschriebenen Anforderungen für Out-of-Band-Authentifizierung folgt, darf ein bestimmtes per SMS gesendetes OTP während seiner Gültigkeitsdauer nur einmal akzeptiert werden. Der Verifizierer muss es nach Ablauf ablehnen, selbst wenn die SMS erst danach zugestellt wird. Dass die Nachricht das Gerät erreicht, verlängert weder die Gültigkeit des Codes noch aktiviert es den Authentifizierungsvorgang erneut.

In der konkret herangezogenen Fassung von NIST SP 800-63B müssen die dort beschriebenen Out-of-Band-Authentifizierungen innerhalb eines Zeitfensters von zehn Minuten abgeschlossen werden; ein bestimmtes Geheimnis darf während seiner Gültigkeitsdauer nur einmal akzeptiert werden. Diese Anforderungen sind keine universelle Frist für jedes OTP per SMS und ersetzen nicht die Notwendigkeit einer eigenen Warteschlangenrichtlinie: Der Absender muss verhindern, dass ein Code, der nicht mehr nutzbar sein kann, weiter zur Zustellung gelangt.

Wenn ein Geheimnis weniger als 64 Bit hat, müssen gemäß den von NIST beschriebenen Anforderungen auch fehlgeschlagene Versuche begrenzt werden. Die Ausgabe eines neuen Geheimnisses darf diesen Zähler nicht zurücksetzen. Diese Regel gehört zum Verifizierer und kann nicht aus dem Transportstatus der SMS abgeleitet werden.

NIST erlaubt die Übertragung eines Authentifizierungsgeheimnisses über PSTN, einschließlich SMS, behandelt diesen Kanal jedoch als Out-of-Band-Authentifizierung mit Einschränkungen. Alternativen sollten für Personen angeboten werden, die PSTN nicht nutzen können. Risikoteams sollten außerdem für den Anwendungsfall relevante Signale berücksichtigen, etwa SIM-Wechsel, Rufnummernportierung oder Gerätewechsel.

• Weisen Sie dem OTP im Verifizierer einen überprüfbaren Ablauf zu.
• Setzen Sie ein Nutzbarkeitsende für den Versand, das den Versand bereits abgelaufener oder praktisch abgelaufener Codes verhindert.
• Behandeln Sie einen DLR nicht als Nachweis dafür, dass der Code gesehen, eingegeben oder akzeptiert wurde.
• Erstellen Sie einen neuen Vorgang nur nach einer neuen Anfrage oder innerhalb eines kontrollierten Ablaufs.
• Setzen Sie Kontrollen für fehlgeschlagene Versuche nicht allein durch die Erzeugung eines neuen Codes zurück.

Koordinieren Sie Warteschlangen, TPS und Wiederholungsversuche mit der verbleibenden Zeit

Eine Warteschlange kann eine bei ihrer Erstellung gültige Nachricht vor dem Versand nutzlos machen. Das geschieht, wenn sich Aufgaben ansammeln, TPS-Limits angewendet werden, auf eine Upstream-Antwort gewartet wird oder ein Wiederholungsversuch geplant wird, ohne das Nutzbarkeitsende zu prüfen.

Die Planung sollte auf der verbleibenden Zeit beruhen, nicht nur auf Alter oder Priorität. Eine Nachricht mit kurzem Fenster benötigt eine frühe Entscheidung: senden, wenn dies richtlinienkonform möglich ist, sie priorisieren, wenn dies legitim und sicher ist, oder sie beenden, bevor weitere Ressourcen verbraucht werden. Es ist nicht richtig, sie unbegrenzt aufzubewahren, nur weil noch keine endgültige Antwort eingegangen ist.

3GPP beschreibt Wiederholungsversuche nach temporären Bedingungen sowie einen Modus mit nur einem Versuch. Ob Wiederholungsversuche verfügbar sind und welche Semantik sie haben, hängt jedoch von Implementierung, Route und Integration ab. Die Auswahl sollte deshalb nicht für alle Fälle automatisch erfolgen. Ein Wiederholungsversuch kann sinnvoll sein, wenn die Information weiterhin gültig ist und genügend Zeit verbleibt; er kann schädlich sein, wenn der Inhalt von einem sich schnell ändernden Status abhängt.

• Berechnen Sie die verbleibende Zeit vor dem Einreihen und vor jedem Wiederholungsversuch.
• Planen Sie keinen Wiederholungsversuch, dessen erwartete Ausführung nach dem Ende der Nutzbarkeit liegt.
• Wenden Sie Wiederholungsversuche nur bei vorübergehenden Bedingungen und mit einer expliziten Richtlinie pro Anwendungsfall an.
• Erwägen Sie einen einzigen Versuch, wenn das Risiko einer verspäteten Zustellung den Nutzen weiterer Versuche übersteigt.
• Beenden Sie Wiederholungsversuche, wenn der Vorgang storniert wird, ein Update die Nachricht ersetzt oder die Nutzbarkeit abläuft.

Interpretieren Sie DLR als Transportsignale, nicht als Nutzungsnachweis

Zustellstatus sind für den Betrieb notwendig, dürfen aber nicht über ihre Aussagekraft hinaus interpretiert werden. Die Bezeichnungen, die Quelle der Bestätigung und die genaue Bedeutung jedes Status hängen von Integration, Anbieter, Betreiber und Route ab. Sie müssen gemäß der jeweils geltenden technischen und vertraglichen Dokumentation ausgelegt werden.

Einige Integrationen verwenden beispielsweise eine Taxonomie mit Labels wie „queued“, „sent“, „delivered“, „undelivered“ oder „failed“. Diese Labels sind keine standardisierten oder universellen SMS-Status. In einer solchen Integration kann „queued“ bedeuten, dass die Anfrage angenommen wurde und auf Versand wartet; „sent“ kann die Annahme durch einen Upstream-Betreiber anzeigen; und „delivered“ kann eine in der Transportkette verfügbare Bestätigung widerspiegeln. Umfang und Zuverlässigkeit dieser Signale unterscheiden sich je nach Integration, Betreiber und Route.

Ein DLR mit dem Status zugestellt beweist nicht, dass eine Person die SMS gelesen, verstanden oder verwendet hat. Bei SMS gibt es kein gleichwertiges Leseereignis, das die Zustellung in einen Nachweis der Nutzung verwandeln könnte. Ebenso darf nicht angenommen werden, dass ein zugestellter DLR universell garantiert, dass der Inhalt auf dem Gerät sichtbar war oder die erwartete Handlung ausgelöst hat.

Daher muss das System den externen Transportstatus vom Geschäftsergebnis trennen. Bei einem OTP sind beispielsweise mindestens die gemeldete Zustellung, der Validierungsversuch sowie die Annahme oder Ablehnung des Geheimnisses relevant. Keines dieser Ereignisse darf die anderen ersetzen.

• Beispiele einer Integrationstaxonomie: „queued“ kann bedeuten, dass die Anfrage auf der meldenden Plattform angenommen wurde und auf den Versand wartet.
• „Sent“ kann, abhängig von der dokumentierten Semantik der Integration, die Annahme durch einen Upstream-Betreiber oder -Anbieter anzeigen.
• „Delivered“ kann eine in der Transportkette verfügbare Zustellbestätigung darstellen; es entspricht nicht Lesen oder Nutzung.
• „Undelivered“ oder „failed“ können auf Nichtzustellung oder eine Unmöglichkeit des Versands hinweisen; bewahren Sie den je nach Integration verfügbaren Grund auf.
• Geschäftsergebnis: unabhängiger Status, etwa Code akzeptiert, Vorgang abgeschlossen, Warnung bestätigt oder Aktion nicht durchgeführt.

Wenn die Nutzbarkeit abläuft, beenden Sie den Vorgang mit einer expliziten Ursache

Eine ausstehende Nachricht, deren Nutzbarkeit abgelaufen ist, darf nicht mehrdeutig in der Warteschlange bleiben oder nur mit einem externen technischen Status klassifiziert werden. Die Plattform benötigt einen internen Endstatus, der die Entscheidung erklärt, beispielsweise „wegen Ablauf der Nutzbarkeit unterdrückt“, zusammen mit der Uhrzeit und der zugrunde liegenden Regel.

Die anschließende Maßnahme hängt von der Verkehrsart ab. Bei OTP oder Wiederherstellung unterdrücken Sie die ausstehende Nachricht und verlängern Sie die Lebensdauer des Geheimnisses nicht. Bei einer weiterhin relevanten Warnung erzeugen Sie ein gültiges Update, statt auf dem Originaltext zu bestehen. Bei einer einwilligungsbasierten Kampagne vermeiden Sie die automatische erneute Zustellung von Inhalten, deren Gelegenheit bereits vorbei ist.

Wenn die Plattform die Nachricht bereits einem Anbieter oder dem Netz übergeben hat, kann sie möglicherweise keine wirksame Stornierung garantieren. Deshalb ist die Unterdrückung vor dem Versand die wichtigste Kontrolle. Nach der Übergabe protokollieren Sie den bekannten Status, bewahren die Unsicherheit und verhindern, dass ein späterer DLR die Geschäftsentscheidung rückwirkend verändert.

• Stornieren: wenn die Integration und der Arbeitsstatus noch erlauben, die Nachricht vor dem Versand zurückzuziehen.
• Unterdrücken: in der eigenen Warteschlange wegen abgelaufener Nutzbarkeit beenden, ohne sie an den nächsten Hop weiterzugeben.
• Neu ausgeben: eine neue Kommunikation nur erstellen, wenn der Anwendungsfall dies weiterhin rechtfertigt und der Inhalt aktualisiert ist.
• Eskalieren: Ansammlungen, ungewöhnliche Wiederholungsversuche, inkonsistente DLR oder wiederholte Abläufe nach Ziel, Route oder Anbieter untersuchen.

Protokollieren Sie die Mindestdaten zur Prüfung jeder Entscheidung

Die Richtlinie ist nur überprüfbar, wenn jede Nachricht eine ausreichende Chronologie hinterlässt, um zu rekonstruieren, was und warum entschieden wurde. Zustell-Callbacks sind asynchron; daher darf die Eingangsreihenfolge eines DLR nicht die Zeitstempel von Erstellung, Annahme, Versand und Ablauf ersetzen.

Verwenden Sie eine stabile Korrelations-ID, um den Geschäftsvorgang mit jedem Transportversuch zu verbinden. Halten Sie die interne ID, gegebenenfalls vorhandene Anbieter-IDs und Versuch-IDs getrennt. So lassen sich Duplikate, Wiederholungsversuche, Unterdrückungen und verspätete Ereignisse analysieren, ohne unterschiedliche Vorgänge zu verwechseln.

Für die Betriebsprüfung sollten Protokolle mit Integritätskontrollen, Nachverfolgbarkeit von Änderungen, festgelegter Aufbewahrung und beschränktem Zugriff verwendet werden. Speichern Sie nicht mehr personenbezogene Inhalte als nötig und wenden Sie die jeweils geltenden Anforderungen an Datenschutz, Aufbewahrung, Berichtigung und Löschung an. Entscheidend ist, die angewendete Richtlinie, die Zustandsfolge und den Grund für die endgültige Entscheidung nachweisen zu können.

• Korrelations-ID des Vorgangs und Art des Anwendungsfalls.
• Interne Nachrichten-ID, Anbieter-IDs und IDs jedes Versuchs, sofern vorhanden.
• Zeitpunkt der Erstellung, Annahme, Einreihung und Entfernung aus der Warteschlange, Versand sowie Empfang jedes DLR.
• Konfiguriertes technisches Ablaufdatum, inhaltliche Gültigkeit und Ende der Nutzbarkeit.
• Gemeldeter technischer Status, interner Endstatus und Zeitstempel jedes Übergangs.
• Entscheidung über Wiederholungsversuch, Stornierung oder Unterdrückung einschließlich Grund und angewendeter Regel.
• Geschäftsergebnis, sofern zutreffend, ohne es aus einem DLR abzuleiten.