最近碰上個棘手的情況，就是 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: p_w_upload;

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: p_w_upload;

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: <>
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: p_w_picpath/",Body,doesn’tContainRE,"^Content-Disposition: (inline|p_w_upload);",Body,contains,"Content-Type: text/plain"