13 N            30 e            47 v
      14 O            31 f            48 w         (pad) =
      15 P            32 g            49 x
      16 Q            33 h            50 y           (1) *
 
   (1) The character "*" is used to enclose portions of an
   encoded message to which encryption processing has not
   been applied.
 
 
                       Printable Encoding Characters
                                  Table 1
      注意本地的形式和轉換消息到標準形式及從標準形式轉換的功能可以在發送者和接
收者之間無信息損失的變動。
4.4 封裝機制
在一個由電子郵件傳輸系統解釋的頭的一個封裝層里的保密增強消息的封裝比一個
簡單的被加密或攜帶密碼控制信息的頭內的一定域的簡單的處理有更多的優勢。封裝提供
了一般性和那些在傳輸時被轉換的消息的用戶對用戶級的隔離的域。被插入到加密/鑒別
過程中的所有的域被放置在封裝的頭中。這個功能為只接收文本沒有從輸入文件或從其它
程序獲得頭域的郵件處理程序提供了兼容性。此外，保密增強處理能被遞歸使用。關于
MTS，合并到密碼鑒別或加密處理的信息將駐留到一個消息的文本部分，而不是頭部分。
用于保密增強郵件的封裝機制來自于RFC-934[11]中的敘述，這一敘述是基于internet
社區消息摘要處理的先例。準備的用于加密或鑒別的一個用戶消息將被轉換為圖1中的表
述。
作為一般的設計原則，敏感的數據通過將數據導入到被封裝的文本而不是通過將數
據導入到封裝的頭里的域的方法來進行保護。潛在的敏感頭信息的域可以包括這些域例
如：“Subject：”，包含的內容對于端到端的用戶和內部的用戶有意義。應用保護的頭域集
（可能是空的）由用戶選擇。不過強烈推薦所有的信息應當在封裝文本里復制
“X-Sender-ID：”和“X-Recipient-ID：”域的拷貝。
如果一個用戶希望對頭域公開保護，他們必須只出現在被封裝的文本中而不在被封
裝的頭中。如果公開保護要求一個消息的主題標識，推薦封裝的頭包含一個“Subject：”
域指出“被加密的郵件跟隨”。
如果要求一個頭信息的被鑒別的版本，除了本身在封裝頭里的數據，包含在被封裝
的本文里的數據也能被復制。例如，一個發送者希望提供接收者一個在一系列被封裝的文
本中的包括一個時間戳或消息計數域的被保護的消息的位置的標識。
一個與帶有消息封裝機制功能的保密增強郵件的完整性有關的特殊的點是值得注
意。被選擇用于傳輸編碼的IA5子集有目的的排除了字符“-”，因此被封裝的文本可以明
確的同一個消息的結束封裝的邊界相區分（Post-EB）不用求助于字符的填充。
boundary (Post-EB) without recourse to character stuffing.
 
   Enclosing Header Portion
           (Contains header fields per RFC-822)
 
   Blank Line
           (Separates Enclosing Header from Encapsulated Message)
 
   Encapsulated Message
 
       Pre-Encapsulation Boundary (Pre-EB)
           -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
 
       Encapsulated Header Portion
           (Contains encryption control fields inserted in plaintext.
           Examples include "X-DEK-Info:", "X-Sender-ID:", and
           "X-Key-Info:".
           Note that, although these control fields have line-oriented
           representations similar to RFC-822 header fields, the set
           of fields valid in this context is disjoint from those used
           in RFC-822 processing.)
 
       Blank Line
           (Separates Encapsulated Header from subsequent encoded
           Encapsulated Text Portion)
 
       Encapsulated Text Portion
           (Contains message data encoded as specified in Section 4.3;
           may incorporate protected copies of enclosing and
           encapsulated header fields such as "Subject:", etc.)
 
       Post-Encapsulation Boundary (Post-EB)
           -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
 
 
                           Message Encapsulation
                                 Figure 1
4.5 郵件列表的郵件
當郵件被定位到郵件列表，可以采用兩種不同的方法：IK-per-list方法和IK-per-recipient
方法。選擇依賴于對于發送者可用的信息和發送者的興趣。
如果一個消息的發送者定位一個消息到一個列表名或別名，表示他將一個IK和那個名
字或別名作為一個實體結合使用（IK-per-list），而不是決定到它的目的地的名字或別名。因
此IK必須對列表的所有成員都是可用的。對于非對稱密鑰管理的情況，列表的私有組件必
須的列表的所有成員都是可用的。另一種是憑借遠端爆增站點發送消息的一般的情況，此時
到這樣的列表的發送者可以不認識個別的接收者。不幸的是，它暴露了共享的IK，使它的
更新變得困難。此外，IK-per-list方法的使用允許列表的IK的任何擁有者可以偽裝成其他的
為了鑒別的目的到這個列表發送者。
與此相對，如果一個消息的發送者可以將目的郵件列表擴展為自己的組成部分并選擇
這么做（IK-per-recipient），消息的DEK（和，在對稱密鑰管理的情況下，MIC）將用每個
接收者的IK加密并且這些被加密的表述將被合并到被傳送的消息中。注意每個接收者的加
密只要求在“X-Key-Info：”中攜帶相對小的DEK和MIC，不像加密消息文本時一般要求更
大。盡管更多的IK在IK-per-recipient方法中被處理，一對IK能被個別調用而且只擁有一
個IK并不能使另一個列表上的使用者成功的進行偽裝。
4.6 被封裝的頭域小結
這部分總結了在保密增強處理的過程中被添加到消息中的被封裝的頭域的語法和語義。
這些頭域分三組出現。正常的，一組將按順序出現在被封裝的頭域，盡管在每一組里不是所
有的域都會出現在所有的消息中。在某些特定情況下，這些域被復制到被封裝的消息文本中
也被包括到被封裝的頭中。圖2和3是被封裝的消息的小例子。圖2假設使用對稱的密鑰管
理。圖3假設說明了使用非對稱的密鑰管理的被封裝的消息的示例。
如果沒有其他的特殊的規定，所有的域參數以一種區分大小寫的風格處理。在大多數情
況下，數字量以連續的十六進制數出現在頭域中，每個數字通過從“0”到“9”或大寫的“A”
到“F”的字符來表示。因此公鑰證書和使用非對稱算法加密的量尺寸比較大，一個更節省
空間的編碼技術的使用對這樣的量是合適的，而且定義在本文檔4.3.2.4節的用可打印的字
符表示6位的編碼機制被采用。在圖3中顯示的例子顯示的被加密的非對稱量（例如，
“X-Mic-Info：”，“X-Key-Info：”）用64個可打印的字符表示，對應384位。帶有非對稱加
密量的域也說明了定義在RFC822中的3.1.1節的折疊的使用。
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
   X-Proc-Type: 3,ENCRYPTED
   X-DEK-Info: DES-CBC,F8143EDE5960C597
   X-Sender-ID: linn@ccy.bbn.com::
   X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:3
   X-Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,B70665BB9BF7CBCD,
    A60195DB94F727D3
   X-Recipient-ID: privacy-tf@venera.isi.edu:ptf-kmc:4
   X-Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,E2EF532C65CBCFF7,
    9F83A2658132DB47
 
   LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
   8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
   J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
   dXd/H5LMDWnonNvPCwQUHt==
   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
 
 
               Example Encapsulated Message (Symmetric Case)
                                 Figure 2
 
 
   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
   X-Proc-Type: 3,ENCRYPTED
   X-DEK-Info: DES-CBC,F8143EDE5960C597
   X-Sender-ID: linn@ccy.bbn.com::
   X-Certificate:
    jHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIk
    YbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUz
    agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bATMtPjCUWbz8Lr9wloXIkYbkNpk0
   X-Issuer-Certificate:
    TMtPjCUWbz8Lr9wloXIkYbkNpk0agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bA
    IkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloX
    vXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLp
   X-MIC-Info: RSA-MD2,RSA,
    5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpotJ6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz
   X-Recipient-ID: linn@ccy.bbn.com:RSADSI:3
   X-Key-Info: RSA,
    lBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHU
   X-Recipient-ID: privacy-tf@venera.isi.edu:RSADSI:4
   X-Key-Info: RSA,
    NcUk2jHEUSoH1nvNSIWL9MLLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72oh
    LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
    8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
    J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
    dXd/H5LMDWnonNvPCwQUHt==
   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
              Example Encapsulated Message (Asymmetric Case)
                                 Figure 3
盡管被封裝的頭域類似RFC-822的頭域，他們之間并沒有交集而且不是使用同樣的處
理密封頭域的分析器。對被封裝頭域字典分析的復雜度明顯比RFC-822頭域的分析復雜度
要小。例如，許多對于在依據造句法的級別的RFC-822有特殊意義的字符在被封裝的頭域
中沒有這種特殊的意義。
    當被封裝的頭域的長度比一行可打印的字符長度要長時，在RFC-822 3.1.1節中可以用
空格折疊這個域。任何這樣空格的加入不會被解釋為這一子集的一部分。作為一個特殊的例
子，由于公鑰證書和使用非對稱算法加密的量的長度，這些量經常需要被折疊成幾行。為了
以統一的方式使用這種折疊，這樣一個量的位表示按順序（最左邊的位置先出現）被劃分0
或多于384位的組（對應64位可打印的字符的表示），最后一組可以是小于384位的任意的
長度。
4.6.1 每個消息被封裝的頭域
    這組被封裝的頭域包含在一個保密增強消息中出現不止一次的域，一般先于所有其他的
被封裝的頭域。
4.6.1.1 X-Proc-Type域
“X-Proc-Type：”被封裝的頭域，是所有的保密增強消息都必須具有的，標識對被傳送
的消息進行的處理類型。在一個消息中該域只出現一次；“X-Proc-Type：”域必須在第一個
出現在被封裝的消息頭中。
“X-Proc-Type：”域必須有兩個子域，被一個逗號分隔。第一個子域是一個十進制數用
于區別不兼容的被封裝的頭域說明可能會在以后對這個標準進行修改后出現。按照本文檔消
息處理將帶有子域值3用于與以前的RFCs 989和1040相區別。
第二個子域可以假設為兩個字符串值中的一個：“ENCRYPTED”或“MIC-ONLY”。如