我遇到了一个附件显示问题,客户最近从 Exchange 2003 切换到 Exchange 2010。该问题最初被认为仅影响 Mac OS X 电子邮件客户端(Outlook 2011 和 Mac OS Mail)和 iOS 客户端。
经过一些故障排除后,我发现 GoDaddy 网络邮件也存在同样的问题。附件显示为二进制代码而不是附件。
有问题的附件是从 SAP 服务器发送的,格式为 .xls 文件,其中包含基本的 html 代码。附件在 Windows 客户端上解码正确,但它们会产生一个错误,提示附件内容与扩展名不匹配,必须覆盖该错误才能让附件通过。最初,问题是新的 Exchange 2010 服务器出于安全原因删除了附件内容,这是因为这个错误。
附件采用以下格式进行 uuencoded :
开始 664 文件名.xls
[二进制代码]
结尾
我只是想知道为什么这些在最近的客户端和网络邮件界面上被错误解码...是不是因为编码太古老以至于大多数平台已经放弃了对它的支持,或者是否可能存在其他问题?
我正在尝试协助发件人解决这个问题,因为他们不知所措,而且他们每天向客户发送大量此类自动邮件。
我向他们提出的建议是,根据当前的 MIME 标准对附件进行编码,并让他们参考规范https://www.rfc-editor.org/rfc/rfc2045
有没有哪位专家愿意指导我,告诉我我是否遗漏了什么,如果我走错了方向,请告诉我。
谢谢,
米
--- 响应消息标题请求而发布 - 不适合评论---
Received: (qmail 26660 invoked from network); 5 May 2012 09:30:51 -0000
Received: from unknown (HELO m1pismtp01-024.prod.mesa1.secureserver.net) ([10.8.12.27])
(envelope-sender <[removed]>)
by p3plsmtp05-04.prod.phx3.secureserver.net (qmail-1.03) with SMTP
for <[removed]>; 5 May 2012 09:30:51 -0000
X-IronPort-Anti-Spam-Result: AuACAB/wpE+qq/xekWdsb2JhbABFoSgBjhqDMSIBAQEBCQsLGwMkgi2BLzA/iCC6Top/hT1jBI04WZs0
Received: from rhmailer.rhbss.com ([170.171.252.94])
by m1pismtp01-024.prod.mesa1.secureserver.net with ESMTP; 05 May 2012 02:30:50 -0700
Received: from sapapp2.us.[removed].com (10.104.61.31) by RHMAILER.RHBSS.COM id hkjpke18hq4j for <[removed]>; Sat, 5 May 2012 05:30:45 -0400 (envelope-from <[removed]>)
Received: from sapapp2.us.[removed].com (localhost.localdomain [127.0.0.1])
by sapapp2.us.[removed].com (8.13.8/8.13.8) with ESMTP id q459Umhs003627;
Sat, 5 May 2012 05:30:48 -0400
Received: (from prdadm@localhost)
by sapapp2.us.[removed].com (8.13.8/8.13.8/Submit) id q459UiC0003584;
Sat, 5 May 2012 05:30:44 -0400
Date: Sat, 5 May 2012 05:30:44 -0400
Message-Id: <[email protected].[removed].com>
To: [removed addresses]
From: "SAPPRD" <[removed]>
Subject: [removed]
X-Nonspam: None
Yesterday's Top 20 Orders
begin 664 [removed].xls
M/$A434P^"CQ(14%$/@H\;65T82!H='1P+65Q=6EV/2)#;VYT96YT+51Y<&4B
M(&-O;G1E;G0](G1E>'0O:'1M;#L@8VAA<G-E=#UW:6YD;W=S+3$R-3(B/@H\
[removed confidential content]
M/2)!<FEA;"(^24X\+T9/3E0^/"]41#X*/"]44CX*/"]486)L93X*/"]"3T19
*/@H\+TA434P^"@``
`
end
答案1
(这可能应该是一条评论,但我想要更多的格式......)
首先,当您说“二进制代码”时,您是否看到如下内容:
begin 644 webutils_pl
M4F5C;V=N:7II;F<@9FEL97,@96YC;V1E9"!U<VEN9R!5565N8V]D90T*#0I!
M(&9I;&4@96YC;V1E9"!W:71H(%5596YC;V1E('5S=6%L>2!S=&%R=',@=VET
M:"!A(&AE861E<B!L:6YE(&]F('1H92!F;W)M.@T*#0IB96=I;B`\;6]D93X@
[ deleted a bunch of similar lines ]
M<F]D=6-E<R!A('9A;'5E('=H;W-E(&QO=V5R('-I>"!B:71S(&%R92`P+@T*
M#0HH4V]U<F-E.B!7:6MI<&5D:6$I#0H-"D9O<B!E>&%M<&QE+"!U=65N8V]D
M:6YG('1H:7,@=VAO;&4@<V5C=&EO;B!W;W5L9"!G:79E('1H92!F;VQL;W=I
*;F<@<F5S=6QT.@``
`
end
如果它是正确的 UUencoded,那么就会有一行仅以“`”作为倒数第二行(“结束”行之前),并且除了“`”之前的行以外,每一行数据都以 M 开头。
如果实际的 UUencoding 是正确的,接下来要查看的是标头是否混乱。创建消息的 SAP 服务器在生成消息时可能会做一些奇怪的事情。您可以发布示例消息的完整标头吗?
编辑:查看已发布的标题后,这不是 MIME 消息 - 没有 MIME-Version 标题,没有 Content-type 行... 仅将 UUencoded 文件作为消息正文会让人回想起 MIME 出现之前的时代,尽管有许多实用程序可以对文件进行 UUdecode,但这不是一个好的解决方案。正如您已经评论的那样,SAP 服务器确实需要配置才能发送 MIME 消息。
答案2
这是正确编码的消息示例。此处的内容并非全部相关,但以下示例中应显示相关文件的正确标头示例。请注意 content-type 和 content-transfer-encoding 标头。
Return-path: <[removed]>
Received: from nk11p00mm-smtpin128.mac.com ([17.158.160.110])
by ms01064.mac.com
(Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan
3 2012)) with ESMTP id <[email protected]> for [removed];
Sat, 05 May 2012 23:37:45 +0000 (GMT)
Original-recipient: rfc822;[removed]
Received: from p3plwbeout05-02.prod.phx3.secureserver.net ([97.74.135.47])
by nk11p00mm-smtpin128.mac.com
(Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug
10 2011)) with SMTP id <[email protected]> for
[removed] (ORCPT [removed]); Sat, 05 May 2012 23:37:45 +0000 (GMT)
Received: (qmail 4538 invoked from network); Sat, 05 May 2012 23:37:45 +0000
Received: from unknown (HELO localhost) (97.74.135.118)
by p3plwbeout05-02.prod.phx3.secureserver.net with SMTP; Sat,
05 May 2012 23:37:45 +0000
Received: (qmail 3092 invoked by uid 99); Sat, 05 May 2012 23:37:45 +0000
Content-type: multipart/mixed; boundary="=_9b9e05f8e0418ec345340e8a4ccb0c8f"
X-Originating-IP: 67.243.139.105
User-Agent: Workspace Webmail 5.6.17
Message-id:
<20120505163744.aee46609c082ce5b1463c91da4f31dbb.ba713f24d9.wbe@email05.secureserver.net>
From: [removed]
To: [removed]
Subject: Test SAP
Date: Sat, 05 May 2012 16:37:44 -0700
MIME-version: 1.0
--=_9b9e05f8e0418ec345340e8a4ccb0c8f
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
<html><body><span style=3D"font-family:Verdana; color:#000000; font-size:10=
pt;"><div><br mce_bogus=3D"1"></div></span></body></html>
--=_9b9e05f8e0418ec345340e8a4ccb0c8f
Content-Transfer-Encoding: base64
Content-Type: text/MSEXCEL;
name="Test_File.xls";
Content-Disposition: attachment;
filename="Test_File.xls";
PEhUTUw+CjxIRUFEPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl
eHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTIiPgo8VElUTEU+SU5URVJBQ1RJVkUgVE9QIDIw
ZWwubnVtYmVyZm9ybWF0OkAiPjxGT05UIEZBQ0U9IkFyaWFsIj5JUDwvRk9OVD48L1REPgo8L1RS
Pgo8L1RhYmxlPgo8L0JPRFk+CjwvSFRNTD4K
--=_9b9e05f8e0418ec345340e8a4ccb0c8f--
答案3
UUENCODE 是一种在电子邮件中发送二进制数据的旧格式。它是一个 Unix 程序,可将二进制转换为文本,发件人可将其粘贴到电子邮件中。收件人将生成的电子邮件内容保存到文件中,然后对其进行 UUDECODED 以查看原始数据;有些客户端会自动执行此操作。
如今,UUENCODE 已被 MIME 取代。最好的答案是将您的 UUENCODED 附件替换为 MIME 编码附件。如果这不是一个选择,那么您就只能听天由命了。虽然没有现代电子邮件客户端会使用 UUENCODE 发送附件,但有些仍会自动检测和解码 UUENCODED 数据;其他则不会。在我今天早上的测试中,我发现 Outlook 2010、Gmail 和 Thunderbird 可以检测和解码它,但 Apple 的 Mail 和 IOS 的 Mail 则不会。您的情况可能会有所不同。
我只是想知道为什么这些在最近的客户端和网络邮件界面上被错误解码
你使用的是 20 年前的技术,但有些客户并不支持它。想想看。
我向他们建议按照当前的 MIME 标准对附件进行编码
这绝对是正确的建议。如果你这么做,你会得到普遍的支持。祝你好运。