Zum Hauptinhalt springen

5. Adressauflösung und Mail-Handhabung (Address Resolution and Mail Handling)

Dieser Abschnitt beschreibt, wie SMTP-Clients bestimmen, wohin Mailnachrichten zugestellt werden sollen, und wie sie den Zustellungsprozess behandeln sollten.

5.1. Lokalisieren des Zielhosts (Locating the Target Host)​

Wenn ein SMTP-Client Mail an eine bestimmte Domain zuzustellen hat, muss er den oder die geeigneten Zielhosts bestimmen. Dieser Prozess verwendet das Domain Name System (DNS) und folgt diesen Schritten.

Schritt 1: MX-Records nachschlagen​

DNS nach Mail-eXchanger-(MX-)Records für die Zieldomain abfragen:

$ dig example.com MX

;; ANSWER SECTION:
example.com.    3600    IN  MX  10 mail1.example.com.
example.com.    3600    IN  MX  20 mail2.example.com.
example.com.    3600    IN  MX  30 mail3.example.com.

Schritt 2: Nach Priorität sortieren​

MX-Records nach Priorität sortieren; eine niedrigere Zahl bedeutet höhere Priorität:

  1. mail1.example.com (Priorität 10)
  2. mail2.example.com (Priorität 20)
  3. mail3.example.com (Priorität 30)

Schritt 3: Zustellung versuchen​

In Prioritätsreihenfolge versuchen, eine Verbindung zu jedem Host herzustellen:

  1. Verbindung zum MX mit höchster Priorität, also niedrigster Zahl, versuchen.
  2. Wenn die Verbindung fehlschlägt, die nächste Prioritätsstufe versuchen.
  3. Fortfahren, bis die Zustellung erfolgreich ist oder alle MX-Hosts ausgeschöpft sind.

Schritt 4: Fallback auf A/AAAA-Records​

Wenn keine MX-Records existieren, die Domain selbst als Mailserver behandeln:

  • A-Record (IPv4) oder AAAA-Record (IPv6) nachschlagen.
  • Direkte Verbindung zu dieser IP-Adresse versuchen.

Wichtig: Wenn MX-Records existieren, aber alle fehlschlagen, darf nicht auf A/AAAA-Records zurückgefallen werden.

Detaillierter Algorithmus​

1. MX-Records für die Zieldomain abfragen.
2. Wenn MX-Records gefunden wurden:
   a. Alle MX entfernen, die auf "." zeigen (Null MX).
   b. Verbleibende MX nach Priorität sortieren.
   c. Für jede Prioritätsstufe, beginnend mit der niedrigsten Zahl:
      i.   Alle MX-Hosts dieser Priorität zu IP-Adressen auflösen.
      ii.  Hosts gleicher Priorität zufällig ordnen.
      iii. Verbindung zu jedem Host versuchen.
      iv.  Wenn die Verbindung gelingt, Mail zustellen.
      v.   Wenn alle Hosts dieser Priorität fehlschlagen, nächste Priorität versuchen.
   d. Wenn alle MX-Hosts fehlschlagen, Zustellung zurückstellen (temporärer Fehler).
3. Wenn keine MX-Records gefunden wurden:
   a. A/AAAA-Records der Domain abfragen.
   b. Direkte Verbindung zur IP der Domain versuchen.
   c. Wenn die Verbindung fehlschlägt, Zustellung zurückstellen.
4. Wenn die Domain nicht auflösbar ist:
   - Permanenten Fehler zurückgeben (5xx-Code).

Beispielszenarien​

Szenario 1: Standardmäßige MX-Auflösung​

Domain: example.com

MX-Records:
  10 mail1.example.com
  20 mail2.example.com

Prozess:
1. mail1.example.com versuchen -> Erfolg, Mail zustellen

Szenario 2: Primärer MX fällt aus​

MX-Records:
  10 mail1.example.com (down)
  20 mail2.example.com

Prozess:
1. mail1.example.com versuchen -> Verbindung fehlgeschlagen
2. mail2.example.com versuchen -> Erfolg, Mail zustellen

Szenario 3: Keine MX-Records​

Domain: smallcompany.example

Keine MX-Records gefunden

Prozess:
1. A-Record für smallcompany.example nachschlagen
2. Direkt mit der IP-Adresse verbinden
3. Mail zustellen

Szenario 4: Null-MX-Record​

Domain: nomail.example

MX-Record:
  0 .

Bedeutung: Diese Domain nimmt keine Mail an
Prozess: Permanenten Fehler zurückgeben (556 oder 550)

Bewährte Verfahren​

  1. TTL beachten: DNS-Ergebnisse gemäß ihren TTL-Werten zwischenspeichern.
  2. Verbindungs-Timeouts: Angemessene Timeouts verwenden, z. B. 5 Minuten für die initiale Verbindung.
  3. Wiederholungslogik: Bei transienten Fehlern (4xx) periodisch erneut versuchen.
  4. Lastverteilung: Bei MX-Records gleicher Priorität die Auswahl zufällig ordnen.
  5. IPv6-Unterstützung: Sowohl A- als auch AAAA-Records versuchen.
  6. Fehlerbehandlung: Temporäre und permanente Fehler unterscheiden.

Häufige Fehler​

Fehler 1: Auf A-Record zurückfallen, wenn MX existiert, aber fehlschlägt

Falsch:
MX-Records existieren, aber alle schlagen fehl -> A-Record versuchen

Korrekt:
MX-Records existieren, aber alle schlagen fehl -> Zustellung zurückstellen (temporärer Fehler)

Fehler 2: Null MX nicht korrekt behandeln

Falsch:
MX: 0 . -> ignorieren und A-Record versuchen

Korrekt:
MX: 0 . -> Domain weist Mail ausdrücklich zurück, permanenten Fehler zurückgeben

5.2. IPv6 und MX-Records (IPv6 and MX Records)​

Beim Auflösen von MX-Hostnamen sollten Clients:

  1. sowohl A-Records (IPv4) als auch AAAA-Records (IPv6) abfragen,
  2. IPv6 bevorzugen, wenn beide verfügbar sind, sofern die Implementierung dies so vorsieht,
  3. auf IPv4 zurückfallen, wenn die IPv6-Verbindung fehlschlägt.

Beispiel:

mail.example.com hat:
  A     192.0.2.1
  AAAA  2001:db8::1

Prozess:
1. IPv6 versuchen: 2001:db8::1
2. Bei Fehlschlag IPv4 versuchen: 192.0.2.1

IPv6-Adressliterale​

SMTP unterstützt IPv6-Adressliterale in MAIL FROM und RCPT TO:

Format: user@[IPv6:2001:db8::1]

Beispiel:

C: MAIL FROM:`<sender@[IPv6:2001:db8::1]>`
S: 250 Ok

Dual-Stack-Überlegungen​

  1. Happy Eyeballs: IPv6 und IPv4 mit geringer Verzögerung parallel versuchen.
  2. Timeout-Behandlung: IPv6-Versuche dürfen IPv4 nicht zu lange verzögern.
  3. Präferenz: Konfiguration der IPv4/IPv6-Präferenz ermöglichen.
  4. Fallback: Für Kompatibilität stets IPv4-Fallback vorsehen.
Letztes Update am