特例: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"
廣告
Categories: 技術分享 | 3 則迴響

文章分頁導航

3 thoughts on “特例:Outlook / Live Mail 之非戰之罪:附件打不開

  1. tim

    您說的狀況我也有遇到耶,真怪.只是突然間對方就無法開啟我們記過去的附件.我們家用msa.hinet.net外寄郵件,對方是澳洲的公司.好怪?都沒解決的方法嗎?

    喜歡

  2. TypeRR

    msa.hinet.net 寄到 yahoo.com.tw 也會不太正常的樣子
    把不能開的信件,從 yahoo.com.tw 轉寄到 seed.net.tw 的信箱是能正常開啟的

    喜歡

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s

在WordPress.com寫網誌.

%d 位部落客按了讚: