5

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
Community
  • 1
Manca Weeks
  • 689
  • 3
  • 7
  • 11
  • UUENCODING has not the current spec for including non-textual data in email for what, 10 years? 20? I recommend that you change to MIME instead. You will find universal support for it. – james.garriss Sep 03 '13 at 19:43

3 Answers3

3

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

Ward - Reinstate Monica
  • 12,788
  • 28
  • 44
  • 59
  • I removed confidential info from the message and headers, but all pertinent information should be there - let me know if this is sufficient - see original post, edited, content did not fit into comment... – Manca Weeks May 05 '12 at 16:38
  • to clarify, the attachment has obviously been truncated in the example message above, included the first an last lines of the attachment content as it appears in the message source. – Manca Weeks May 05 '12 at 16:44
  • OK, thanks, that does answer my question. I figured that this was what needed to happen, thanks for confirming it for me. I guess Outlook still has provisions in it for uuencoded attachments without proper headers in Windows... If you have it in you to post what the correct headers would look like for my example, that would complete this answer for anyone looking for this answer (as well as for me)... – Manca Weeks May 05 '12 at 23:22
  • As you may notice I went ahead and posted a sample of what works. There may be other ways to achieve a working encoding, but no need for you to waste your time doing this for me - thanks again. – Manca Weeks May 05 '12 at 23:42
  • As per this question http://stackoverflow.com/questions/6904126/how-can-we-figure-out-why-certain-uuencoded-files-are-not-decoding-properly-usin I am also having some files with ".." at starting of last line. Should i replace them with "M" is correct solution for this? – Neel Jun 02 '16 at 12:04
1

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.

 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--
Manca Weeks
  • 689
  • 3
  • 7
  • 11
0

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.

I simply want to know what the reason is for these being incorrectly decoded on clients and webmail interfaces of a recent vintage

You're working with 20-year old tech and some clients don't support it. Go figure.

My recommendation to them was going to be to encode the attachments in accordance with the current MIME standards

That is absolutely the right recommendation. You will get universal support if you do. Good luck.

james.garriss
  • 360
  • 6
  • 17