Jest na ten temat dobry artykuł w Wikipedii .
Najwcześniejsze iteracje NCP używane przez ARPAnet były bardziej jak strumienie bitowe niż strumienie bajtów lub próby wynegocjowania dogodnego rozmiaru bajtu; 8-bitowy bajt został znormalizowany dopiero znacznie później. Było również kilka prób stworzenia protokołów przesyłania plików, które działałyby na różnych komputerach (poczta początkowo była funkcją protokołu FTP, głównie jako polecenia MAILiMLFL , a następnie podzielona na MTP , a później SMTP ). Te maszyny często miały różne kodowanie znaków - ASCII vs EBCDIC - lub nawet różne rozmiary bajtów , 8-bitowe bajty vs 6-bitowe vs ...
Dlatego początkowo zdefiniowano funkcje przesyłania poczty do przesyłania stosunkowo krótkich wiadomości w postaci zwykłego tekstu; w szczególności „NVT-ASCII”. Na przykład RFC 772 mówi:
OŚWIADCZENIE I PRZECHOWYWANIE POCZTY
Poczta jest przesyłana z urządzenia pamięci masowej na hoście wysyłającym do urządzenia pamięci masowej na hoście odbierającym. Może być konieczne wykonanie pewnych przekształceń w poczcie, ponieważ reprezentacje przechowywania danych w dwóch systemach są różne. Na przykład NVT-ASCII ma różne reprezentacje przechowywania danych w różnych systemach. PDP-10 zazwyczaj przechowują NVT-ASCII jako pięć 7-bitowych znaków ASCII, wyrównanych do lewej w 36-bitowym słowie. 360 przechowuje NVT-ASCII jako cztery 8-bitowe kody EBCDIC w 32-bitowym słowie. Multics przechowuje NVT-ASCII jako cztery 9-bitowe znaki w 36-bitowym słowie.
Dla uproszczenia wszystkie dane muszą być reprezentowane w MTP jako NVT-ASCII. Oznacza to, że znaki muszą zostać przekonwertowane na standardową reprezentację NVT-ASCII podczas przesyłania tekstu, niezależnie od tego, czy hosty wysyłające i odbierające są różne. Nadawca konwertuje dane z wewnętrznej reprezentacji znaków na standardową 8-bitową reprezentację NVT-ASCII (patrz specyfikacja TELNET). Odbiornik konwertuje dane ze standardowego formularza na własny formularz wewnętrzny. Zgodnie z tym standardem, sekwencja powinna być użyta do oznaczenia końca linii tekstu.
Mimo że osiem bitów było transmitowanych przez drut, ósmy bit często bywał odrzucany lub zniekształcany, ponieważ nie było wymogu jego zachowania; w rzeczywistości niektóre protokoły wymagały, aby ósmy bit był ustawiony na zero, na przykład początkowy RFC SMTP, jak podano poniżej. Innymi słowy, oprogramowanie nie było 8-bitowe .
Transfer danych
Połączenie TCP obsługuje transmisję 8-bitowych bajtów. Dane SMTP to 7-bitowe znaki ASCII. Każdy znak jest przesyłany jako 8-bitowy bajt z bitem wyższego rzędu zerowanym.
Trwało to przez długi czas, nawet po rozpowszechnieniu 8-bitowych kodowań znaków ISO-8859- #. Chociaż niektóre serwery były już czyste 8-bitowo, wiele innych nie, a ślepe wysyłanie 8-bitowych danych spowodowałoby zniekształcenie wiadomości.
Później opublikowano „Extended SMTP” , który pozwala serwerom pocztowym zadeklarować obsługiwane przez nich rozszerzenia SMTP; jednym z nich było 8BITMIMEwskazanie, że serwer odbierający może bezpiecznie zaakceptować dane 8-bitowe. Części wiadomości MIME mogą mieć „ Content-Transfer-Encoding : 8bit”, co oznacza, że nie są w żaden sposób kodowane.
Jednak protokół SMTP pozostał oparty na liniach i ma limit linii oktetu 998, a także wykorzystuje .linię (0D 0A 2E 0D 0A) jako wskaźnik „końca wiadomości”. Oznacza to, że nawet jeśli większość plików binarnych można wysłać w niezmienionej postaci, nadal możliwe jest, że pliki zawierające tę sekwencję oktetów będą interpretowane jako koniec przesłanej wiadomości, a reszta pliku jako polecenie SMTP, prawdopodobnie powodując uszkodzenie. Podobnie „linia” dłuższa niż 998 oktetów może zostać odcięta przez serwer odbierający.
W 2000 r. Rozszerzenie ESMTP „BINARYMIME” zostało opublikowane jako RFC 3030 , umożliwiając przesyłanie surowych danych binarnych przez SMTP. Wiadomość jest teraz przesyłana w odcinkach o wcześniej wskazanej długości, z fragmentem o zerowej długości używanym jako terminator, a kodowanie Base64 i podobne nie są już potrzebne. Niestety niewiele serwerów SMTP obsługuje to rozszerzenie; na przykład ani Postfix, ani Exim4 nie reklamują się CHUNKINGw odpowiedzi na EHLO. Aby skorzystać z BINARYMIME, musi on być obsługiwany przez wszystkie serwery w ścieżce komunikatów, która może być więcej niż jednym lub dwoma.
Zobacz też: