MINFO (Mailbox Information) Record Lookup
Definiert als experimentelles Protokoll im RFC 1035, wurde der MINFO-Record (Mailbox Information) entwickelt, um hochgranulare, administrative Routing-Metadaten an Mailinglisten und einzelne Postfächer anzuhängen. Während der Dial-up-Ära des Internets brachen Netzwerkverbindungen ständig ab und Mailserver stürzten häufig ab. Automatisierte Bounce-Nachrichten (Non-Delivery Reports oder NDRs) kreisten oft endlos in Schleifen zwischen Servern und verstopften die begrenzte Bandbreite des ARPANET. Der MINFO-Record war ein Versuch, strikte Routing-Regeln für die Fehlerbehandlung direkt im DNS-Layer bereitzustellen.
RMAILBX und EMAILBX Parameter
Im Gegensatz zu Standard-Records, die einen einzelnen Ziel-String nutzen, erforderte der MINFO-Payload zwei unterschiedliche Pointer. Der erste war die RMAILBX (Responsible Mailbox). Dieser Parameter definierte explizit die Domain oder das Postfach, das für den Empfang automatisierter Fehlermeldungen und Server-Bounces verantwortlich war, die mit einer bestimmten Mailingliste assoziiert waren. Der zweite Parameter war die EMAILBX (Error Mailbox), welche den menschlichen Administrator oder Maintainer definierte, der für die Liste zuständig war. Wenn ein externer Server bei dem Versuch, einen Bulk-Payload zuzustellen, auf einen kritischen Fehler stieß, sollte er den MINFO-Record abfragen, um herauszufinden, wohin genau die Error-Logs gesendet werden sollten, wobei die eigentliche Adresse des Absenders umgangen wurde.
Das Scheitern von Out-of-Band-Signaling
Der architektonische Kernfehler des MINFO-Records war, dass er auf "Out-of-Band"-Signaling angewiesen war. Es zwang einen Mailserver, der sich bereits mitten in der Verarbeitung einer SMTP-Transaktion befand, die Ausführung zu stoppen, eine neue UDP-Verbindung zu öffnen, den DNS-Layer nach MINFO-Records abzufragen, auf die Propagation zu warten und dann die Fehler-Routing-Pfade umzuschreiben. Dies erwies sich als signifikant langsamer und unzuverlässiger, als das Fehler-Routing einfach "In-Band" während der tatsächlichen E-Mail-Übertragung abzuwickeln.
SMTP-Header ersetzen DNS-Logik
Ingenieure erkannten schnell, dass das SMTP-Protokoll selbst weitaus besser geeignet war, Bounce-Metadaten zu handhaben als das DNS. Die Einführung spezifischer SMTP-Envelope-Header – allen voran die Header Return-Path und Errors-To – beseitigte den Bedarf an MINFO-Records komplett. Wenn ein Bulk-Sender heute einen Newsletter versendet, bettet er die Bounce-Verarbeitungsadresse direkt in die verborgenen Header der E-Mail ein. Stößt der empfangende Server auf einen Fehler, liest er den Header einfach lokal und feuert die Bounce-Nachricht sofort zurück, was keinerlei externe DNS-Lookups erfordert. Infolgedessen ignorieren Produktions-MTAs MINFO-Payloads komplett.