Zum Hauptinhalt springen

6. Problemerkennung und -behandlung (Problem Detection and Handling)

Dieser Abschnitt behandelt, wie SMTP-Implementierungen verschiedene Probleme behandeln sollten, die während der Mailübertragung auftreten.

6.1. Zuverlässige Zustellung und Antworten per E-Mail​

Zustellstatusbenachrichtigungen (DSN)​

Wenn Mail nicht zugestellt werden kann, sollte das sendende System eine Zustellstatusbenachrichtigung, also eine Bounce-Nachricht, erzeugen, um den Absender zu informieren.

DSN-Anforderungen:

  • müssen an den Reverse-Path, also die MAIL-FROM-Adresse, gesendet werden (MUST);
  • müssen einen Null-Reverse-Path (MAIL FROM:<>) verwenden, um Schleifen zu verhindern (MUST);
  • sollten die ursprüngliche Nachricht oder deren Header enthalten (SHOULD);
  • sollten den Grund des Fehlers angeben (SHOULD).

Beispiel einer Bounce-Nachricht:

From: [email protected]
To: [email protected]
Subject: Undelivered Mail Returned to Sender

Your message to [email protected] could not be delivered:

  550 5.1.1 Mailbox does not exist

--- Original message headers follow ---
From: [email protected]
To: [email protected]
Subject: Important message
...

Erfolgsbenachrichtigungen​

Zustellungsbestätigungen bei Erfolg werden im Allgemeinen nicht gesendet, da sie zusätzlichen Verkehr erzeugen. Die DSN-Erweiterung erlaubt jedoch explizite Anforderungen positiver Zustellungsbestätigung.

Timeouts und Wiederholungen​

Wiederholungsplan:

  • erster Fehler: nach 30 Minuten erneut versuchen;
  • nachfolgende Fehler: exponentielles Backoff, z. B. 1 Stunde, 2 Stunden, 4 Stunden usw.;
  • maximale Wiederholungsperiode: mindestens 4 bis 5 Tage;
  • endgültiger Fehler: Bounce an den Absender senden.

Warnnachrichten:

  • nach 4 bis 6 Stunden eine Verzögerungswarnung an den Absender senden;
  • den Grund der Verzögerung angeben;
  • den Absender informieren, dass Zustellversuche fortgesetzt werden.

6.2. Unerwünschte, unaufgeforderte und "Angriffs"-Nachrichten​

SMTP-Server sollten Schutzmaßnahmen gegen Missbrauch implementieren.

Spam-Prävention​

Techniken:

  1. Empfängerverifikation: Prüfen, ob der Empfänger existiert, bevor Mail angenommen wird.
  2. Absenderverifikation: SPF, DKIM und DMARC prüfen.
  3. Rate Limiting: Nachrichten pro Verbindung oder Stunde begrenzen.
  4. Greylisting: Erstmalige Absender vorübergehend ablehnen.
  5. Inhaltsfilterung: Nachrichteninhalt auf Spam-Muster prüfen.
  6. Reputationssysteme: Absenderreputation verfolgen.

Denial-of-Service-(DoS-)Schutz​

Abwehrmaßnahmen:

  1. Verbindungslimits: Gleichzeitige Verbindungen von einer einzelnen IP begrenzen.
  2. Rate Limiting: Befehle pro Sekunde begrenzen.
  3. Tarpit: Verdächtige Absender verlangsamen.
  4. Ressourcenlimits: CPU- und Speichernutzung pro Verbindung begrenzen.
  5. Timeout-Durchsetzung: Inaktive Verbindungen trennen.

Directory-Harvest-Angriffe (DHA)​

Angreifer senden RCPT-TO-Befehle mit geratenen Adressen, um gültige Mailboxen zu finden.

Gegenmaßnahmen:

Verwundbar:
C: RCPT TO:``&lt;[email protected]&gt;``
S: 550 No such user        (zeigt ungültige Adresse)
C: RCPT TO:``&lt;[email protected]&gt;``
S: 250 Ok                  (zeigt gültige Adresse)

Geschützt:
- Antworten auf RCPT-Befehle verzögern
- gleiche Antwort für gültig und ungültig verwenden, z. B. immer "250 Ok"
- Empfänger erst während oder nach DATA verifizieren
- RCPT-Befehle begrenzen

Backscatter-Prävention​

Backscatter sind Bounces, die an gefälschte Absenderadressen gesendet werden und dadurch kollateralen Spam erzeugen.

Prävention:

  1. Zur SMTP-Zeit ablehnen: Ungültige Empfänger während der SMTP-Transaktion, vor DATA, ablehnen.
  2. Absender verifizieren: Mail von gefälschten Absendern nicht annehmen.
  3. Keine Bounces erzeugen: Für Mail unbekannter oder verdächtiger Herkunft keine Bounces erzeugen.
Gute Praxis:
C: RCPT TO:``&lt;[email protected]&gt;``
S: 550 5.1.1 User unknown    (sofort ablehnen)

Schlechte Praxis:
C: RCPT TO:``&lt;[email protected]&gt;``
S: 250 Ok                    (Mail annehmen)
(später Bounce an gefälschten Absender erzeugen)

6.3. Schleifenerkennung​

Mailschleifen treten auf, wenn Nachrichten wiederholt durch dieselben Server weitergeleitet werden.

Erkennungsmethoden​

Methode 1: Anzahl der Received-Header

Received-Header in der Nachricht zählen
Wenn Anzahl > 100:
  mit "554 5.4.6 Too many hops" ablehnen

Methode 2: Analyse der Received-Header

Received-Header analysieren
Prüfen, ob der aktuelle Server mehrfach erscheint
Falls ja:
  Schleife erkennen und ablehnen

Methode 3: Message-ID-Tracking

Message-ID kürzlich verarbeiteter Nachrichten merken
Wenn dieselbe Message-ID nach kurzer Zeit erneut erscheint:
  wahrscheinlich eine Schleife, ablehnen

Schleifenvermeidung​

Bewährte Verfahren:

  1. Hops begrenzen: Nach 50 bis 100 Received-Headern ablehnen.
  2. Muster erkennen: Wiederholte Servernamen in Trace-Informationen identifizieren.
  3. Schleifen brechen: Mail, die zu schleifen scheint, nicht weiterleiten.
  4. Konfiguration prüfen: Weiterleitungsregeln vermeiden, die Schleifen erzeugen.

Beispielschleife:

mail.a.example -> mail.b.example ->
mail.c.example -> mail.a.example (loop!)

6.4. Kompensation von Unregelmäßigkeiten​

SMTP-Implementierungen in der Praxis weichen manchmal von Standards ab. Robuste Implementierungen sollten häufige Unregelmäßigkeiten tolerant behandeln.

Häufige Unregelmäßigkeiten​

1. Zusätzliche Leerzeichen​

Einige Implementierungen senden zusätzliche Leerzeichen:

Nicht standardkonform:
C: MAIL  FROM: ``&lt;[email protected]&gt;``    (extra spaces)

Robuste Behandlung:
Akzeptieren und korrekt parsen

2. Befehle mit gemischter Groß-/Kleinschreibung​

Nicht standardkonform:
C: Mail From:``&lt;[email protected]&gt;``

Robuste Behandlung:
Als Groß-/Kleinschreibung-insensitiv behandeln

3. Fehlende Winkelklammern​

Einige alte Systeme lassen <> um Adressen weg:

Nicht standardkonform:
C: MAIL FROM:[email protected]

Robuste Behandlung:
Mit und ohne Klammern akzeptieren

4. Nur CR oder LF, nicht CRLF​

Der Standard verlangt CRLF (\r\n), aber einige Systeme senden nur LF (\n) oder CR (\r):

Robuste Behandlung:
CR, LF oder CRLF als Zeilenabschluss akzeptieren
(aber immer CRLF senden)

5. Lange Zeilen​

Einige Implementierungen senden Zeilen über den Grenzwerten:

Robuste Behandlung:
- Zeilen länger als 512 Oktette akzeptieren
- bei Bedarf intern aufteilen
- während der SMTP-Transaktion nicht abbrechen

Robustheitsprinzip​

"Sei konservativ in dem, was du sendest, und liberal in dem, was du akzeptierst."

  • Senden: Standards strikt einhalten.
  • Empfangen: Geringfügige Abweichungen tolerant akzeptieren.
  • Protokollieren: Nicht standardkonformes Verhalten aufzeichnen.
  • Nicht tun: Still korrigieren und weiterleiten, da dies Interoperabilitätsprobleme erhält.

Fehlerwiederherstellung​

Bei Unregelmäßigkeiten:

Option 1: Akzeptieren und fortfahren

Warnung protokollieren
Nachricht normal verarbeiten

Option 2: Akzeptieren mit Benachrichtigung

Warnung protokollieren
Nachricht verarbeiten
DSN über das Problem an den Postmaster senden

Option 3: Ablehnen

Nur bei schwerwiegenden Verstößen
Klare Fehlermeldung bereitstellen
Zur Analyse protokollieren

Konformitätstests​

Implementierer sollten testen gegen:

  • standardkonforme Server: korrekten Betrieb verifizieren;
  • bekannt fehlerhafte Implementierungen: Interoperabilität sicherstellen;
  • fehlerhaft geformte Eingaben: Fehlerbehandlung prüfen;
  • Randfälle: Grenzbedingungen und ungewöhnliche Szenarien testen.
Letztes Update am