Es gibt einen guten Wikipedia-Artikel dazu.
Die frühesten von ARPAnet verwendeten Iterationen von NCP ähnelten eher Bitströmen als Byteströmen oder versuchten, eine geeignete Bytegröße auszuhandeln. Das 8-Bit-Byte wurde erst viel später standardisiert. Es gab auch mehrere Versuche, Dateiübertragungsprotokolle zu erstellen, die auf verschiedenen Computern funktionieren würden (E-Mail war anfangs eine Funktion des FTP-Protokolls, in erster Linie als Befehl MAILundMLFL , dann aufgeteilt in MTP , später SMTP ). Diese Maschinen hatten oft unterschiedliche Zeichenkodierungen - ASCII vs EBCDIC - oder sogar unterschiedliche Byte-Größen , 8-Bit-Bytes vs 6-Bit vs ...
Daher wurden ursprünglich Mail-Übertragungsfunktionen definiert, um relativ kurze Nachrichten im Klartext zu übertragen. speziell "NVT-ASCII". Zum Beispiel sagt RFC 772 :
MAIL VERTRETUNG UND LAGERUNG
E-Mails werden von einem Speichergerät auf dem sendenden Host zu einem Speichergerät auf dem empfangenden Host übertragen. Möglicherweise müssen bestimmte Transformationen für die E-Mail ausgeführt werden, da die Datenspeicherdarstellungen in den beiden Systemen unterschiedlich sind. Beispielsweise verfügt NVT-ASCII über unterschiedliche Datenspeicherdarstellungen in unterschiedlichen Systemen. PDP-10 speichern NVT-ASCII im Allgemeinen als fünf 7-Bit-ASCII-Zeichen, die in einem 36-Bit-Wort linksbündig ausgerichtet sind. 360 speichert NVT-ASCII als vier 8-Bit-EBCDIC-Codes in einem 32-Bit-Wort. Multics speichert NVT-ASCII als vier 9-Bit-Zeichen in einem 36-Bit-Wort.
Der Einfachheit halber müssen alle Daten in MTP als NVT-ASCII dargestellt werden. Dies bedeutet, dass Zeichen beim Übertragen von Text in die Standard-NVT-ASCII-Darstellung konvertiert werden müssen, unabhängig davon, ob der sendende und der empfangende Host unterschiedlich sind. Der Absender konvertiert die Daten aus seiner internen Zeichendarstellung in die Standard-8-Bit-NVT-ASCII-Darstellung (siehe TELNET-Spezifikation). Der Empfänger wandelt die Daten aus dem Standardformular in ein eigenes internes Formular um. In Übereinstimmung mit dieser Norm sollte die Sequenz verwendet werden, um das Ende einer Textzeile zu kennzeichnen.
Obwohl acht Bits über die Leitung übertragen wurden, wurde das achte Bit häufig verworfen oder beschädigt, da es nicht erforderlich war, es aufzubewahren. Tatsächlich erforderten einige Protokolle, dass das 8. Bit auf Null gesetzt wurde, wie beispielsweise der im Folgenden angegebene anfängliche SMTP-RFC . Mit anderen Worten, die Software war nicht 8-Bit-sauber .
Datentransfer
Die TCP-Verbindung unterstützt die Übertragung von 8-Bit-Bytes. Die SMTP-Daten bestehen aus 7-Bit-ASCII-Zeichen. Jedes Zeichen wird als 8-Bit-Byte übertragen, wobei das höherwertige Bit auf Null gesetzt wird.
Dies blieb auch nach der Verbreitung von 8-Bit-ISO-8859- # -Zeichenkodierungen noch lange bestehen. Obwohl einige Server bereits 8-Bit-fehlerfrei waren, waren es viele andere nicht, und das blinde Senden von 8-Bit-Daten hätte zu fehlerhaften Nachrichten geführt.
Später wurde "Extended SMTP" veröffentlicht, mit dem Mailserver die von ihnen unterstützten SMTP-Erweiterungen deklarieren können. Einer davon war 8BITMIME, dass der empfangende Server 8-Bit-Daten sicher akzeptieren konnte. MIME-Nachrichtenteile können " Content-Transfer-Encoding : 8bit" aufweisen, was darauf hinweist, dass sie in keiner Weise codiert sind.
Das SMTP-Protokoll blieb jedoch zeilenbasiert und hat das Zeilenlimit von 998 Oktetten sowie die Verwendung einer .Zeile (0D 0A 2E 0D 0A) als "Ende der Nachricht" -Anzeige. Dies bedeutet, dass, obwohl die meisten Binärdateien unverändert gesendet werden konnten, Dateien, die diese Oktettfolge enthalten, möglicherweise als Ende der übertragenen Nachricht und der Rest der Datei als SMTP-Befehl interpretiert werden und möglicherweise Schäden verursachen. In ähnlicher Weise kann eine "Zeile", die länger als 998 Oktette ist, vom empfangenden Server abgeschnitten werden.
Im Jahr 2000 wurde die ESMTP-Erweiterung "BINARYMIME" als RFC 3030 veröffentlicht , mit der die Übertragung von binären Rohdaten über SMTP möglich ist. Die Nachricht wird jetzt in Blöcken mit der angegebenen Länge übertragen, wobei ein Block mit der Länge Null als Abschluss verwendet wird. Base64- und ähnliche Codierungen werden nicht mehr benötigt. Leider unterstützen nur wenige SMTP-Server diese Erweiterung. Beispielsweise werben weder Postfix noch Exim4 CHUNKINGals Antwort auf EHLO. Um die Vorteile von BINARYMIME nutzen zu können, muss BINARYMIME von allen Servern im Nachrichtenpfad unterstützt werden, bei denen es sich um mehr als einen oder zwei handeln kann.
Siehe auch: