特例：Outlook / Live Mail 之非戰之罪：附件打不開

最近碰上個棘手的情況，就是 pdf / xls / doc / rar 等附件寄到對方信箱，但對方開不了，檢查原始信件 (.eml) 發現一個問題，就是信件內容少了一行 MIME Header base64 的描述，造成附件未依 base64 解碼，懂得人可以手動把這行加到 .eml 內，再開啟就正常了。

 

先用一封測試郵件比對差異性：

正常版 (gMail, ms5.hinet.net)	問題信箱
X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Content-Length: 15931 Status:     這是 MIME 格式的 Multipart 郵件。   ——=_NextPart_000_0011_01CAFC16.6AEEDEC0 Content-Type: multipart/alternative;                 boundary="—-=_NextPart_001_0012_01CAFC16.6AEEDEC0"	X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Spam-Status: No, score=-1.7 X-Spam-Score: -16 X-Spam-Bar: - X-Spam-Flag: NO   3o,O MIME .f&!*: Multipart 6l%s!C   ——=_NextPart_000_001B_01CAFC1E.5C879BD0 Content-Type: multipart/alternative;                 boundary="—-=_NextPart_001_001C_01CAFC1E.5C87C2E0"
——=_NextPart_000_0011_01CAFC16.6AEEDEC0 Content-Type: application/pdf;                 name="=?utf-8?Q?testpdf.txt_-_=E8=A8=98=E4=BA=8B=E6=9C=AC.pdf?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment;                 filename="=?utf-8?Q?testpdf.txt_-_=E8=A8=98=E4=BA=8B=E6=9C=AC.pdf?="	——=_NextPart_000_001B_01CAFC1E.5C879BD0 Content-Type: application/pdf;                 name="=?utf-8?Q?testpdf.txt_-_=E8=A8=98=E4=BA=8B=E6=9C=AC.pdf?=" Content-Disposition: attachment;                 filename="=?utf-8?Q?testpdf.txt_-_=E8=A8=98=E4=BA=8B=E6=9C=AC.pdf?="

 

第一段藍色的差異並不會影響郵件的閱讀，可以忽略，第二段紅色的差異，漏了這行，附件就無法讀取。

所以人工編輯 .eml 就是把這行：

Content-Transfer-Encoding: base64

加到 MIME Header 區即可。

 

目前測試會有此情形的，是一家很大的美商主機商 BlueHost，可以看本文的介紹，測試會出問題的 SMTP 版權畫面如下：

問題信箱的主機

C:> telnet 對方domainName 25 220-box276.bluehost.com ESMTP Exim 4.69 #1 Tue, 25 May 2010 01:40:14 -0600 220-We do not authorize the use of this system to transport unsolicited, 220 and/or bulk e-mail. quit 221 box276.bluehost.com closing connection     遺失與主機的連線。

 

經過交叉比對，會出問題的條件還要是 HiNet 的客戶，下表是 3 個伺服器互寄：

	收件信箱	gMail	ms5.hinet.net	問題信箱
寄信伺服器
msa.hinet.net		正常	正常	異常
問題信箱		正常	正常	正常
gMail		正常	正常	正常

 

目前會出現此問題的已經確認的有：Outlook 2007 / Windows Live Mail 14.0 ，可能其他軟體也有此情況，因為我用 Windows Network Monitor 來看寄信時的封包，寄件封包是包含 base64 的編碼的，所以我懷疑是寄件伺服器跟收件伺服器透過 SMTP 溝通時，才發生的錯誤。

 

Outlook 2010 倒是沒事，不知道是不是因為 MIME 編碼說明字串用英文，所以沒事…

Outlook 2010 Mail Header

X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acr74iw2m2FBEkcVSOCbZCydLN6kSA== Content-Language: zh-tw X-Spam-Status: No, score=-2.6 X-Spam-Score: -25 X-Spam-Bar: – X-Spam-Flag: NO   This is a multipart message in MIME format.   ——=_NextPart_000_0020_01CAFC25.410449B0 Content-Type: multipart/alternative;  boundary="—-=_NextPart_001_0021_01CAFC25.410449B0"

 

想要知道自己是不是這個狀況的受害者，如果是 Office 文件，開起來可能會變成一堆英數字，其他檔案類型通常只會告訴你不能開，你可以將附件存起來後，用記事本開，看看是否是純英數字，大概是每 76 字元換行，若與此狀況相符，恭喜你，中獎了。

 

可以的話，麻煩你分享一下你的寄件伺服器、信箱、郵件軟體產品名與版本。

 

[18:03 補]

OutlookExpress 6.0 也沒事，不OE6 MIME 編碼說明字串也用英文…

Outlook Express 6.0 Mail Header

X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Disposition-Notification-To: <call.wu@msa.hinet.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Spam-Status: No, score=-1.7 X-Spam-Score: -16 X-Spam-Bar: - X-Spam-Flag: NO   This is a multi-part message in MIME format.   ——=_NextPart_000_02F9_01CAFC26.821966A0 Content-Type: multipart/alternative;  boundary="—-=_NextPart_001_02FA_01CAFC26.821966A0"

 

我現在開始懷疑，這串中文字串是不是在美國某些機器會短路了~

 

[22:20 再補]

用 Windows Live Mail 最新版 14.0.8117.416 分別用純文字檔、HTML 再測一次，我發覺應該是這家 SMTP Server 安裝的防廣告過濾器的問題，-25 都可以把附件正確發過去，但是 -17 則不行：

Windows Live Mail 純文字郵件附件可讀 Mail Header

X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Spam-Status: No, score=-2.6 X-Spam-Score: -25 X-Spam-Bar: – X-Spam-Flag: NO   3o,O MIME .f&!*: Multipart 6l%s!C   ——=_NextPart_000_000A_01CAFC56.FF36D110 Content-Type: text/plain;  format=flowed;  charset="utf-8";  reply-type=original Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by msr12.hinet.net id WAA11428

 

Windows Live Mail HTML郵件附件不可讀 Mail Header

X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Spam-Status: No, score=-1.7 X-Spam-Score: -16 X-Spam-Bar: - X-Spam-Flag: NO   3o,O MIME .f&!*: Multipart 6l%s!C   ——=_NextPart_000_0009_01CAFC58.3B1A2050 Content-Type: multipart/alternative;  boundary="—-=_NextPart_001_000A_01CAFC58.3B1A2050"

 

現在過濾出可能被誤判需同時滿足的條件是：

1. msa.hinet.net 寄給 BlueHost  

2. 多媒體郵件，第一行為：「這是 MIME 格式的 Multipart 郵件。」

3. MIME 郵件內文 (Mail Body) 第一部分不為 text/plain ，我猜 html/plain 應該也可以，因為 HTML 郵件為 multipart/alternative 。

 

[5/26 16:25 再補]

我們家的信箱提供業者回復他們的主機不是 BlueHost ，可能是我昨天再測多個有相同問題的廠商，開太多命令提示字元搞錯了，所以上面那個 BlueHost 應該是廠商的 SMTP Server 。

我們家的是亞太線上，使用 SpamAssassin(TM) Spam Filter 濾信，有可能是這個濾信規則的問題。

我 Google 到這個規則，不確定是不是這條規則：

[enabled],"Base 64 Encoded Body","Base 64 Encoded",16711680,AND,Delete,Body,contains,"Content-Transfer-Encoding: base64",Body,doesn’tContain,"Content-Type: image/",Body,doesn’tContainRE,"^Content-Disposition: (inline|attachment);",Body,contains,"Content-Type: text/plain"