Zusammenfassung

  • Erst nachdem der Server 8BITMIME in der EHLO-Antwort dieser Sitzung angekündigt hatte, durfte der Client BODY=8BITMIME erklären und Oktette mit gesetztem oberem Bit senden.
  • Annahme begründete bitgenaue Verwahrung; vor einem unfähigen nächsten Hop musste das Relay verlustfreies gültiges Sieben-Bit-MIME herstellen oder dauerhaft fehlschlagen.

Die Beschreibung der Fracht verbreiterte nicht die Straße

MIME gab E-Mail Begriffe für Medientyp, Zeichensatz und Transferkodierung. Damit war der Inhalt beschreibbar, aber SMTP nicht automatisch breiter. RFC 2045 trennt 7bit, 8bit und binary. Ein korrekt beschriebenes MIME-Objekt konnte Oktette enthalten, deren oberes Bit der nächste Server nie zu bewahren versprochen hatte.

Die historische Frage lautete deshalb: Welche laufende Implementierung nahm diese Darstellung auf welcher Verbindung an, und wo endete ihre Verantwortung?

Drei RFCs stabilisierten ein kleines Versprechen

RFC 1426 veröffentlichte die erste Erweiterung im Februar 1993. RFC 1652 ersetzte sie im Juli 1994; RFC 6152 ersetzte RFC 1652 im März 2011. Diese Folge belegt Normgeschichte, keine heutige Verbreitung.

Der Server nennt 8BITMIME in einer erfolgreichen EHLO-Antwort. Das IANA-Register der SMTP-Erweiterungen führt das Schlüsselwort ohne EHLO-Parameter und verweist auf RFC 6152. Ein neues SMTP-Verb entstand nicht.

Der Client kann MAIL FROM um BODY=7BIT oder BODY=8BITMIME ergänzen. BODY bezeichnet den Oktettbereich des folgenden DATA-Inhalts, nicht Sprache, Zeichensatz oder Medientyp. Transporterlaubnis und Bedeutung bleiben verschiedene Tatsachen.

Die Erlaubnis gehörte zur aktuellen Verbindung

Vor einem Acht-Bit-Inhalt muss der Client per EHLO eine 250-Antwort mit der Fähigkeit erhalten. Fehlt sie, darf er keine Oktette außerhalb von US-ASCII senden. Dass TCP beliebige Bytes trägt oder dass dasselbe Produkt gestern tolerant war, ersetzt den Beleg dieser Sitzung nicht.

Das Versprechen gilt für einen Hop. Ein Relay kann annehmen und anschließend einen nächsten Server ohne 8BITMIME treffen. Die erste Anzeige spricht weder für den zweiten Server noch für das Darstellungsvermögen des Empfängers.

Annahme bedeutete Verwahrung jedes Bits

Ein fähiger Server muss alle Bits jedes über DATA angenommenen Oktetts bewahren und bei Zustellung oder Weiterleitung erhalten. Die Pflicht durchquert Spool, Scanner, Queue und Ausgangsprozess. Löscht eine interne Altkomponente das obere Bit, war die Anzeige des Frontends im laufenden System falsch.

Das ist keine Authentifizierung, kein Sicherheitsurteil und keine Zustellgarantie. Es ist die engere Pflicht, eine angenommene Darstellung nicht durch eine alte Sieben-Bit-Annahme zu verändern.

Acht Bit waren kein beliebiges Binärformat

DATA behält Zeilenstruktur und Punkttransparenz. Eine einzelne Punktzeile beendet weiter die Übertragung; Punkte am Zeilenanfang werden verdoppelt. Auch die Zeilenlänge bleibt begrenzt. RFC 6152 erlaubt Server, die nur 1.000 Oktette einschließlich CRLF pro Zeile garantieren.

8BITMIME trägt daher MIME-8bit, nicht binary. Es erweitert Werte innerhalb einer Zeile, beseitigt die Zeile aber nicht. CHUNKING und BINARYMIME gehören zu einer anderen Framing-Geschichte.

Der nächste Hop erzwang Wandlung oder Fehler

Kündigt der nächste Server die Erweiterung nicht an, darf das Relay nicht auf Toleranz hoffen. Es kann die Nachricht ohne Informationsverlust in gültiges Sieben-Bit-MIME transformieren oder die Barriere als dauerhaften Zustellfehler behandeln.

RFC 6152 schreibt keinen Konverter vor. Header, Multipart-Grenzen, Zeilenenden, Kodierungsangaben und Signaturen müssen zusammenpassen. Nur niedrige Ausgangsbytes genügen nicht, wenn der Leser eine andere Bedeutung erhält. Ist Verlustfreiheit nicht belegbar, ist sichtbares Scheitern ehrlicher als beschädigter Erfolg.

Die Erklärung ordnete den Beweis

BODY=8BITMIME ist eine Client-Aussage, keine automatische Wahrheit. Betrieb muss getrennt festhalten, was der Peer anbot, was der Client erklärte, welcher Oktettbereich tatsächlich erschien und was am nächsten Hop geschah. Nur dann lässt sich Korruption Sender, Wandlung, internem Verlust oder Darstellung zuordnen.

Der bleibende Fortschritt war die Begrenzung der Autorität. MIME beschrieb die Fracht; die SMTP-Verbindung erklärte, ob dieser Verwahrer sie übernehmen konnte; die nächste Verbindung fragte erneut.

Quellen und Grenzen

Die Linie bilden RFC 1426, RFC 1652 und RFC 6152. RFC 2045 definiert MIME-Bereiche, das IANA-Register den aktuellen Eintrag. Die Quellen messen keine heutige Nutzung oder Wandlungsrate.