安徽快三开奖结果今天开奖号
首頁 | 郵件資訊 | 技術教程 | 解決方案 | 產品評測 | 郵件人才 | 郵件博客 | 郵件系統論壇 | 軟件下載 | 郵件周刊 | 熱點專題 | 工具
網絡技術 | 操作系統 | 郵件系統 | 客戶端 | 電子郵箱 | 反垃圾郵件 | 郵件安全 | 郵件營銷 | 移動電郵 | 郵件軟件下載 | 電子書下載

網絡技術

郵件原理 | 硬件設備 | CISCO | 網絡協議 | 網絡管理 | 傳輸介質 | 線路接入 | 路由接口 | 郵件存儲 | 華為3Com |
首頁 > 網絡技術 > 電子郵件原理及協議 > UTF-7 郵件安全的 Unicode 轉換編碼 > 正文

UTF-7 郵件安全的 Unicode 轉換編碼

出處:VC知識庫 作者:VC知識庫 時間:2006-5-4 13:41:00

本備忘錄狀態:

本文為因特網社區提供信息。本文沒有指定任何因特網標準。分發本文不受限制。

摘要

Unicode標準,2.0版本, 以及ISO/IEC 10646-1聯合定義了一種字符集,它包含了世界上大多數可書寫的字符系統。(后文都直接用Unicode一詞)。

事實上,因特網郵件(STD 11, RFC 822)目前所支持的僅僅是7-bit的ASCII字符集。MIME(RFC 2045到2049)擴展了網絡郵件以支持不同的媒體類型和字符集,也因此能夠在郵件信息里支持Unicode了。雖然它確實提供了隨著時間而增加的字符集注冊的方法,但MIME既沒有把Unicode定義為容許的字符集,也沒有說明它要怎么編碼。

本文檔描述了一種Unicode的轉換編碼,它只使用7-bit的ASCII字節,并且意圖在文件由US-ASCII表中字符組成的限定條件下,對人來說是易讀的。還說明了在MIME的內容中怎么使用這種轉換編碼(RFC 1641“在MIME中使用 Unicode”)。

起因

雖然存在著其他的Unicode轉換格式,并且也足以在這樣的環境下使用(最明顯的就是UTF-8,還有UTF-2 or UTF-FSS),但他們都有一個缺點,就是他們使用了128-255這一范圍對Unicode編碼,超過了US-ASCII的范圍。因此,在郵件環境中,8位字節必須要被編碼。這要求讓文本經歷兩次連續的編碼,讓US-ASCII范圍以外的字符有一個顯著的擴展,這使得非英文的使用者處于非常不利的地步。例如,使用UTF-8和MIME中的Quoted-Printable內容編碼方式一起處理,讓US-ASCII字符出現在一個字節里,但其 它的字符可能需要9個字節。

概述

UTF-7把Unicode字符編碼為US-ASCII的字節,并且用替換序列編碼超出范圍(0-127)的字符。為了這個目的,US-ASCII 表里的一個字符就要保留作為替換字符使用。大多郵件網關和系統不能處理完整的US-ASCII字符集(例如那些基于EBCDIC的),所以UTF-7包含了在US-ASCII用于編碼的預留,以便所有的郵件系統都能兼容。UTF-7應該一般用在7-bit傳輸的環境中,比如郵件。其他的環境中Unicode或者UTF-8還是

首選的。參見RFC 1641,“在MIME中使用Unicode”整體描述了在MIME中Unicode轉換編碼的使用。

定義

首先,定義Unicode:

16-bit字符集,Unicode,由"Unicode標準,2.0版本"所定義。這套字符集與國際標準組織的編碼ISO/IEC 10646-1一致。 編碼后形式為UCS-2;子集為300;實現等級為3,包含對10646+的前7個修正。

注:Unicode 2.0 還進一步說明了這些字符在ISO標準組織以外的使用和交互。事實上,一個有效的10646序列就是一個有效的Unicode序列,反之也是;Unicode 協會提供對序列的解析,而ISO標準組織卻一直沒有。

然后,定義一些US-ASCII字符子集:

集合D:(直接字符)包含如下的字符(取自RFC 1521,附錄B,在RFC 2045中不再出現了):

大寫字母A-Z,小寫字母a-z,和10個數字0-9,和后面的9個特殊字符(注意:"+"和"-"遺漏了)

字符     ASCII & Unicode值 (十進制)
                  ''           39
                  (           40
                  )           41
                  ,           44
                  -           45
                  .           46
                  /           47
                  :           58
                  ?           63

集合O: (可選的直接字符) 包含如下的字符: (注意 "\" 和 "~" 遺漏了):

字符     ASCII & Unicode值 (十進制)
                  !           33
                  "           34
                  #           35
                  $           36
                  %           37
                  &           38
                  *           42
                  ;           59
                  <           60
                  =           61
                  >           62
                  @           64
                  [           91
                  ]           93
                  ^           94
                  _           95
                  ''           96
                  {           123
                  |           124
                  }           125

基本原理:有兩個字符 "\" 和 "~" 被遺漏了是因為在ASCII表中他們經常被重新定義變量值。

集合B: (更改過的Base64) (RFC 2045)定義的Base64字母表中的字符,除了襯墊字符:"=" (十進制值為 61)。

基本原理: 襯墊字符 "=" 被排除了是因為UTF-7被設計用來在報頭字段中使用,就如RFC 2047中的集合4。 因為RFC 2047編碼中唯一易讀的編碼就是"Q",(基于RFC 2045''s Quoted Printable),所以"="不適合使用(沒有很多的轉義序列)。這很不幸,但是卻不可避免。其實,"=" 字符在UTF-7中也可以作為轉義字符使用,如果不是使用"+"。

注:所有US-ASCII在Unicode中都是用同樣的值,補0擴展到16 bits。

UTF-7 定義

一個UTF-7流用如下方式使用7-bit US-ASCII字節表示16-bit Unicode字符:

  • 規則1:(直接編碼) 上面的集合D中的Unicode字符可以直接的編碼為ASCII的等價物。集合O中的字符可以有隨意的直接編碼為ASCII的等價物,但要記得其中的很多的字符在報頭字段是不合法的,或者不能正確的穿過郵件網關;
  • 規則2:(Unicode替換編碼) 通過在前面加上轉換字符"+"(US-ASCII字符十進制值為43),任何一個Unicode序列都可以使用集合B中的字符編碼。"+"意味著后面的字節將被作為更改過的BASE64字母表中的元素解析,直到遇到一個不是字母表中的字符為止。這些字符中包含控制字符,比如回車和換行;因此,一個Unicode轉換序列總是在一行上結束。作為一個特殊的情形,如果序列結束于一個"-"字符(US-ASCII值45),那么那個字符就要被關注;其他的結束字符不用關心,而且可以正常處理;
  • 注意:如果跟在轉換字符后的第一個字符就是"-",那么一個多余的必須被加上,以便結束轉換序列,所以真正的"-"不是它關心的;
  • 基本原理:一個結束字符在如下的情形是必須的:在更改的base64序列的下一個字符是集合B中的部分,或者本身就是一個結束字符。通過界定編碼的序列也可以增強可讀性。作為特定情形,序列"+-"可以用來編碼字符"+"。一個"+"字符之后立即跟著的字符若不是集合B的成員或者"-",就是一個形式有誤的序列;

對Unicode使用更改的base64編碼時候,可以首先轉換Unicode的16bit的數量值為一個字節流。通過把成對中的一個當作單獨的值以后,就會轉換為字節對。奇數個字節的的文本是錯誤的形式,ISO1646 字符超過可設定地址范圍的部分轉換為字節對后也無法編碼。

  • 基本原理:ISO/IEC 10646-1:1993(E)說明了當UCS2形式被字節流序列化時,哪個字節在前面。選定一種用來發送的規范格式,在一般網絡應用中也是遵循的;
  • 基本原理:ISO 10646和Unicode標準中代碼點定位的策略是一個同步一致的字

    符表。如果字節對超過了ISO10646可尋址范圍,就無法對代碼點定

    位了。

然后,對字節流進行編碼時使用了"更改的base64編碼"算法(定義于RFC 2045),更改中去掉了襯墊字符"="。在編碼時候,增加了代替的"0 bits"以便襯墊base64編碼字符的邊界。在解碼時,在"更改的base64編碼"序列最后的一些bits,如果不能組成一個完整的 16-bit的Unicode字符,那么就會被丟棄。如果丟棄的bits不是0,那么這個編碼序列就是有格式錯誤的。

  • 基本原理:在對更改的 Base64 進行編碼時,不使用襯墊字符"=",因為就象上文提及的,它與在 RFC 2047 中將它用做 "Q 內容傳輸編碼" 的轉義字符相沖突;
  • 規則3: 空格 (十進制 32),tab (十進制 9),回車(十進制 13),和換行(十進制 10)字符可以直接使用ASCII等價字符表示。事實上,應該注意到MIME傳輸編碼也有使用這些字符的規則。如果使用并不遵循RFC 822的限制,必須要使用MIME編碼而不是7bit或者8bit的一些編碼,比如quoted-printable,binary,或者base64。

鑒于給定的一組規則,Unicode字符可以經由規則1或者規則3編碼,一個字符占用一字節;然后其他的Unicode字符用規則2編碼,一個字符占用平均(2 + 2/3)個字節,加上一個轉換開關字節用來進入"更改的base64編碼",加一個可選的轉換跳出字節。

例如:Unicode序列 "A<NOT IDENTICAL TO><ALPHA>." (十進制: 0041,2262,0391,002E) 可以被編碼如下:

A+ImIDkQ.

例如:Unicode序列 "Hi Mom -<WHITE SMILING FACE>-!" (十進制: 0048, 0069, 0020, 004D, 006F, 006D, 0020, 002D, 263A,002D, 0021) 可以被編碼如下:

Hi Mom -+Jjo--!

例如:Unicode序列 用漢語表示日文 "nihongo" (十進制: 65E5,672C,8A9E) 可以被編碼如下:

+ZeVnLIqe-

在MIME中使用UTF-7字符集

UTF-7字符集對郵件傳輸是安全的,因此可以應用于MIME中任何內容的編碼(除非出現了對行長度和行中斷的強制約束)。特定的,7-bit的編碼用于主體, "Q內容編碼"用于報頭的情況也可以使用。MIME字符集的標簽是UTF-7,這一點對大于等于2.0版本的Unicode很重要。

例子:這是一個MIME消息的片段,包含了一段Unicode序列:

"Hi Mom <WHITE SMILING FACE>!" (十進制 0048,0069, 0020, 004D, 006F, 006D, 0020, 263A, 0021)。Content-Type: text/plain; charset=UTF-7 Hi Mom +Jjo-!

例子:這是一個MIME消息的片段,包含了一段用漢語表示日語詞 "nihongo" 的 Unicode 序列:

(十進制: 65E5, 672C, 8A9E)。Content-Type: text/plain; charset=UTF-7 +ZeVnLIqe-

例子: 這是一個MIME消息的片段 ,包含了一段Unicode序列:

"A<NOT IDENTICAL TO><ALPHA>." (十進制: 0041, 2262, 0391, 002E)Content-Type: text/plain; charset=utf-7 A+ImIDkQ.

例子: 這是一個MIME消息的片段,包含了一段Unicode序列:

"Item 3 is <POUND SIGN>1." (十進制 0049, 0074, 0065, 006D, 0020, 0033, 0020, 0069, 0073, 0020, 00A3, 0031, 002E)。Content-Type: text/plain; charset=UTF-7 Item 3 is +AKM-1.

注意:為了和"可能不支持Unicode與MIME的系統"達到最好的互用性,在準備郵件傳輸正文的時候,"行中斷"應該遵守網絡慣例。這意味著行應該很短而且要使用SMTP的CRLF來標記結束。Unicode的行分隔符(十進制 2028)和段分隔符 (十進制 2029)應該被替換為SMTP的行中斷。理想的情況,這應該由一個理解 Unicode的用戶代理透明的處理。

這樣的準備也不是絕對必要的,因為UTF-7和適當的MIME編碼可以在不遵守網絡慣例的情況下處理正文,但是對于沒有Unicode或者MIME的系統的可讀性就會被削弱了。關于郵件協同工作能力問題的討論可以參見 RFC 2045。

在UTF-7轉換序列中行是不可以被打斷的,因為這樣的序列不可以跨越行中斷。因此,UTF-7編碼可以放在行中斷后面。如果一行含有轉換后會很長的序列,可以使用MIME中的編碼來處理正文,比如 Quoted Printable。另一個可行性就是同時執行行中斷和UTF-7編碼,這樣包含轉換序列的行就已經符合長度限制了。

討論

在本節中,我們將引入UTF-7編碼,它反對選擇現有的Unicode轉換編碼(例如UTF-8)和MIME編碼一起使用。在討論之前,有必要先列舉一些假設,這些假設有關于典型自然語言文本串中字符出現的頻率,而這些頻率可以用來評估典型存儲的需求:

  1. 多數西歐語言使用大概7/8的US-ASCII字符和1/8的打丁字符(ISO-8859-1);
  2. 多數基于非羅馬字母表的語言(比如希臘)使用大約1/6的ASCII字符(因為空格 也算是7bit的),其他的來源于他他們自己的字母表;
  3. 東亞基于表意字表的語言(包括日文)基本使用他們自己的字符表,Han或者CJK;
  4. 非直接編碼的標點字符的出現次數不足以影響結果;

    注意:當前的8bit標準,比如ISO-8859-x,要求使用內容傳輸編碼。為了和后續的討論對比,把代價列舉如下,(注意:很多其中的數字只是接近的,因為他們依賴文本確切的組成形式):

Base64中的8859-x 文本類型 平均字節數/字符 所有 1.33 Quoted Printable中的8859-x 文本類型 平均字節數/字符 US-ASCII 1 西歐 1.25 其他 2.67

注意:使用base64編碼的Unicode平均一個字符占用了2.67個字節。為了對比,我們看一下UTF-8和UTF-7在Base64和Quoted中的情況。還要指出的是:一個較長的字符串有固定的經常性開銷,大約為 1/n,n是指編碼后字節串的長度。

UTF-8在 Base64中 文本類型 平均字節數/字符 US-ASCII 1.33 西歐 1.5 一些字母表的 2.44 其他 4 UTF-8在Quoted Printable中 文本類型 平均字節數/字符 US-ASCII 1 西歐 1.63 一些字母表的 5.17 其他 7-9 UTF-7 文本類型 平均字節數/字符 多數 US-ASCII 1 西歐 1.5 其他 2.67+2/n

我們會發現UTF-8在Quoted Printable選項中是不可行的,因為在文本中有太多的除了西歐語言外的其他的語言。當只有當文本中大多是ASCII或者拉丁數字字符,偶爾有其他的字符散布的時候,這樣編碼才是可行的。我們將首選介紹一種編碼能很好的適用于所有用戶。我們還會發現UTF-8與base64編碼的使用者中,有大量的非西歐用戶。即便是里面有很多的ASCII字符,因為沒有很好的可讀性,這樣的編碼也不是十分適用。基于UTF-7的編碼可以給出很好的結果,并且對ASCII文本有很好的可讀性。

UTF-7 給出的結果挑戰了ISO-8859-x,而且適用于所有的Unicode字符。我想,這證明了引入一種新的Unicode轉換編碼是正確。

UTF-7作為一種可選的方案,但是,因為multipart/mixed內容類型忽略了行中斷的問題,也可能在使用現有的MIME機制的時候會和其他的Unicode字符集產生混亂。(感謝Nathaniel Borenstein提了這個建議),例如:(重新說一下前面的例子)

Content-type: multipart/mixed; boundary=foo Content-Disposition: inline --foo Content-type: text/plain; charset=us-ascii Hi Mom --foo Content-type: text/plain; charset=UNICODE-2-0 Content-transfer-encoding: base64 Jjo= --foo Content-type: text/plain; charset=us-ascii ! --foo--

理論上,這里去掉了在消息體里對UTF-7的需求。(多部分類型不可以在報頭字段里使用)事實上,我們發現使用Unicode字符集變得更為廣泛了,間斷使用一些特殊的Unicode字符(例如錢和數學符號)的情況會出現,并且文本里還會包含很多小塊的其他的語句,比如西里爾的,希臘的和東亞的語言。(羅馬的文字都已經能被MIME字符集充分處理了)雖然多部分技術對于大塊用于交互的文本來說工作的很好,我們還是覺得它不能充分的支持剛剛討論的應用類型,所以我們認為引入UTF-7是合理的。

總結

UTF-7編碼方式使得Unicode字符集能在US-ASCII的7-bit范圍中編碼。對于一些Unicode序列,如果含有相對較長的US-ASCII字符串,中間夾雜了單個的Unicode字符或者Unicode串,這種編碼是高效的。因為它容許沒有Unicode支持的系統直接閱讀US-ASCII的部分。UTF-7僅僅應該用在7-bit傳輸的時候,比如郵件。在其他的環境下,Unicode 或者UTF-8應該是首選的。

致謝

對如下人的貢獻,評論和建議表示感謝,如果因為疏忽而遺漏了某一位,也不是故意的!

Glenn Adams Harald T. Alvestrand Nathaniel Borenstein Lee Collins Jim Conklin Dave Crocker Steve Dorner Dana S. Emery Ned Freed Kari E. Hurtta John H. Jenkins John C. Klensin Valdis Kletnieks Keith Moore Masataka Ohta Einar Stefferud Erik M. van der Poel

附錄 A —— 例子:

這里有個更大的例子,是從一個BIG5編碼的文檔里拿來的。只是精簡了一些。這里有兩個版本,第一個使用了可選的"O"字符集(這可能會造成不能通過一些郵件網關),第二個沒有。

Content-type: text/plain; charset=utf-7

下面就是全都是中文的一端節選 (+itaKng-)。原文是這樣的:

"The sayings of Confucius," James R. Ware, trans. +U/BTFw-:+ZYeB9FH6ckh5Pg-, 1980. (中文文本做了英文轉換)+Vttm+E6UfZM-, +W4tRQ066bOg-, +UxdOrA-: +Ti1XC2b4Xpc-, 1990."The Chinese Classics with a Translation, Critical and ExegeticalNotes, Prolegomena, and Copius Indexes," James Legge, trans., Taipei:Southern Materials Center Publishing, Inc., 1991.

(中文文本做了英文翻譯)分別做了個BIG5和GB兩個版本:

本文中沒有包含BIG5或者GB的所有字符。缺失的字符已經使用它們的Unicode/ISO代碼點指示出來了。"U+-" 后面跟著四個十六進制指定一個Unicode/10646代碼(例如:U+-9F08)。這對小規模的BIG5和GB使用的問題,不是一個好的解決方案;但是這種解決方案的表現,對我個人而言是很滿意的。

(缺失了…)+XrdxmVtXUXg-(缺失了…)John H. Jenkins +TpVPXGBG- [email protected] 5 January 1993(缺失了…)Content-type: text/plain; charset=utf-7

下面就是全都是中文的一端節選(+itaKng-)。原文是這樣的:

+ACI-The sayings of Confucius,+ACI- James R. Ware, trans. +U/BTFw-:+ZYeB9FH6ckh5Pg-, 1980. (中文做了英文轉換)+Vttm+E6UfZM-, +W4tRQ066bOg-, +UxdOrA-: +Ti1XC2b4Xpc-, 1990.+ACI-The Chinese Classics with a Translation, Critical and ExegeticalNotes, Prolegomena, and Copius Indexes,+ACI- James Legge, trans.,Taipei: Southern Materials Center Publishing, Inc., 1991.

(中文文本做了英文轉換)分別做了個BIG5和GB兩個版本:

本文中沒有包含BIG5或者GB的所有字符。缺失的字符已經使用它們的Unicode/ISO代碼點指示出來了。+ACI-U+-+ACI- 后面跟著四個十六進制指定一個Unicode/10646代碼(例如:U+-9F08)。這對小規模的BIG5和GB(+ADs-)使用的問題,不是一個好的解決方案;但是這種解決方案的表現,對我個人而言是很滿意的。

(缺失了…)+XrdxmVtXUXg-(缺失了…)John H. Jenkins +TpVPXGBG- jenkins+AEA-apple.com 5 January 1993(缺失了…)

對安全的考慮

本文沒有討論安全問題

相關文章 熱門文章
  • Javamail處理unicode-1-1-utf-7編碼的郵件
  • Courier Mail Server用戶名編碼拒絕服務漏洞
  • 常用郵件編碼及亂碼的解決
  • IIS如何接收ServerXMLHTTP傳過來的編碼字符?
  • 亂碼大全(19)──日文和韓文的漢字編碼(2)
  • 亂碼大全(18)──日文和韓文的漢字編碼(1)
  • 解決UTF-8編碼VBB3附件下載名亂碼
  • 讓使用UTF-8編碼中文標題不再亂碼
  • E-mail傳送中的三種編碼標準
  • 奇妙的Base64編碼
  • 淺談Base64編碼
  • 解讀郵件原文(二)--郵件編碼介紹
  • 中文RFC文檔目錄
  • 手把手教你玩轉免費頂級域名
  • 淺談Base64編碼
  • 手把手教你如何免費注冊國際頂級域名
  • 電子郵件原理
  • 郵件-域名-DNS相關知識
  • 全面剖析E-mail收發失敗的原因(一)
  • SMTP結構及原理
  • 關于郵件系統域名(DNS)設置的小常識
  • 電子郵件的工作原理
  • 郵件原文詳細介紹(一)--神奇的MIME
  • 發送郵件常見出錯代碼
  • 自由廣告區
     
    最新軟件下載
  • SharePoint Server 2010 部署文檔
  • Exchange 2010 RTM升級至SP1 教程
  • Exchange 2010 OWA下RBAC實現的組功能...
  • Lync Server 2010 Standard Edition 標..
  • Lync Server 2010 Enterprise Edition...
  • Forefront Endpoint Protection 2010 ...
  • Lync Server 2010 Edge 服務器部署文檔
  • 《Exchange 2003專家指南》
  • Mastering Hyper-V Deployment
  • Windows Server 2008 R2 Hyper-V
  • Microsoft Lync Server 2010 Unleashed
  • Windows Server 2008 R2 Unleashed
  • 今日郵件技術文章
  • 騰訊,在創新中演繹互聯網“進化論”
  • 華科人 張小龍 (中國第二代程序員 QQ...
  • 微軟推出新功能 提高Hotmail密碼安全性
  • 快壓技巧分享:秒傳郵件超大附件
  • 不容忽視的郵件營銷數據分析過程中的算..
  • 國內手機郵箱的現狀與未來發展——訪尚..
  • 易觀數據:2011Q2中國手機郵箱市場收入..
  • 穿越時空的愛戀 QQ郵箱音視頻及賀卡郵件
  • Hotmail新功能:“我的朋友可能被黑了”
  • 入侵鄰居網絡發騷擾郵件 美國男子被重..
  • 網易郵箱莫子睿:《非你莫屬》招聘多過..
  • 中國電信推廣189郵箱綠色賬單
  • 最新專題
  • 鳥哥的Linux私房菜之Mail服務器
  • Exchange Server 2010技術專題
  • Windows 7 技術專題
  • Sendmail 郵件系統配置
  • 組建Exchange 2003郵件系統
  • Windows Server 2008 專題
  • ORF 反垃圾郵件系統
  • Exchange Server 2007 專題
  • ISA Server 2006 教程專題
  • Windows Vista 技術專題
  • “黑莓”(BlackBerry)專題
  • Apache James 專題
  • 分類導航
    郵件新聞資訊:
    IT業界 | 郵件服務器 | 郵件趣聞 | 移動電郵
    電子郵箱 | 反垃圾郵件|郵件客戶端|網絡安全
    行業數據 | 郵件人物 | 網站公告 | 行業法規
    網絡技術:
    郵件原理 | 網絡協議 | 網絡管理 | 傳輸介質
    線路接入 | 路由接口 | 郵件存儲 | 華為3Com
    CISCO技術 | 網絡與服務器硬件
    操作系統:
    Windows 9X | Linux&Uinx | Windows NT
    Windows Vista | FreeBSD | 其它操作系統
    郵件服務器:
    程序與開發 | Exchange | Qmail | Postfix
    Sendmail | MDaemon | Domino | Foxmail
    KerioMail | JavaMail | Winwebmail |James
    Merak&VisNetic | CMailServer | WinMail
    金笛郵件系統 | 其它 |
    反垃圾郵件:
    綜述| 客戶端反垃圾郵件|服務器端反垃圾郵件
    郵件客戶端軟件:
    Outlook | Foxmail | DreamMail| KooMail
    The bat | 雷鳥 | Eudora |Becky! |Pegasus
    IncrediMail |其它
    電子郵箱: 個人郵箱 | 企業郵箱 |Gmail
    移動電子郵件:服務器 | 客戶端 | 技術前沿
    郵件網絡安全:
    軟件漏洞 | 安全知識 | 病毒公告 |防火墻
    攻防技術 | 病毒查殺| ISA | 數字簽名
    郵件營銷:
    Email營銷 | 網絡營銷 | 營銷技巧 |營銷案例
    郵件人才:招聘 | 職場 | 培訓 | 指南 | 職場
    解決方案:
    郵件系統|反垃圾郵件 |安全 |移動電郵 |招標
    產品評測:
    郵件系統 |反垃圾郵件 |郵箱 |安全 |客戶端
    廣告聯系 | 合作聯系 | 關于我們 | 聯系我們 | 繁體中文
    版權所有:郵件技術資訊網©2003-2010 www.mpmgk.icu, All Rights Reserved
    www.mpmgk.icu Web Team   粵ICP備05009143號
    安徽快三开奖结果今天开奖号