摘要：
為了通過8bit字符擴充SMTP協(xié)議已經(jīng)定義了了[3][4]。按照這些協(xié)議的要求，通過擴
充的SMTP協(xié)議傳送的消息將按照MIME協(xié)議的[1][2]被編碼。
在這些協(xié)議開始工作前，為了傳送8bit數(shù)據(jù)，幾個SMTP補充協(xié)議采用ad-hoc機制。
這急需擴充了的SMTP環(huán)境和這些ad-hoc機制之間相互發(fā)揮作用。
1． 術(shù)語
RFC定義了7bit傳送。在本文檔中，傳送代理沒有在接收方的八進制上用SMTP信息中
的比特集清除高級比特，這樣的傳送被稱為8bit透明傳送。
在SMTP擴充協(xié)議中的一個補充說明和8傳送MIME用8位一組中的全部8位信息的
8bit擴充協(xié)議4被稱為8bit擴充SMTP
在擴充SMTP協(xié)議中不接收8比特字符的擴充體被稱為7bitESMTP
為改變或轉(zhuǎn)換一條信息的內(nèi)容用戶代理權(quán)威把網(wǎng)關(guān)定義為傳送代理。
2． 問題
在RFC821中定義的SMTP限制了internet郵件到美國ASCⅡ5字符的傳送，隨著internet
已發(fā)展成包含非英文通信，通過其它字符集而非美國ASCⅡ字符集用來通信的需要促使
許多賣主和用戶來擴充SMTP或RFC822來使用非ASCⅡ集。通常的方法是在現(xiàn)有的
RFC822/SMTP上傳送7bitISO642字符集全局變量，利用8bitISO8859來擴充SMTP和
RFC822協(xié)議，和使用PC的專用字符集。第三種方法是用來處理日本郵件的，通過成
對的八進制組清除高序bit，日文字符被表處理，顯現(xiàn)出來。在ISO釋放序列2022信息
中說明了從14bit字符集到7bit字符集的轉(zhuǎn)換。
只要這些補充說明能夠不通過中級轉(zhuǎn)換而進行通信，并有在不拖延地使用專用字符
集時有一個放寬的秘密協(xié)議，那么基本的郵件服務(wù)就能夠被提供。
在轉(zhuǎn)換為已定的8bitESMTP/MIME環(huán)境中，一個當(dāng)前沒有遵循協(xié)議的用戶所發(fā)送
的郵件能被另一個同樣沒有遵循協(xié)議的用戶所理解，這一點是很重要的。從8bit文本到
不可讀的Base—64編碼文本或被引用的可打印的“歪曲”編碼文本的轉(zhuǎn)換中降低了這
個現(xiàn)有的功能。在非美國ASCⅡ郵件和很可能出現(xiàn)到8bit/MIME轉(zhuǎn)換中的幾個新郵件
中，目前有一些有趣的非共同操作的例子，下面列出了到mine轉(zhuǎn)換的例子，在本備忘
錄中，只討論翻譯網(wǎng)關(guān)內(nèi)容4的解決辦法。



發(fā)件人

收件人僅7bit透明8bitMIME/ESMTP

僅7bit(1)(1)(1)

透明8bit(2)(3)(4)

MIME/ESMTP(5)(5)(6)


(1) 7bit非MIME發(fā)件人到7bitMIME或透明8bit收件人
假如在發(fā)件人和收件人之間達(dá)成一個內(nèi)部的“超波段”一致，通過ISO646或ISO2022
字符集變量的轉(zhuǎn)換這將持續(xù)無變化的工作。一個從7bit到8bit/EMTP的網(wǎng)關(guān)不需要改變這
些信息的內(nèi)部。
（2）8bit發(fā)件人到7bit非MIME收件人
收件人將會接收到打包的bit郵件，這樣的郵件導(dǎo)致了數(shù)據(jù)之間的錯誤解釋和字符的錯
誤顯示和打印。使用ISO8859中美國ASCII子集字符語言發(fā)送的郵件在某種程度上是可讀
的。
（3）透明8bit發(fā)件人到透明8bit收件人
假如當(dāng)收件人和發(fā)件人之間達(dá)成了內(nèi)部的“超波段”一致后，用一個非凡的沒有貼標(biāo)
簽的字符集，在這種情況下會工作嗎？
（4）透明8bit發(fā)件人到非MIME7bit收件人
假如網(wǎng)關(guān)提供一個可行的升級路徑，假如這個網(wǎng)關(guān)插入的暗含的字符集的標(biāo)簽是正確
的，假如收件人支持發(fā)件人選擇的字符集，這種情況是可行的。這個例子是本備忘錄的焦點。
（5）MIME/ESMTP發(fā)件人到非MIME7bit收件人
由于ESMTP/MIME發(fā)件人不知道收件人是否接收8bit，發(fā)件人將把文本編碼成Base-64
或者是可被收件人看作“歪曲”了的引用形式。為了提供一個可用的下破路徑，網(wǎng)關(guān)必須有
一些關(guān)于收件人責(zé)任的常識。當(dāng)字符集能被清楚的識別時，在RFC1345中描述的MNEM編
碼技術(shù)在這個例子中可能會有幫助。
（6）MIME/ESMTP發(fā)件人到MIME/ESMTP收件人
假如收件人支持發(fā)件人所選擇的字符集，就可以達(dá)到互操作性。
3． 從透明8bit到ESMTP/MIME的升級路徑
改進的用來支持?jǐn)U充的SMTP協(xié)議的網(wǎng)關(guān)可以提高MIME接收到的一個8bit信息。
這與所有被ESMTP發(fā)送的8bit郵件必須編碼與MIME的要求是一致的。
一個站點可以通過完成對所有正遠(yuǎn)離此站點的消息的MIME轉(zhuǎn)換升級MIMEen-masse
對于文本信息，假如此站點使用單一的字符集，那么這個信息體會被加上一個MIME版本
的報頭和在該站點使用的字符集的內(nèi)容類型。
為了表明任何編碼都是必須的，必須添加一個適當(dāng)?shù)膬?nèi)容轉(zhuǎn)換編碼的報頭線。

例：
MIME版本：1.0
內(nèi)容-類型：Text/Plain;字符集=ISO-8859-1
內(nèi)容轉(zhuǎn)換編碼：8bit

假如使用的字符集沒有任何可用的信息，網(wǎng)關(guān)應(yīng)該使用“未知8bit”字符集來改進內(nèi)容。
這個字符集參數(shù)的值表明了在消息中使用的字符集沒有任何可信的可以得到。
假如一個消息體被升級到MIME，包含非美國ASCII字符集的RFC822的報頭必須被升
級來和使用RFC1342編碼規(guī)則的報頭保持一致。
網(wǎng)關(guān)必須把所有未組織的報頭字段重新編碼以及根據(jù)RFC1342規(guī)則而來的RFC822的
“評注”和“短語”字段。
由于在RFC1342中沒有與“8bit”內(nèi)容報頭編碼規(guī)則值相同的消息體，所以所有8bit
報頭必須根據(jù)“B”或“Q”編碼方法來轉(zhuǎn)換形式。在ISO8859字符集中，“Q”編碼通常會
產(chǎn)生一些某種程度上可讀的報頭。
文檔中應(yīng)該用轉(zhuǎn)換字句:"rfc822-to-8bit","rfc822-to-base-64"，"rfc822-to-quoted-添加跟蹤信息。
例如：
來自dbc.mtview.ca.us通過dbc.mtview.ca.us
轉(zhuǎn)換rfc822-to-8bit,星期二，9月1日，1992年，01：18：00-0700

附錄-“未知8bit字符集“
以下部分定義了一個“字符集“參數(shù)，用于一個MIME的內(nèi)容類型字段。
一個有非凡用途的被稱為“未知8bit“的字符集被定義為一個未知的8bit字符集，被
編碼為一系列的8進制。它可以在任何語言的任何字符集中被當(dāng)作標(biāo)簽，使用任何編碼方式。
它不能被進一步定義。
在一條消息的“charset="字段中，這個符號的作用表明關(guān)于字符集的使用一切未知。在
非MIME到MIME的轉(zhuǎn)換中，將計劃使用這個標(biāo)簽，尤其在那些從SMTP到8bitESMTP/
MIME的轉(zhuǎn)換中。
這個字符集沒有打算被所有郵件的編寫者使用。可以假定郵件的編寫者了解所用的字
符集，并用在[1]中規(guī)定的字符集值標(biāo)記所寫郵件，通過當(dāng)前指定的序號文檔[6]修正所寫郵
件。
“未知8bit”標(biāo)簽僅計劃被郵件網(wǎng)關(guān)代理來使用。這個代理不能決定預(yù)期的字符集的超
波段信息。
未知8bit的解釋由郵件的閱讀者來負(fù)責(zé)。可以假定在許多例子中，人類用戶將能夠解
釋信息，選擇一個適當(dāng)?shù)淖址蝾A(yù)處理機。

致謝
本文檔起源于NedFreed,NeilKatin和本作者的一次非正式談話。JonathanLaventhol,
CraigEverhart,OlleJarnefors,andOlafurGudmundsson接受了主要的意見。本文檔用
IETFSMTP擴展工作組中許多成員的意見重新修訂而成。

參考

[1]Borenstein,N.,andN.Freed,"MultipurposeInternetMail
Extensions",RFC1341,Bellcore,Innosoft,June1992.

[2]Moore,K.,"RepresentationofNon-ASCIITextinInternetMessage
Headers",RFC1342,UniversityofTennessee,June1992.

[3]Klensin,J.,WGChair,Freed,N.,Editor,Rose,M.,Stefferud,
E.,andD.Crocker,"SMTPServiceExtensions"RFC1425,United
NationsUniversity,InnosoftInternational,Inc.,DoverBeach
Consulting,Inc.,NetworkManagementAssociates,Inc.,TheBranch
Office,February1993.

[4]Klensin,J.,WGChair,Freed,N.,Editor,Rose,M.,Stefferud,
E.,andD.Crocker,"SMTPServiceExtensionsfor8bit
MIMEtransport",RFC1426,UnitedNationsUniversity,Innosoft
International,Inc.,DoverBeachConsulting,Inc.,Network
ManagementAssociates,Inc.,TheBranchOffice,February1993.

[5]CodedCharacterSet--7-BitAmericanStandardCodeforInformation
Interchange,ANSIX3.4-1986.

[6]Reynolds,J.,andJ.Postel,"AssignedNumbers",STD2,RFC1340,
USC/InformationSciencesInstitute,July1992.

安全考慮
本備忘錄中未討論安全問題。

作者地址
GregVaudreuil




Internet郵件從Just-Send-8到8bit-SMTP/MIME的轉(zhuǎn)換
RFC1428TransitionofInternetMailfromJust-Send-8to8bit-SMTP/MIME