Ursachen für das Fehlschlagen von Sendungen

Bounces sind das Ergebnis eines Versandversuchs und -fehlers, bei dem der ISP Fehlermeldungen zurückgibt. Die Bounce-Verarbeitung ist ein wichtiger Bestandteil der Listenhygiene. Nach mehrmaligen Bounces einer E-Mail wird sie von diesem Prozess markiert und unterdrückt.

Dadurch wird verhindert, dass Systeme weiterhin E-Mails mit ungültigen E-Mail-Adressen versenden. Bounces sind eines der wichtigsten Kriterien, mit denen ISPs die IP-Reputation bestimmen. Es ist wichtig, diese Metrik im Auge zu behalten. Die häufigste Methode zur Messung des Versands von Marketing-Nachrichten ist wahrscheinlich der Vergleich von „Zugestellt“ mit „Bounce“. Je höher der Prozentsatz der zugestellten Mails ist, desto besser.

Wenn eine Nachricht nicht an ein Profil gesendet werden kann, sendet der Remote-Server automatisch eine Fehlermeldung an Adobe Campaign. Dieser Fehler wird qualifiziert, um festzustellen, ob die E-Mail-Adresse, die Telefonnummer oder das Gerät unter Quarantäne gestellt werden soll. Siehe Bounce-Message-Verwaltung.

Nach dem Versand einer Nachricht können Sie den Versandstatus für jedes Profil sowie den damit verbundenen Fehlertyp und die Ursache in den Versand-Logs einsehen.

Wenn eine E-Mail-Adresse unter Quarantäne gestellt wird oder sich ein Profil auf der Blockierungsliste befindet, wird der Empfänger bei der Versandvorbereitung ausgeschlossen. Ausgeschlossene Nachrichten werden im Versand-Dashboard aufgeführt.

Warum ist der Nachrichtenversand fehlgeschlagen?

Es gibt zwei Typen von fehlgeschlagenen Sendungen. Jeder Fehlertyp bestimmt, ob eine Adresse in Quarantäne gestellt wird oder nicht.

  • Hardbounces
    Hardbounces sind dauerhafte Fehler, die erzeugt werden, wenn ein ISP feststellt, dass eine E-Mail nicht an eine Abonnentenadresse zugestellt werden kann. Innerhalb von Adobe Campaign werden Hardbounces, die als nicht zustellbar kategorisiert sind, zur Quarantäneliste hinzugefügt, was bedeutet, dass kein erneuter Zustellversuch stattfindet. In manchen Fällen wird ein Hardbounce ignoriert, wenn die Ursache des Fehlers unbekannt ist.

    Im Folgenden finden Sie einige gängige Beispiele für Hardbounces: Adresse existiert nicht, Konto deaktiviert, fehlerhafte Syntax, ungültige Domain

  • Softbounces
    Softbounces sind temporäre Fehler, die von ISPs bei Versandproblemen von E-Mails erzeugt werden. Bei Softbounces werden mehrfache erneute Zustellversuche unternommen (abhängig von den benutzerdefinierten oder vorkonfigurierten Versandeinstellungen), um einen erfolgreichen Versand durchzuführen. Adressen, die kontinuierlich einen Softbounce verursachen, werden erst dann unter Quarantäne gestellt, wenn eine maximale Anzahl erneuter Zustellungen versucht wurde (was wiederum je nach Einstellungen variiert).

    Einige häufige Ursachen für Softbounces sind: Postfach voll, empfangender E-Mail-Server heruntergefahren, Probleme mit der Versender-Reputation.

Ignoriert: Vorübergehender Fehler, beispielsweise "Out of office" oder technischer Fehler bei Absendern vom Typ "Postmaster".

Die Feedback-Schleife funktioniert wie Bounce-E-Mails: Wenn ein Benutzer eine E-Mail als Spam kennzeichnet, können Sie E-Mail-Regeln in Adobe Campaign so konfigurieren, dass alle Sendungen an diesen Benutzer blockiert werden. Die Adressen dieser Benutzer befinden sich dann auf der Blockierungsliste, obwohl sie nicht auf den Abmelde-Link geklickt haben. Adressen werden in die Quarantänetabelle (NmsAddress) und nicht in die Empfängertabelle (NmsRecipient) mit dem Status Auf die Blockierungsliste gesetzt aufgenommen. Im Handbuch von Adobe mit Best Practices für die Zustellbarkeit erfahren Sie mehr über den Mechanismus der Feedback-Schleife.

Synchrone und asynchrone Fehler

Ein Nachrichtenversand kann sofort fehlschlagen. In diesem Fall wird dies als synchroner Fehler qualifiziert. Wenn der Nachrichtenversand zu einem späteren Zeitpunkt fehlschlägt, ist der Fehler asynchron.

Diese Fehlertypen werden wie folgt verwaltet:

  • Synchroner Fehler: Der vom Adobe Campaign-Versand-Server angesprochene Remote-Server gibt sofort eine Fehlermeldung zurück. Die Nachricht kann nicht an den Server des Profils gesendet werden. Der Mail Transfer Agent (MTA) bestimmt den Bounce-Typ und qualifiziert den Fehler, bevor er diese Informationen an Campaign zurücksendet, um zu ermitteln, ob die betroffenen E-Mail-Adressen unter Quarantäne gestellt werden sollen. Siehe Bounce-Message-Qualifizierung.

  • Asynchroner Fehler: Eine Bounce Message oder ein Statusbericht (SR) wird vom empfangenden Server verzögert zurückgesendet. Dieser Fehler wird mit einer mit dem Fehler verbundenen Bezeichnung qualifiziert. Asynchrone Fehler können bis zu eine Woche nach einem Versand auftreten.

HINWEIS

Für Managed Services-Benutzer erfolgt die Konfiguration des Bounce-Postfachs durch Adobe.

Qualifizierung von Bounce Messages

Die Art und Weise, wie die Bounce-Message-Qualifizierung in Adobe Campaign verarbeitet wird, hängt vom Fehlertyp ab:

  • Synchrone Fehler: Der MTA bestimmt den Bounce-Typ und die Qualifizierung und sendet diese Informationen an Campaign zurück. Die Bounce-Qualifizierungen in der Tabelle Versandlogqualifizierung werden nicht für Fehlernachrichten bei synchronen Sendungen verwendet.

  • Asynchrone Fehler: Die von Campaign zur Qualifizierung von fehlgeschlagenen Sendungen verwendeten Regeln werden im Knoten Administration > Campaign Management > Unzustellbarkeitsverwaltung > Versandlogqualifizierung aufgelistet. Asynchrone Bounces werden vom InMail-Prozess über die Regeln für eingehende E-Mails qualifiziert. Mehr dazu finden Sie in der Dokumentation zu Campaign Classic v7.

Verwaltung von erneuten Zustellversuchen

Wenn der Nachrichtenversand aufgrund eines temporären Fehlers fehlschlägt (Soft oder Ignoriert), versucht Campaign eine erneute Zustellung. Diese weiteren Zustellversuche können bis zum Ende der Versandlaufzeit durchgeführt werden.

Weitere Zustellversuche aufgrund von Softbounces und die Zeitdauer zwischen ihnen werden durch den MTA bestimmt, basierend auf Typ und Schweregrad der Bounce-Antworten, die von der E-Mail-Domain der Nachricht zurückgegeben werden.

HINWEIS

Die Einstellungen für weitere Zustellversuche in den Versandeigenschaften werden von Campaign nicht verwendet.

Gültigkeitszeitraum

Die Einstellung des Gültigkeitszeitraums in Ihren Campaign-Sendungen ist auf 3,5 Tage oder weniger begrenzt. Wenn Sie für Ihren Versand in Campaign einen Wert von mehr als 3,5 Tagen definieren, wird dieser nicht berücksichtigt.

Wenn der Gültigkeitszeitraum in Campaign beispielsweise auf den Standardwert von 5 Tagen eingestellt ist, werden Softbounce-Nachrichten in die Warteschlange für Wiederholungsversuche des MTA aufgenommen. Wiederholungsversuche werden dann nur bis zu 3,5 Tage ab dem Zeitpunkt, an dem die Nachricht beim MTA empfangen wurde, durchgeführt. In diesem Fall wird der in Campaign eingestellte Wert nicht verwendet.

Sobald eine Nachricht 3,5 Tage lang in der Warteschlange des MTA war und nicht gesendet werden konnte, wird sie mit einem Timeout beendet, und ihr Status ändert sich von Gesendet in Fehlgeschlagen (in den Versandlogs).

Weitere Informationen zum Gültigkeitszeitraum finden Sie im Abschnitt Dokumentation zu Adobe Campaign Classic v7.

E-Mail-Fehlertypen

Für den E-Mail-Kanal sind im Folgenden mögliche Ursachen für einen fehlgeschlagenen Versand aufgeführt.

Bezeichnung des Fehlers Fehlertyp Technischer Wert Beschreibung
Konto deaktiviert Softbounce / Hardbounce 4 Das mit der Adresse verknüpfte Konto ist nicht mehr aktiv. Wenn das Konto längere Zeit nicht abgefragt wird, kann es vom Internetanbieter geschlossen werden, was den Versand an diese Empfängeradresse unmöglich macht. Wenn das Konto vorübergehend wegen einer sechsmonatigen Inaktivität deaktiviert ist und wieder aktiviert werden kann, wird der Status "Mit Fehlern" zugewiesen und der Zustellversuch wird wiederholt, bis der Fehlerzähler 5 erreicht hat. Wenn aus den Fehlern hervorgeht, dass das Konto permanent deaktiviert ist, wird es sofort unter Quarantäne gestellt.
Adresse in Quarantäne Hard 9 Die Adresse wurde unter Quarantäne gestellt.
Adresse nicht angegeben Hard 7 Empfängeradresse fehlt.
Adresse schlechter Qualität Ignoriert 14 Qualitätsindex der Postanschrift ist zu niedrig.
Adresse, die auf die Blockierungsliste gesetzt wurde Hard 8 Die Adresse wurde zum Zeitpunkt des Versands der Blockierungsliste hinzugefügt. Dieser Status wird zum Importieren von Daten aus externen Listen und externen Systemen in die Quarantäneliste von Adobe Campaign verwendet.
Kontrollgruppenadresse Ignoriert 127 Empfängeradresse ist Teil der Kontrollgruppe.
Doppelt Ignoriert 10 Empfängeradresse bereits im Versand enthalten.
Fehler ignoriert Ignoriert 25 Die Adresse befindet sich auf der Zulassungsliste. Der Fehler wird daher ignoriert und eine E-Mail gesendet.
Ausgeschlossen nach Schlichtung Ignoriert 12 Der Empfänger wurde durch Anwendung einer Typologieregel vom Typ 'Schlichtung' ausgeschlossen.
Von einer SQL-Regel ausgeschlossen Ignoriert 11 Der Empfänger wurde durch Anwendung einer Typologieregel vom Typ 'SQL' ausgeschlossen.
Ungültige Domain Soft 2 Die Domain der E-Mail-Adresse ist fehlerhaft oder existiert nicht mehr. An dieses Profil werden wiederholte Zustellversuche unternommen, bis die Fehleranzahl 5 erreicht. Danach wird der Datensatz in den Quarantänestatus versetzt und die Zustellversuche werden eingestellt.
Postfach voll Soft 5 Das Postfach des Benutzers ist voll und kann keine Nachrichten mehr aufnehmen. An dieses Profil werden wiederholte Zustellversuche unternommen, bis die Fehleranzahl 5 erreicht. Danach wird der Datensatz in den Quarantänestatus versetzt und die Zustellversuche werden eingestellt.
Dieser Fehlertyp wird von einem Bereinigungsprozess verwaltet. Die Adresse erhält nach 30 Tagen wieder einen gültigen Status.
Warnung: Damit die Adresse automatisch aus der Quarantäne genommen werden kann, muss der technische Workflow für die Datenbankbereinigung gestartet sein.
Nicht angemeldet Ignoriert 6 Das Mobiltelefon des Empfängers war beim Versand der Nachricht ausgeschaltet oder verfügte über keinen Netzempfang.
Unbestimmt Unbestimmt 0 Die Adresse wird noch qualifiziert, da der Fehler noch nicht inkrementiert wurde. Dieser Fehlertyp tritt auf, wenn der Server eine bis dahin unbekannte Fehlermeldung sendet: Hierbei kann es sich um einen einmaligen Fehler handeln. Sollte er sich jedoch wiederholen, wird der Fehlerzähler erhöht, was die zuständigen technischen Mitarbeiter auf das Problem aufmerksam macht. Sie können dann über den Knoten Administration / Campaign Management / Unzustellbarkeitsverwaltung in der Baumstruktur eine Nachrichtenanalyse durchführen und diesen Fehler qualifizieren.
Kommt nicht für die Angebote infrage Ignoriert 16 Der Empfänger kommt für die Angebote im Versand nicht infrage.
Zurückgewiesen Softbounce / Hardbounce 20 Die Adresse wurde wegen eines Sicherheits-Feedbacks unter Quarantäne gestellt, da die Nachricht als Spam gemeldet wurde. Je nach Fehler wird der Zustellversuch wiederholt, bis der Fehlerzähler 5 erreicht hat, oder die Adresse wird sofort unter Quarantäne gestellt.
Größe der Zielgruppe begrenzt Ignoriert 17 Maximale Versandgröße wurde für den Empfänger erreicht.
Adresse nicht qualifiziert Ignoriert 15 Postanschrift wurde nicht qualifiziert
Unerreichbar Softbounce / Hardbounce 3 In der Verteilungskette der Nachricht ist ein Fehler aufgetreten. Hierbei kann es sich um einen Vorfall beim SMTP-Server oder eine zeitweilig unerreichbare Domain handeln etc. Je nach Fehler wird der Zustellversuch wiederholt, bis der Fehlerzähler 5 erreicht hat, oder die Adresse wird sofort unter Quarantäne gestellt.
Unbekannter Nutzer Hard 1 Die Adresse existiert nicht. An dieses Profil werden keine weiteren Zustellversuche unternommen.

Fehlertypen bei Push-Benachrichtigungen

Für den Mobile-App-Kanal sind unten mögliche Ursachen für einen fehlgeschlagenen Versand aufgeführt.

Quarantäne bei iOS-Geräten

Das HTTP/V2-Protokoll ermöglicht für jeden Push-Versand ein direktes Feedback zu dessen Status. Bei Verwendung des Connectors für das HTTP/V2-Protokoll wird der Feedback-Dienst des Workflows mobileAppOptOutMgt nicht mehr aufgerufen. Ein Token gilt als abgemeldet, wenn eine Mobile App deinstalliert oder neu installiert wird.

Wenn der APNS für eine Nachricht den Status "abgemeldet" zurückgibt, wird der Ziel-Token direkt unter Quarantäne gestellt.

Szenario
Status
Fehlernachricht
Typ des Fehlschlagens
Grund des Fehlschlagens
Erneut versuchen
Zielgerät eingeschaltet
OK
Zielgerät ausgeschaltet
OK
Empfänger deaktiviert Benachrichtigungen für die Anwendung
OK
Nachrichtenerstellung/Analysephase - Nutzdaten zu groß
Fehlgeschlagen
Nutzdaten zu lang
Soft
Zurückgewiesen
Nein
Nachrichtenerstellung/Analysephase - Problem mit Inhalt mit unerwartetem Format
Fehlgeschlagen
Verschiedene Fehlernachrichten je nach Fehler
Soft
Unbestimmt
Nein
Problem mit Zertifikat (Passwort, Beschädigung etc.) und Fehler bei Testverbindung mit APNS
Fehlgeschlagen
Verschiedene Fehlernachrichten je nach Fehler
Soft
Zurückgewiesen
Nein
Netzwerkverbindung während des Versands abgebrochen
Fehlgeschlagen
Verbindungsfehler
Unbestimmt
Unerreichbar
Ja
Zurückweisung von APNS-Nachricht: Abmeldung
Benutzer hat die Mobile App entfernt oder das Token ist abgelaufen
Fehlgeschlagen
Abgemeldet
Hard
Unbekannter Nutzer
Nein
Zurückweisung von APNS-Nachricht: alle anderen Fehler
Fehlgeschlagen
Der Grund für Zurückweisung wird in der Fehlernachricht angegeben
Soft
Zurückgewiesen
Nein

Quarantäne bei Android-Geräten

Für Android V1

Für jede Benachrichtigung erhält Adobe Campaign die synchronen Fehler direkt vom FCM-Server. Adobe Campaign verarbeitet diese unmittelbar und erstellt Hard- und Softbounces entsprechend des Schweregrads des Fehlers. Es können weitere Zustellversuche unternommen werden:

  • Nutzdatenlänge überschritten, Verbindungsproblem, Problem mit Dienstverfügbarkeit: Neuversuch wird unternommen, Softbounce, Grund für den Fehler ist Abgelehnt.
  • Gerätequote überschritten: kein Neuversuch, Softbounce, Grund für Fehler ist Abgelehnt.
  • Ungültiger oder abgemeldeter Token, unerwarteter Fehler, Problem mit Absenderkonto: kein Neuversuch, Hardbounce, Grund für Fehler ist Abgelehnt.

Der mobileAppOptOutMgt-Workflow wird alle sechs Stunden zur Aktualisierung der AppSubscriptionRcp-Tabelle durchgeführt. Für jeden abgemeldeten oder nicht mehr gültigen Token wird das Feld Deaktiviert auf Wahr gesetzt und das mit dem Gerät verknüpfte Abonnement wird automatisch von künftigen Sendungen ausgeschlossen.

Während der Versandanalyse werden alle Geräte, die von der Zielgruppe ausgeschlossen werden, automatisch zur Tabelle excludeLogAppSubRcp hinzugefügt.

HINWEIS

Im Folgenden finden Sie die unterschiedlichen Fehlertypen für den Baidu-Connector:

  • Verbindungsproblem zu Beginn des Versands: Fehlertyp Undefiniert, Grund Unerreichbar, Neuversuch wird unternommen.
  • Verbindung während des Versands unterbrochen: Softbounce, Grund für den Fehler Abgelehnt, Neuversuch wird unternommen.
  • Während des Versands von Baidu synchroner Fehler zurückgegeben: Hardbounce, Grund für den Fehler Abgelehnt, es wird kein Neuversuch unternommen.

Adobe Campaign kontaktiert den Baidu-Server alle zehn Minuten, um den Status der versendeten Nachrichten abzurufen, und aktualisiert die Versandlogs. Wenn eine Nachricht als gesendet gemeldet wird, ändert sich der Status der Nachricht in den Versandlogs in Erhalten. Wenn Baidu einen Fehler meldet, wird der Status auf Fehlgeschlagen gesetzt.

Für Android V2

Der Quarantänemechanismus für Android V2 verwendet denselben Prozess wie für Android V1. Dasselbe gilt für die Aktualisierung von Anmeldungen und Ausschlüssen. Weiterführende Informationen hierzu finden Sie im Abschnitt Android V1.

Szenario
Status
Fehlernachricht
Typ des Fehlschlagens
Grund des Fehlschlagens
Erneut versuchen
Nachrichtenerstellung/Analysephase: unzulässige Schlüsselwörter in den benutzerdefinierten Feldern verwendet
Fehlgeschlagen
Folgende Schlüsselwörter dürfen nicht benutzt werden: {1}
Soft
Nein
Nachrichtenerstellung/Analysephase: Nutzdaten zu groß
Fehlgeschlagen
Die Benachrichtigung ist zu groß: {1} Bit statt maximal {2}.
Soft
Zurückgewiesen
Nein
Netzwerkverbindung während des Versands abgebrochen
Fehlgeschlagen
Keine Antwort von Firebase Cloud Messaging für die Adresse: {1}
Soft
Unerreichbar
Ja
Zurückweisung von FCM-Nachricht: Der FCM-Server ist vorübergehend nicht verfügbar (z. B. durch Timeouts).
Fehlgeschlagen
Firebase Cloud Messaging ist zurzeit nicht verfügbar
Soft
Unerreichbar
Ja
Zurückweisung von FCM-Nachricht: Fehler bei der Authentifizierung des Absenderkontos
Fehlgeschlagen
Entwicklerkonto konnte nicht identifiziert werden, bitte Kennung und Kennwort prüfen.
Soft
Zurückgewiesen
Nein
Zurückweisung von FCM-Nachricht: Gerätequote überschritten
Fehlgeschlagen
Soft
Zurückgewiesen
Ja
Zurückweisung von FCM-Nachricht: ungültige Registrierung/nicht registriert
Fehlgeschlagen
Hard
Unbekannter Nutzer
Nein
Zurückweisung von FCM-Nachricht: alle anderen Fehler
Fehlgeschlagen
Der Firebase Cloud Messaging Server hat einen unerwarteten Fehlercode ausgegeben: {1} Zurückgewiesen
Nein
Zurückweisung von FCM-Nachricht: ungültiges Argument
Fehlgeschlagen
INVALID_ARGUMENT Ignoriert Unbestimmt
Nein
Zurückweisung von FCM-Nachricht: Authentifizierungsfehler bei Drittanbieter
Fehlgeschlagen
THIRD_PARTY_AUTH_ERROR Ignoriert Zurückgewiesen
Ja
Zurückweisung von FCM-Nachricht: Sender ID stimmt nicht überein
Fehlgeschlagen
SENDER_ID_MISMATCH Soft Unbekannter Nutzer
Nein
Zurückweisung von FCM-Nachricht: abgemeldet
Fehlgeschlagen
UNREGISTERED Hard Unbekannter Nutzer
Nein
Zurückweisung von FCM-Nachricht: intern
Fehlgeschlagen
INTERNAL Ignoriert Zurückgewiesen
Ja
Zurückweisung von FCM-Nachricht: nicht verfügbar
Fehlgeschlagen
UNAVAILABLE Ignoriert Zurückgewiesen
Ja
Zurückweisung von FCM-Nachricht: unerwarteter Fehlercode
Fehlgeschlagen
Unerwarteter Fehlercode Ignoriert Zurückgewiesen
Nein
Authentifizierung: Verbindungsproblem
Fehlgeschlagen
Verbindung zum Authentifizierungs-Server nicht möglich Ignoriert Zurückgewiesen
Ja
Authentifizierung: Nicht autorisierter Client oder Perimeter in Anfrage.
Fehlgeschlagen
unauthorized_client Ignoriert Zurückgewiesen
Nein
Authentifizierung: Der Client ist nicht berechtigt, Zugriffs-Token mit dieser Methode abzurufen, oder der Client ist für keinen der angeforderten Perimeter autorisiert.
Fehlgeschlagen
unauthorized_client Ignoriert Zurückgewiesen
Nein
Authentifizierung: Zugriff verweigert
Fehlgeschlagen
access_denied Ignoriert Zurückgewiesen
Nein
Authentifizierung: ungültige E-Mail-Adresse
Fehlgeschlagen
invalid_grant Ignoriert Zurückgewiesen
Nein
Authentifizierung: ungültiger JWT
Fehlgeschlagen
invalid_grant Ignoriert Zurückgewiesen
Nein
Authentifizierung: ungültige JWT-Signatur
Fehlgeschlagen
invalid_grant Ignoriert Zurückgewiesen
Nein
Authentifizierung: ungültiger OAuth-Perimeter oder ungültige ID-Token-Zielgruppe angegeben
Fehlgeschlagen
unauthorized_client Ignoriert Zurückgewiesen
Nein
Authentifizierung: OAuth-Client deaktiviert
Fehlgeschlagen
disabled_client Ignoriert Zurückgewiesen
Nein

Quarantäne für SMS

Für Standard-Connectoren

Die Besonderheiten für den SMS-Kanal sind unten aufgeführt.

HINWEIS

Die Tabelle Versandlogqualifizierung gilt nicht für den Connector Erweitertes allgemeines SMPP.

Szenario
Status
Fehlernachricht
Typ des Fehlschlagens
Grund des Fehlschlagens
An Anbieter gesendet
Gesendet
Auf Mobiltelefon erhalten
Erhalten
Fehler von Provider gemeldet
Fehlgeschlagen
Fehler beim Abrufen von Daten (SR oder MO)
Soft
Unerreichbar
Ungültige MT-Quittierung
Fehlgeschlagen
Fehler '{1}' bei der Verarbeitung des Empfangsbestätigungs-Frames eines Sendeauftrags
Soft
Unerreichbar
Fehler beim Senden von MT
Fehlgeschlagen
Fehler beim Senden der Nachrichten
Soft
Unerreichbar

Für den Connector für erweitertes allgemeines SMPP

Bei Verwendung des SMPP-Protokolls zum Senden von SMS-Nachrichten wird die Fehlerverwaltung anders gehandhabt.

Der SMPP-Connector ruft zum Filtern des Inhalts mithilfe regulärer Ausdrücke (regexes) Daten von der zurückgegebenen Empfangsbestätigung ab. Diese Daten werden dann mit den Informationen in der Tabelle Versandlogqualifizierung abgeglichen. Der Zugriff darauf erfolgt über das Menü Administration > Kampagnenverwaltung > Unzustellbarkeitsverwaltung.

Bevor ein neuer Fehlertyp qualifiziert wird, wird der Fehlergrund immer standardmäßig auf Abgelehnt gesetzt.

HINWEIS

Die Typen und Ursachen für Fehlschläge sind dieselben wie für E-Mails.

Erkundigen Sie sich bei Ihrem Provider nach einer Liste mit Status- und Fehlercodes, um in der Versandlogqualifizierungs-Tabelle die korrekten Fehlertypen und -ursachen anzugeben.

Beispiel einer generierten Nachricht:

SR Generic DELIVRD 000|#MESSAGE#
  • Alle Fehlernachrichten beginnen mit SR, sodass SMS-Fehlercodes von E-Mail-Fehlercodes unterschieden werden können.

  • Der zweite Teil der Fehlernachricht (in diesem Beispiel Allgemein) bezieht sich auf den Namen der SMSC-Implementierung entsprechend der Definition im Feld Name der SMSC-Implementierung des externen SMS-Kontos.

    Da derselbe Fehlercode bei jedem Provider eine andere Bedeutung haben kann, sehen Sie in diesem Feld, welcher Provider den Fehlercode erstellt hat. Den Fehler können Sie dann in der entsprechenden Dokumentation des Providers einsehen.

  • Der dritte Teil der Fehlernachricht (in diesem Beispiel DELIVRD) entspricht dem Statuscode, der von der Empfangsbestätigung unter Verwendung des – im externen SMS-Konto definierten – regulären Ausdruck zur Statusextraktion abgerufen wurde.

    Dieser reguläre Ausdruck ist im Tab SMSC-Besonderheiten des externen Kontos spezifiziert.
    Standardmäßig erfolgt die Regex-Extraktion des stat:-Felds entsprechend der Definition im Bereich Appendix B der SMPP 3.4-Spezifikation.

  • Der vierte Teil der Fehlernachricht (in diesem Beispiel 000) entspricht dem Fehlercode, der von der Empfangsbestätigung unter Verwendung des im externen SMS-Konto definierten regulären Ausdrucks zur Fehlercode-Extraktion extrahiert wurde.

    Dieser reguläre Ausdruck ist im Tab SMSC-Besonderheiten des externen Kontos spezifiziert.

    Standardmäßig erfolgt die Regex-Extraktion des err:-Felds entsprechend der Definition im Bereich Anhang B der SMPP 3.4-Spezifikation.

  • Alles, was hinter dem senkrechten Strich (|) steht, wird nur in der Spalte Erster Text der Tabelle Versandlogqualifizierung dargestellt. Nach der Bereinigung der Nachricht wird dieser Inhalt durch #MESSAGE# ersetzt. Dadurch wird vermieden, dass für ähnliche Fehler mehrere Einträge vorgenommen werden. Das Verfahren ist dasselbe wie für E-Mails.

Der Connector für erweitertes allgemeines SMPP wendet eine Heuristik an, um sinnvolle Standardwerte zu finden: Ein mit DELIV beginnender Status wird als erfolgreich bewertet, da dies den üblicherweise von Providern verwendeten Statuswerten DELIVRD oder DELIVERED entspricht. Alle anderen Statuswerte verursachen einen Hardbounce.

Auf dieser Seite