Dazu gibt es einen guten Wikipedia-Artikel .
Die frühesten Wiederholungen von NCP, wie sie von ARPAnet verwendet werden, waren eher Bitströme als Byteströme oder Versuche, eine geeignete Bytegröße auszuhandeln. Das 8-Bit-Byte wurde erst viel später standardisiert. Es wurden auch mehrere Versuche unternommen, Dateiübertragungsprotokolle zu erstellen, die auf verschiedenen Maschinen funktionieren (Mail war anfangs eine Funktion des FTP-Protokolls, vor allem als MAILundMLFL -Befehle, danach in MTP, später SMTP ). Diese Maschinen hatten oft unterschiedliche Zeichencodierungen - ASCII vs. EBCDIC - oder sogar unterschiedliche Byte-Größen, 8-Bit-Bytes vs. 6-Bit ...
Daher wurden ursprünglich Mailübertragungsfunktionen definiert, um relativ kurze Nachrichten im Klartext zu übertragen. insbesondere "NVT-ASCII". Zum Beispiel sagt RFC 772 :
MAIL-DARSTELLUNG UND LAGERUNG
Mail wird von einem Speichergerät im sendenden Host an ein Speichergerät im empfangenden Host übertragen. Es kann erforderlich sein, bestimmte Transformationen für die E-Mail durchzuführen, da die Darstellungen der Datenspeicherung in den beiden Systemen unterschiedlich sind. Zum Beispiel verfügt NVT-ASCII über unterschiedliche Datenspeicherdarstellungen in verschiedenen Systemen. PDP-10 speichert NVT-ASCII im Allgemeinen als fünf 7-Bit-ASCII-Zeichen, die in einem 36-Bit-Wort nach links ausgerichtet sind. 360s speichern 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 sich sendende und empfangende Hosts unterscheiden. Der Sender konvertiert die Daten von seiner internen Zeichendarstellung in die standardmäßige 8-Bit-NVT-ASCII-Darstellung (siehe TELNET-Spezifikation). Der Empfänger konvertiert die Daten vom Standardformular in ein eigenes internes Formular. In Übereinstimmung mit diesem Standard sollte die Sequenz verwendet werden, um das Ende einer Textzeile zu kennzeichnen.
Obwohl acht Bits über die Leitung übertragen wurden, wurde das 8. Bit oft verworfen oder verstümmelt, da es nicht erforderlich war, es zu erhalten. Einige Protokolle erforderten tatsächlich, dass das 8. Bit auf Null gesetzt wurde, wie beispielsweise der anfängliche SMTP-RFC (siehe unten). 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 sind 7-Bit-ASCII-Zeichen. Jedes Zeichen wird als 8-Bit-Byte übertragen, wobei das höherwertige Bit auf Null gesetzt wird.
Dies blieb lange Zeit bestehen, auch nachdem sich 8-Bit-Kodierungen nach ISO-8859- # weit verbreitet hatten. Obwohl einige Server bereits 8-Bit-Clean waren, war dies bei vielen anderen nicht der Fall, und das blinde Senden von 8-Bit-Daten hätte zu verstümmelten Nachrichten geführt.
Später wurde "Extended SMTP" veröffentlicht, sodass Mailserver die unterstützten SMTP-Erweiterungen angeben können. Eine davon war 8BITMIME, dass der empfangende Server 8-Bit-Daten sicher akzeptieren konnte. MIME-Nachrichtenteile können " Content-Transfer-Encoding : 8bit" haben, was darauf hinweist, dass sie in keiner Weise codiert sind.
Das SMTP-Protokoll blieb jedoch leitungsbasiert und hat das Zeilenlimit von 998 Bytes sowie die Verwendung einer .Leitung (0D 0A 2E 0D 0A) als "Ende der Nachricht". Dies bedeutet, dass, obwohl die meisten Binärdateien unverändert gesendet werden können, es immer noch möglich ist, dass Dateien, die diese Oktettfolge enthalten, als das Ende der übertragenen Nachricht und der Rest der Datei als SMTP-Befehl interpretiert werden, was zu Schäden führen kann. 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, die die Übertragung von binären Rohdaten über SMTP ermöglicht. Die Nachricht wird jetzt in Chunks mit der zuvor angegebenen Länge übertragen, wobei ein Chunk mit einer Länge von Null als Terminator verwendet wird und Base64- und ähnliche Kodierungen nicht mehr erforderlich sind. Leider unterstützen nur wenige SMTP-Server diese Erweiterung. Zum Beispiel werben weder Postfix noch Exim4 CHUNKINGals Antwort auf die EHLO. Um BINARYMIME zu nutzen, müsste es von allen Servern im Nachrichtenpfad unterstützt werden. Dies kann mehr als ein oder zwei sein.
Siehe auch: