I have run into a attachment display issue at a client who has recently switched from Exchange 2003 to Exchange 2010. The issue was initially perceived as affecting only Mac OS X email clients (Outlook 2011 and Mac OS Mail) and iOS clients.
After some troubleshooting I discovered that GoDaddy webmail also suffers from the same issue.The attachment displays as binary code instead of an attachment.
The attachments in question are sent from a SAP server as .xls files containing basic html code. The attachments are decoded correctly on Windows clients, although they produce an error about the contents of the attachment not matching the extension, which had to be overridden for the attachments to come through at all. Initially, the issue was that the new Exchange 2010 server was stripping the attachment contents for security reasons because of this error.
The attachments are uuencoded in the following format:
begin 664 Filename.xls
[binary code]
end
I simply want to know what the reason is for these being incorrectly decoded on clients and webmail interfaces of a recent vintage... Is it simply because the encoding is so ancient that most platforms have abandoned support for it or is it possible that there is another problem?
I am trying to assist the sender in fixing this problem as they are at a loss and they send a ton of these automated mailings to their customers every day.
My recommendation to them was going to be to encode the attachments in accordance with the current MIME standards and point them to the spec https://www.rfc-editor.org/rfc/rfc2045
Anyone more expert on this willing to school me on whether I am missing something here, please let me know if I am going in the wrong direction.
Thanks,
M
---posted in response to request for message headers - didn't fit into comment---
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
(This should probably be a comment, but I wanted a bit more formatting...)
First off, when you say "binary code," are you seeing stuff like this:
If it's properly UUencoded, there's a line with just "`" as the second-to-last line (before the "end" line) and every line of data starts with M except for the one before the "`".
If the actual UUencoding is correct, the next thing to look at is whether the headers are messed up. The SAP server that's creating the messages might be doing something strange when it generates the message. Can you post the full headers of a sample message?
Edit: after looking at the posted headers, that's not a MIME message at - there's no MIME-Version header, no Content-type lines... Having just the UUencoded file as the body of the message is a flashback to pre-MIME days, and although there are lots of utilities that can UUdecode the files, that's not a good solution. As you've already commented, the SAP server really needs to be configured to send MIME messages.
This is what a correctly encoded message sample looks like. Not all the stuff in here is pertinent, but an example of correct headers for the file in question should appear within the sample below. Note the content-type, and content-transfer-encoding headers.
UUENCODE is an old format for sending binary data in emails. It's a Unix program that converts binary to text, which the sender can paste into his email. The recipient saved the contents of the resulting email to a file, and then UUDECODED it to see the original data; some clients did this automatically.
These days, UUENCODE has been supplanted by MIME. The best answer is to replace your UUENCODED attachment with a MIME encoded attachment. If that's not an option, then you are at the mercy of your email client. Although no modern email client will use UUENCODE to send an attachment, some will still automatically detect and decode UUENCODED data; others will not. In my test this morning, I found that Outlook 2010, Gmail, and Thunderbird detect and decode it, but Apple's Mail and IOS's Mail do not. Your mileage may vary.
You're working with 20-year old tech and some clients don't support it. Go figure.
That is absolutely the right recommendation. You will get universal support if you do. Good luck.