Я столкнулся с проблемой отображения вложений у клиента, который недавно переключился с Exchange 2003 на Exchange 2010. Первоначально эта проблема рассматривалась как затрагивающая только почтовые клиенты Mac OS X (Outlook 2011 и Mac OS Mail) и клиенты iOS.
После устранения неполадок я обнаружил, что веб-почта GoDaddy также страдает от той же проблемы. Вложение отображается как двоичный код, а не вложение.
Рассматриваемые вложения отправляются с сервера SAP в виде файлов .xls, содержащих базовый код HTML. Вложения правильно декодируются на клиентах Windows, хотя они выдают ошибку о том, что содержимое вложения не соответствует расширению, которое нужно было переопределить, чтобы вложения вообще прошли. Первоначально проблема заключалась в том, что новый сервер Exchange 2010 удалял содержимое вложения по соображениям безопасности из-за этой ошибки.
Вложения имеют кодировку в следующем формате:
begin 664 Filename.xls
[бинарный код]
конец
Я просто хочу знать, в чем причина того, что они неправильно декодируются на клиентах и интерфейсах веб-почты недавнего выпуска ... Это просто потому, что кодировка настолько древняя, что большинство платформ отказались от ее поддержки, или возможно, что существует другая проблема?
Я пытаюсь помочь отправителю решить эту проблему, поскольку он в затруднении и ежедневно отправляет своим клиентам тонны этих автоматических рассылок.
Моя рекомендация заключалась в том, чтобы закодировать вложения в соответствии с текущими стандартами MIME и указать их на спецификацию. http://tools.ietf.org/html/rfc2045
Если кто-то еще эксперт по этому поводу хочет научить меня, не упускаю ли я чего-то здесь, пожалуйста, дайте мне знать, если я иду в неправильном направлении.
Спасибо,
M
--- отправлено в ответ на запрос заголовков сообщений - не вписывается в комментарий ---
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: <201205050930.q459UiC0003584@sapapp2.us.[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
(Вероятно, это должен быть комментарий, но я хотел немного больше форматирования ...)
Во-первых, когда вы говорите «двоичный код», вы видите что-то вроде этого:
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
Если он правильно закодирован в UU, там будет строка, в которой предпоследней строкой будет только "" (перед "конечной" строкой), и каждая строка данных начинается с M, за исключением той, которая находится перед "" ".
Если фактическое кодирование UU правильно, следующее, на что нужно обратить внимание, - не перепутались ли заголовки. Сервер SAP, создающий сообщения, может делать что-то странное при создании сообщения. Можете ли вы опубликовать полные заголовки образца сообщения?
Изменить: после просмотра опубликованных заголовков это не сообщение MIME - нет заголовка MIME-версии, нет строк типа содержимого ... Наличие только файла UUencoded в качестве тела сообщения - это воспоминание о днях до MIME , и хотя существует множество утилит, которые могут UU-декодировать файлы, это не очень хорошее решение. Как вы уже отметили, сервер SAP действительно нужно настроить для отправки сообщений MIME.
Так выглядит образец правильно закодированного сообщения. Не все здесь уместно, но пример правильных заголовков для рассматриваемого файла должен появиться в образце ниже. Обратите внимание на заголовки 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 <0M3K00ABRPMXDOK0@ms01064.mac.com> 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 <0M3K006BVPMXKR30@nk11p00mm-smtpin128.mac.com> 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--
UUENCODE - это старый формат для отправки двоичных данных в электронных письмах. Это программа для Unix, которая преобразует двоичный файл в текст, который отправитель может вставить в свое электронное письмо. Получатель сохранил содержимое полученного электронного письма в файл, а затем UUDECODED его, чтобы увидеть исходные данные; некоторые клиенты делали это автоматически.
В наши дни UUENCODE был вытеснен MIME. Лучший ответ - заменить вложение UUENCODED вложением в кодировке MIME. Если это не вариант, то вы зависите от своего почтового клиента. Хотя ни один современный почтовый клиент не будет использовать UUENCODE для отправки вложения, некоторые по-прежнему будут автоматически обнаруживать и декодировать данные UUENCODED; другие не будут. В ходе моего тестирования сегодня утром я обнаружил, что Outlook 2010, Gmail и Thunderbird обнаруживают и декодируют его, а Mail от Apple и IOS - нет. Ваш пробег может отличаться.
Я просто хочу знать, в чем причина того, что они неправильно декодируются в интерфейсах клиентов и веб-почты недавнего выпуска.
Вы работаете с техникой 20-летней давности, а некоторые клиенты ее не поддерживают. Иди разберись.
Моя рекомендация заключалась в том, чтобы закодировать вложения в соответствии с текущими стандартами MIME.
Это абсолютно правильная рекомендация. Если вы это сделаете, вы получите универсальную поддержку. Удачи.