A2P-SMS-Fehlertaxonomie: Ablehnungen, Ablauf und unsichere Ergebnisse klassifizieren

Warum ein einzelner Fehlerstatus für den Betrieb einer Route nicht ausreicht

Ein einzelner Status wie „fehlgeschlagen“ vereinfacht Berichte, entfernt jedoch die Informationen, die für die Entscheidung über das weitere Vorgehen erforderlich sind. Es ist nicht dasselbe, ob eine SMPP-Anfrage wegen einer ungültigen Zieladresse abgelehnt wird, ob das SMSC die Nachricht annimmt, diese aber während ihrer Gültigkeitsdauer abläuft, oder ob das System keinen interpretierbaren DLR erhält.

Die A2P-SMS-Fehlertaxonomie muss Ergebnisse zwischen Routen, Anbietern, Zielen und Zeitfenstern vergleichbar machen, ohne die ursprüngliche technische Evidenz zu ersetzen. Ihr Ziel ist nicht, die endgültige Ursache jeder Nachricht zu erraten, sondern beobachtbare Fakten zu ordnen und jedem Fall eine angemessene Maßnahme zuzuordnen.

Eine hilfreiche Klassifizierung beantwortet vier Fragen: Wo ist das Ergebnis entstanden, ist es endgültig oder kann es sich noch ändern, welche Evidenz stützt es und welche Maßnahme ist zulässig? Diese Disziplin reduziert unnötige Wiederholungsversuche, verhindert falsche Zuschreibungen und verbessert die Qualität technischer Eskalationen.

• Verwenden Sie „fehlgeschlagen“ nicht als Ursache.
• Halten Sie das Ergebnis der Anfrage, den Zustellstatus und die bestätigte Ursache getrennt.
• Unterscheiden Sie endgültige von Zwischenstatus.
• Bewahren Sie den originalen empfangenen Code und Text immer auf, auch nach Anwendung eines internen Mappings.

Evidenzprinzip: beobachtbare Fakten, Schlussfolgerungen und bestätigte Ursachen

Die erste Regel besteht darin, technische Fakten von ihrer Interpretation zu trennen. Eine SMPP-Antwort mit erfolgreichem command_status belegt, dass die Protokolloperation angenommen wurde; sie bestätigt nicht, dass die SMS das Endgerät erreicht hat. Ebenso ist ein DLR mit dem Status DELIVERED eine über die Zustellkette empfangene Bestätigung, jedoch kein unabhängiger und universeller Nachweis, dass eine Person die Nachricht gelesen oder physisch empfangen hat.

DLRs können Kennung, Sendedatum, Abschlussdatum, Status und Fehlercode enthalten. Diese Felder ermöglichen die Rekonstruktion eines Lebenszyklus, sofern die Kennung zuverlässig der ursprünglichen Nachricht zugeordnet werden kann. Das konkrete Format von in short_message übertragenen Receipts kann jedoch je nach Gateway oder SMSC variieren; daher muss der Parser je Anbieter oder Route kontrolliert werden.

Das Fehlen eines DLR beweist für sich genommen ebenfalls keine Nichtzustellung. Es kann daran liegen, dass der Callback nicht empfangen wurde, der DLR nicht interpretiert werden konnte, ein Abstimmungsversatz besteht oder die Upstream-Kette eine bestimmte Reporting-Richtlinie hat. Der Fall muss als Unsicherheit klassifiziert werden, bis zusätzliche Evidenz vorliegt.

• Beobachtbarer Fakt: HTTP-Antwort, submit_sm_resp, DLR, Callback, Statusabfrage oder internes Timeout.
• Schlussfolgerung: „wahrscheinliche Überlastung“, „mögliche Absenderbeschränkung“ oder „mögliche Filterung“.
• Bestätigte Ursache: nur dann, wenn ein Code, eine dokumentierte Antwort oder eine Untersuchung des Anbieters sie identifiziert.
• Vertrauensniveau: Erfassen Sie, ob die Klassifizierung direkt, abgeleitet oder noch unbestätigt ist.

Die fünf operativen Ergebnisfamilien

Eine minimale und vergleichbare Taxonomie kann Ergebnisse in fünf Familien organisieren. Jede Familie sollte den Originalstatus, die Quelle der Evidenz und das Vertrauensniveau bewahren. Die Familien ersetzen keine Anbietercodes: Sie fassen diese für Betrieb, Analyse und Entscheidungsfindung zusammen.

Dieselbe Route kann Ergebnisse aus mehreren Familien erzeugen. Daher sollte eine Route nicht anhand eines einzigen aggregierten Prozentsatzes bewertet werden, ohne die Zusammensetzung der Fehler, die zeitliche Entwicklung und die verfügbare Evidenz zu prüfen.

• Ablehnung vor Annahme: Die lokale Plattform bricht den Versuch ab, bevor das SMSC erreicht wird, oder das SMSC lehnt die Anfrage ab. Halten Sie beide Situationen getrennt. Mögliche technische Beispiele: Bind-Fehler, ungültige Zugangsdaten, ungültige Absenderadresse oder ungültige Zieladresse.
• Temporärer Fehler: Die Evidenz des Anbieters kennzeichnet das Ergebnis ausdrücklich als temporär oder wiederholbar. Machen Sie einen generischen Fehler nicht aus operativer Bequemlichkeit zu einem temporären Fehler.
• Endgültiger Fehler: Es liegt ein negatives Endergebnis vor, für das die Dokumentation oder die verfügbare Evidenz keinen sicheren Wiederholungsversuch vorsieht. Eine SMSC-Ablehnung kann zu dieser Familie gehören, wenn sie sich mit derselben Anfrage wahrscheinlich wiederholen wird.
• Ablauf: Die Nachricht hat vor Abschluss der Zustellung ein Gültigkeitsfenster ausgeschöpft. Dieser Fall muss vom endgültigen Fehler getrennt werden, da Gültigkeitsdauer und Anwendungsfall relevant sind.
• Unsicheres Ergebnis: Das SMSC könnte die Nachricht angenommen haben, es liegt jedoch kein empfangener und interpretierbarer DLR vor, der den Fall als zugestellt, fehlgeschlagen oder abgelaufen abschließt.

Daten, die pro Nachricht aufbewahrt werden sollten

Die Klassifizierung bleibt schwach, wenn die Protokolle keine Rekonstruktion der Abfolge erlauben. Die interne Kennung muss neben den von Plattform, Anbieter oder SMSC vergebenen Kennungen bestehen. Der DLR muss mit der ursprünglichen Nachricht verknüpft werden, ohne sich ausschließlich auf einen Receipt-Text zu stützen, der zwischen Implementierungen variieren kann.

Das Ziel sollte im standardisierten internationalen Format gemäß der Struktur des E.164-Nummerierungsplans gespeichert und von den Attributen getrennt werden, die für Routing oder Segmentierung verwendet werden. Die Normalisierung macht eine Nummer nicht gültig, aktiv, einwilligungsbasiert oder zustellbar; sie verbessert lediglich die Konsistenz der Datenverarbeitung und Analyse.

Wichtig ist auch eine kontrollierte Klassifizierung von Inhalt und Absender, ohne diese Felder zur Ableitung einer Ursache ohne Evidenz zu verwenden. So kann beispielsweise ein unterschiedliches Verhalten nach Absendertyp eine Untersuchung rechtfertigen, bestätigt aber nicht selbstständig eine Absenderbeschränkung.

• Interne Kennung des Versuchs und der logischen Nachricht.
• Kennungen von Plattform, Anbieter, SMSC und DLR, sofern vorhanden.
• Zeitstempel: Erstellung, Annahme, Versand, Aktualisierung, DLR-Empfang und interner Abschluss.
• Normalisiertes Ziel, zugehöriges Land und Betreiber nur dann, wenn ausreichende Evidenz für die Daten vorliegt.
• Absender, Absendertyp und relevante Anfragekonfiguration.
• Route, Anbieter, Verbindung, Parser-Version und Mapping-Version.
• Inhaltsklasse oder Anwendungsfall: OTP, transaktional oder rechtmäßiges Marketing.
• Originalstatus und -code, Originaltext, normalisierte Familie, Vertrauensniveau und nächste Maßnahme.

HTTP, SMPP und DLR mappen, ohne Informationen zu verlieren

Das Mapping sollte eine zusätzliche und umkehrbare Schicht sein. Speichern Sie zuerst die Originalantwort und wenden Sie dann eine versionierte Regel an, die eine operative Kategorie erzeugt. Überschreiben Sie keinen SMPP-Code, HTTP-Status oder DLR-Text mit einer internen Bezeichnung wie „ungültige Nummer“ oder „gefiltert“, wenn diese Ursache nicht bestätigt ist.

In SMPP informiert command_status über Erfolg oder Fehler einer SMPP-Anfrage. Codes wie ESME_RINVSRCADR, ESME_RINVDSTADR, ESME_RSYSERR, ESME_RBINDFAIL und ESME_RINVPASWD haben unterschiedliche technische Bedeutungen und müssen für die Diagnose verfügbar bleiben. Eine erfolgreiche Antwort auf submit_sm darf nicht als „zugestellt“ gemappt werden: Sie darf höchstens als „durch die Protokolloperation angenommen“ oder als entsprechender Zwischenstatus eingeordnet werden.

Auch Zustellstatus erfordern eine zeitliche Hierarchie. ENROUTE ist ein Zwischenstatus und kann sich beispielsweise zu DELIVERED oder EXPIRED entwickeln. Ein Parser darf eine Nachricht nicht irreversibel abschließen, solange nur ein Status vorliegt, der sich noch ändern kann.

• Erfassen Sie: Protokoll, Endpoint oder Befehl, Code, Text, Original-Payload und Empfangszeitstempel.
• Wenden Sie eine Regel mit Version, Geltungsbereich und Datum des Inkrafttretens an.
• Definieren Sie die Priorität zwischen Aktualisierungen: Ein gültiger endgültiger DLR muss Vorrang vor einem vorherigen Zwischenstatus haben.
• Halten Sie nicht interpretierbare DLRs in einer Prüfwarteschlange und klassifizieren Sie sie vorübergehend als unsicheres Ergebnis.
• Versionieren Sie Parser nach Anbieter, Verbindung oder Route, wenn das Receipt-Format dies erfordert.
• Vermeiden Sie eine programmatische Abhängigkeit von veränderlichen Texten spezifischer Fehler; verwenden Sie sie als aufbewahrte diagnostische Evidenz.

Klassifizierung nach Handlungsfähigkeit

Der Nutzen einer Taxonomie zeigt sich, wenn sie sichere Maßnahmen steuert. Nicht jede Kategorie erlaubt einen Wiederholungsversuch, und nicht jeder Vorfall erfordert das Stoppen des Verkehrs. Die Maßnahme muss von der Familie, dem Originalcode, dem Anwendungsfall, dem Gültigkeitsfenster und der gesammelten Evidenz abhängen.

Entscheidungen sollten durch explizite Regeln umgesetzt werden. Ein Wiederholungsversuch kann angemessen sein, wenn der Anbieter das Ergebnis als temporär oder wiederholbar kennzeichnet; er sollte nicht automatisch auf Ablehnungen angewandt werden, die mit derselben Anfrage wahrscheinlich denselben Fehler erzeugen. Bei Unsicherheit sollte zuerst der Status abgeglichen werden, bevor Duplikate erzeugt werden.

• Daten oder Konfiguration korrigieren: Wenden Sie dies bei Evidenz wie ungültigem Ziel, ungültigem Absender, Bind-Fehler oder falschen Zugangsdaten an. Validieren Sie vor einem erneuten Versand.
• Sicher wiederholen: nur mit Evidenz für Temporärität oder Wiederholbarkeit, einer Deduplizierungsrichtlinie und einem weiterhin sinnvollen Gültigkeitsfenster.
• Verkehr stoppen oder begrenzen: bei anhaltenden Anstiegen technischer Ablehnungen, Authentifizierungsfehlern, Systemfehlern oder Verhaltensänderungen, die eine Route betreffen. Die Maßnahme muss anhand von Daten überprüft werden, nicht anhand automatischer Zuschreibung.
• An den Anbieter eskalieren: bei anhaltenden Codes, inkonsistenten DLRs, nicht interpretierbaren Receipts, Abweichungen bei Kennungen oder zunehmenden unsicheren Ergebnissen.
• Beobachten und abgleichen: für Zwischenstatus, fehlende DLRs innerhalb des definierten Fensters oder Konflikte zwischen Statusquellen.

Mehrdeutige Fehler: Wann „Ursache nicht bestimmt“ verwendet werden sollte

Eine Kategorie „Ursache nicht bestimmt“ ist erforderlich, wenn die Evidenz keine konkrete Ursache erkennen lässt. Sie ist kein Analysefehler, sondern verhindert, dass eine Hypothese zu operativen Daten wird. Sie sollte etwa verwendet werden, wenn ein generischer Nichtzustellstatus ohne Code eingeht, der zwischen möglichen Ursachen unterscheiden könnte.

Ordnen Sie eine Nichtzustellung nicht automatisch Inhaltsfilterung, Nichtverfügbarkeit des Endgeräts, Absenderbeschränkung, Überlastung oder einem Nummerierungsproblem zu. Ein negativer Status kann mehrere Ursachen abdecken. Die Zuschreibung muss auf einen spezifischen Code, eine dokumentierte Anbieterantwort, konsistente Evidenz nach Segment oder eine bestätigte Untersuchung warten.

Damit diese Kategorie nützlich bleibt, darf sie nicht zu einer dauerhaften Sammelschublade werden. Jeder Fall muss ausreichend Metadaten bewahren, um neu klassifiziert werden zu können, wenn ein verspäteter DLR eintrifft, der Parser aktualisiert wird oder der Anbieter eine Klarstellung liefert.

• Verwenden Sie „Ursache nicht bestimmt“, wenn diskriminierende Evidenz fehlt.
• Nutzen Sie diese Kategorie nicht, um Parserfehler, verlorene Callbacks oder fehlende Korrelation zu verbergen: Erfassen Sie diese Probleme getrennt.
• Messen Sie ihren Anteil nach Route, Anbieter, Ziel und Integrationsversion.
• Leiten Sie eine Überprüfung ein, wenn sie nachhaltig steigt oder sich auf dieselbe Route oder dasselbe DLR-Format konzentriert.
• Klassifizieren Sie nur durch eine versionierte Regel neu und bewahren Sie die Änderungshistorie auf.

Unterschiedliche Regeln für OTP, Transaktionsnachrichten und rechtmäßiges Marketing

Die Fehlerkategorie ändert sich nicht mit dem Anwendungsfall, die Maßnahme kann sich jedoch ändern. Ein OTP hat einen zeitlich begrenzten Nutzen und verlangt besondere Vorsicht bei Wiederholungsversuchen: Ein doppelter oder verspäteter Code kann den Empfänger verwirren und den Zugriff nicht lösen. Das System muss die Gültigkeit des Codes beachten und Wiederholungen vermeiden, wenn sie keinen Nutzen mehr bringen.

Transaktionsnachrichten können eine andere Wiederholungsrichtlinie tolerieren, wenn ihr Inhalt weiterhin gültig ist und das Ereignis nicht schädlich dupliziert wird. Rechtmäßiges Marketing erfordert noch mehr Disziplin: Es darf nur an Empfänger mit der anwendbaren Rechtsgrundlage und den erforderlichen Einwilligungen gesendet werden, und ein unsicheres Ergebnis darf nicht zur Rechtfertigung wiederholter Sendungen verwendet werden.

Die Gültigkeitsdauer ist Teil der Entscheidung. Ein Ablauf zeigt an, dass die Nachricht ausstehend blieb, bis ein konfiguriertes Fenster ausgeschöpft war, bevor sie auf der Plattform fehlschlug. Analysieren Sie Abläufe daher zusammen mit der konfigurierten Gültigkeit und nicht nur als Indikator für die Qualität einer Route.

• OTP: schneller Abschluss, strenge Deduplizierung und Wiederholung nur, wenn der Code noch gültig ist und die Richtlinie dies zulässt.
• Transaktional: Prüfen Sie Idempotenz, Gültigkeit des Ereignisses und Duplikatsrisiko vor einem Wiederholungsversuch.
• Rechtmäßiges Marketing: Begrenzen Sie die Häufigkeit, beachten Sie geltende Einwilligungen und Ausschlüsse und nutzen Sie Unsicherheit nicht als Grund, erneut zu senden.
• Für alle Fälle: Dokumentieren Sie die Wiederholungsrichtlinie, die maximale Anzahl der Versuche und die Abschlussbedingung.