Uuencoded mail attachments display as binary code

attachmentemail

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

Best Answer

(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:

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

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.

Related Topic