Internet郵件從Just-Send-8到8bit-SMTP/MIME的轉換

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



發件人

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

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

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

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


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

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

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

附錄-“未知8bit字符集“
以下部分定義了一個“字符集“參數，用于一個MIME的內容類型字段。
一個有特殊用途的被稱為“未知8bit“的字符集被定義為一個未知的8bit字符集，被
編碼為一系列的8進制。它可以在任何語言的任何字符集中被當作標簽，使用任何編碼方式。
它不能被進一步定義。
在一條消息的“charset="字段中，這個符號的作用表明關于字符集的使用一切未知。在
非MIME到MIME的轉換中，將計劃使用這個標簽，尤其在那些從SMTP到8bitESMTP/
MIME的轉換中。
這個字符集沒有打算被所有郵件的編寫者使用?？梢约俣ㄠ]件的編寫者了解所用的字
符集，并用在[1]中規定的字符集值標記所寫郵件，通過當前指定的序號文檔[6]修正所寫郵
件。
“未知8bit”標簽僅計劃被郵件網關代理來使用。這個代理不能決定預期的字符集的超
波段信息。
未知8bit的解釋由郵件的閱讀者來負責?？梢约俣ㄔ谠S多例子中，人類用戶將能夠解
釋信息，選擇一個適當的字符集或預處理機。

致謝
本文檔起源于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的轉換
RFC1428TransitionofInternetMailfromJust-Send-8to8bit-SMTP/MIME