Eine Nachricht kann einen temporären Fehler zeigen, bevor sie später zugestellt wird. Greylisting ist eine mögliche Ursache. Throttling und andere vorübergehende Probleme können dieselbe Statusklasse erzeugen.
Wie funktioniert Greylisting?
Ein Empfänger stellt einen unbekannten sendenden Client vorübergehend zurück und prüft, ob ein späterer Versuch als Retry gewertet werden kann.
RFC 6647 beschreibt diese Anti-Abuse-Technik. Software, die niemals erneut versucht, kann die Zustellung über diese Prüfung nicht abschließen.
Der Empfänger gibt einen temporären SMTP-Fehler zurück und überlässt dem sendenden System die Verantwortung, die Nachricht aufzubewahren und erneut zu senden. Das Bestehen des Retry-Tests beseitigt dieses Hindernis. Die übrigen Filterregeln des Empfängers gelten weiterhin.
Wie erkennt der Empfänger einen Retry?
Der Empfänger vergleicht Informationen aus dem neuen Versuch mit einem Datensatz des früheren.
RFC 6647 empfiehlt, die sendende IP, den Envelope-Sender und den ersten Empfänger zu erfassen. Der Envelope-Sender ist die Adresse, die für Zustellfehlermeldungen verwendet wird.
Eine Änderung dieser Kennungen kann einen Retry wie eine neue Nachricht aussehen lassen. Der Versand über mehrere Server kann das Matching daher erschweren, abhängig von der Richtlinie des Empfängers.
Der RFC empfiehlt, nach einem erfolgreichen Retry weiteren Datenverkehr von der IP zuzulassen. Er empfiehlt außerdem, inaktive Datensätze ablaufen zu lassen, damit die Freigabe nicht unbegrenzt bestehen bleiben muss.
Warum kann Greylisting unerwünschte E-Mails aufhalten?
Es stoppt Software, die nur einen Versuch unternimmt und bei einem temporären Fehler aufgibt.
Die Technik testet das Retry-Verhalten. Sie stellt nicht fest, ob der Nachrichteninhalt sicher oder erwünscht ist. Missbräuchliche Software, die erneut versucht, kann die Prüfung ebenfalls bestehen.
Ein Empfänger benötigt daher weitere Filtersignale. Das erfolgreiche Bestehen von Greylisting belegt weder Authentifizierung noch Einwilligung oder eine gute Absenderreputation.
Wie lange kann die Verzögerung dauern?
Die Verzögerung hängt davon ab, wann der Absender es erneut versucht und welche Versuche der Empfänger als rechtzeitig akzeptiert.
RFC 6647 empfiehlt ein Standard-Retry-Fenster von einer Minute bis 24 Stunden, um typische Retry-Zeitpläne abzudecken. Das ist ein empfängerseitiger Bereich zur Erkennung von Retries. Er verspricht keine Zustellung innerhalb dieses Zeitraums.
Beispielsweise ist ein Retry nach 30 Sekunden für dieses Standardfenster zu früh. Ein Retry nach 30 Stunden kann als neuer Versuch behandelt werden. Ein qualifizierender Retry unterliegt weiterhin den übrigen Prüfungen des Empfängers.
Ein Absender, der erst nach einer Stunde erneut versucht, kann die Prüfung nicht früher bestehen. Bei einem Bestätigungscode, der nach zehn Minuten abläuft, trifft die Zustellung nach Ablauf des Codes ein.
Wie unterscheiden Sie Greylisting von einem anderen Fehler?
Nutzen Sie die Antwortdetails und die Retry-Historie. Ein temporärer Statuscode allein beweist kein Greylisting.
| Beobachtung | Was sie belegt |
|---|---|
4xx, dann erfolgreiche Zustellung | Ein temporärer Fehler wurde behoben. Greylisting ist eine mögliche Ursache |
Wiederholte 4xx-Antworten bis zum Ablauf | Zustellung nie abgeschlossen. Der Antworttext und das Retry-Muster können helfen, die Ursache zu ermitteln |
5xx-Antwort | Ein permanenter Fehler für diese SMTP-Anfrage |
RFC 6647 behandelt 421 beim Beenden der Verbindung und 450 in anderen Fällen. Er schreibt keinen Antworttext vor, daher muss der Text Greylisting nicht ausdrücklich benennen.
Verzögerte E-Mail und Bounces beschreiben die temporären und endgültigen Ergebnisse.
Was sollte der sendende Betreiber untersuchen?
Stellen Sie sicher, dass die Nachricht erneut gesendet wird und die identifizierenden Informationen für die Matching-Richtlinie des Empfängers geeignet bleiben.
Prüfen Sie, ob Retries den Envelope-Sender ändern oder zwischen sendenden IPs wechseln. Prüfen Sie außerdem, ob verschiedene empfangende MX-Server dieselbe Retry-Historie erkennen.
RFC 6647 empfiehlt, dass empfangende Server eine gemeinsame Greylisting-Datenbank nutzen, weil ein Retry ein anderes Ziel erreichen kann. Eine Diskrepanz kann legitime E-Mails wiederholt verzögern.
Übermitteln Sie dem empfangenden Betreiber Versuchszeiten, IPs und Antworttext, wenn die Verzögerung anhält. Der RFC unterstützt vom Empfänger verwaltete Ausnahmen für legitime Absender, die mit Greylisting nicht gut funktionieren.
Sollte ein Empfänger authentifizierte Einlieferungen greylisten?
RFC 6647 empfiehlt, authentifizierte Clients des eigenen Einlieferungsdienstes vom Greylisting auszunehmen. Diese Clients haben sich bereits zur Einlieferung authentifiziert, sodass die Prüfung, ob ein unbekannter Absender erneut versucht, eine vermeidbare Verzögerung verursacht. Wenden Sie die Regel am empfangenden oder einliefernden Dienst an, der sie steuert.
Prüfen Sie bei einer Anwendung, die eine Versandplattform nutzt, das Zustellergebnis der Nachricht. Ein erneuter Anwendungsversand repariert nicht das Greylisting-Matching des ersten Versuchs. Er kann Duplikate erzeugen.
Kurz gesagt
Greylisting testet das Retry-Verhalten.
Ein temporärer Fehler fordert den sendenden Server auf, es erneut zu versuchen. Er stellt keine dauerhafte Ablehnung dar.
Ein Retry garantiert keine Annahme.
Der Versuch muss die Timing- und Identitätsprüfungen des Empfängers sowie dessen übrige Mail-Richtlinien erfüllen.
Das Timing hängt von beiden Servern ab.
Das Retry-Fenster des Empfängers und der Zeitplan des Absenders bestimmen gemeinsam die Verzögerung.
Wiederholte Zurückstellungen erfordern eine Untersuchung.
Prüfen Sie Antwortdetails, Retries und sich ändernde Absenderkennungen, bevor Sie Greylisting als Ursache annehmen.