C'è un buon articolo di Wikipedia su questo.
Le prime iterazioni di NCP utilizzate da ARPAnet erano più simili a flussi di bit che a flussi di byte o tentavano di negoziare una dimensione di byte conveniente; il byte a 8 bit è stato standardizzato solo molto più tardi. Ci sono stati anche diversi tentativi di creare protocolli di trasferimento file che avrebbero funzionato su macchine diverse (la posta inizialmente era una funzione del protocollo FTP, principalmente come i comandi MAILeMLFL , quindi divisa in MTP , in seguito SMTP ). Quelle macchine avevano spesso codifiche di caratteri differenti - ASCII vs EBCDIC - o persino dimensioni di byte diverse, byte a 8 bit vs 6 bit vs ...
Pertanto, inizialmente sono state definite funzioni di trasferimento della posta per il trasferimento di messaggi relativamente brevi in testo normale; in particolare, "NVT-ASCII". Ad esempio, RFC 772 dice:
RAPPRESENTAZIONE E STOCCAGGIO DELLA POSTA
La posta viene trasferita da un dispositivo di archiviazione nell'host mittente a un dispositivo di archiviazione nell'host ricevente. Potrebbe essere necessario eseguire determinate trasformazioni sulla posta perché le rappresentazioni della memorizzazione dei dati nei due sistemi sono diverse. Ad esempio, NVT-ASCII ha diverse rappresentazioni di archiviazione dei dati in diversi sistemi. I PDP-10 generalmente memorizzano NVT-ASCII come cinque caratteri ASCII a 7 bit, giustificati a sinistra in una parola di 36 bit. 360 memorizza NVT-ASCII come quattro codici EBCDIC a 8 bit in una parola a 32 bit. Multics memorizza NVT-ASCII come quattro caratteri a 9 bit in una parola a 36 bit.
Per semplicità, tutti i dati devono essere rappresentati in MTP come NVT-ASCII. Ciò significa che i caratteri devono essere convertiti nella rappresentazione NVT-ASCII standard durante la trasmissione di testo, indipendentemente dal fatto che gli host di invio e di ricezione siano diversi. Il mittente converte i dati dalla sua rappresentazione di carattere interna alla rappresentazione standard NVT-ASCII a 8 bit (vedere le specifiche TELNET). Il destinatario converte i dati dal modulo standard al proprio modulo interno. In conformità con questo standard, la sequenza dovrebbe essere utilizzata per indicare la fine di una riga di testo.
Anche se otto bit venivano trasmessi sul filo, l'ottavo bit veniva spesso scartato o rovinato, poiché non era necessario conservarlo; in effetti, alcuni protocolli richiedevano che l'ottavo bit fosse impostato su zero, come il RFC SMTP iniziale come indicato di seguito. In altre parole, il software non era pulito a 8 bit .
Trasferimento dati
La connessione TCP supporta la trasmissione di byte a 8 bit. I dati SMTP sono caratteri ASCII a 7 bit. Ogni carattere viene trasmesso come byte a 8 bit con il bit di ordine superiore azzerato.
Ciò è persistito a lungo anche dopo che le codifiche dei caratteri ISO-8859- # a 8 bit sono diventate diffuse. Anche se alcuni server erano già puliti a 8 bit, molti altri no, e l'invio alla cieca di dati a 8 bit avrebbe comportato messaggi alterati.
Successivamente, è stato pubblicato "Extended SMTP" , che consente ai server di posta di dichiarare le estensioni SMTP supportate; uno di questi 8BITMIMEindicava che il server ricevente poteva accettare in sicurezza dati a 8 bit. Le parti del messaggio MIME possono avere " Codifica trasferimento contenuto : 8 bit", indicando che non sono codificate in alcun modo.
Tuttavia, il protocollo SMTP è rimasto basato sulla linea e ha il limite di 998 ottetti, oltre a utilizzare una .linea (0D 0A 2E 0D 0A) come indicatore "fine del messaggio". Ciò significa che anche se la maggior parte dei file binari potrebbe essere inviata inalterata, è ancora possibile che i file che contengono questa sequenza di ottetti vengano interpretati come la fine del messaggio trasferito e il resto del file come un comando SMTP, con possibili danni. Allo stesso modo, una "linea" più lunga di 998 ottetti potrebbe essere tagliata dal server ricevente.
Nel 2000, l' estensione ESMTP "BINARYMIME" è stata pubblicata come RFC 3030 , consentendo il trasferimento di dati binari grezzi su SMTP. Il messaggio viene ora trasferito in blocchi di lunghezza predeterminata, con un blocco di lunghezza zero utilizzato come terminatore e Base64 e codifiche simili non sono più necessarie. Sfortunatamente, pochi server SMTP supportano questa estensione; ad esempio, né Postfix né Exim4 pubblicizzano CHUNKINGin risposta a EHLO. Per sfruttare BINARYMIME, dovrebbe essere supportato da tutti i server nel percorso del messaggio, che può essere più di uno o due.
Guarda anche: