Attachments garbled, unreadable

Hi All,
I am using several machines to access my work email from an imap server.
My desktop machine (G5, 10.4.6) usually works fine, over the office ethernet. However, there are a fraction of messages with (usually large) attachments that do not come through. Rather than having the attachment clearly recognized, the message incorporates the attachment as machine language to create a single very LARGE message like this:
...nfMAoCelqrXVMAsAjdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB...
It is in the body of the text, usually set off with something like:
--=_Part44615259.52_=
Content-Type: application/msword; name="Test.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Test.doc"
Theere is no "paperclip" indicating an attachment and no "save" button n the top of the paine.
If I access the message from the webmail server, bypassing the client, I can pull the attachment from there, so the attachment itself is fine.
This doesn't happen on my laptop (G4, 10.3.9), which always downloads the attachments properly, whether from the office ethernet, wireless, or remotely from my home ISP.
It also does not happen to all attachments, and not even to all large attachments. But they are unreadable. Quitting and restarting does not help.
Any ideas?

I have an AOL account (IMAP server) that I access via Mac Mail.
I also get big attachements that come in as unreadable text in the body of the e-mail. But this is infrequent, but persistent. I've not been able to pin it to one source or type of file.
The other problem I get is often the mail comes in "blank" there is nothing (or only header text) in the mail I open with Mac Mail.
The interesting thing is that I can go to my AOL account and log on there via my ISP (the same one that I go though to get Mac Mail) and both of these problems go away (they are okay when viewed via AOL mail client).
Today I got one of the "header only" problem e-mails. I went to AOL and could read it. So I forwarded it back to my AOL account and when opened the second time from Mac Mail, it was all readable. Can someone explain???
More importantly, can someone explain what I need to do in Mac Mail to be able to consistently read incoming files.
Here is the text of what my e-mail looked like in the Mac Mail after it was forwarded back following my opening it in AOL. I have cut off some of the text to reduce the length of the e-mail, but have kept in the headers as they may contain useful information:
From: [email protected]
Subject: Fwd: [PRAF] Fwd: 2006 Governor's Cup 1st Call - Wae River YC
Date: May 16, 2006 1:01:37 PM EDT
To: [email protected], [email protected]
In a message dated 5/16/06 10:28:01 AM, [email protected] writes:
Note: forwarded message attached.
X-Apparently-To: [email protected] via 209.73.179.84; Tue, 16 May 2006 06:47:50 -0700
X-Originating-IP: [64.12.137.4]
Authentication-Results: mta237.mail.re2.yahoo.com
from=aol.com; domainkeys=neutral (no sig)
Received: from 64.12.137.4 (EHLO imo-m23.mail.aol.com) (64.12.137.4)
by mta237.mail.re2.yahoo.com with SMTP; Tue, 16 May 2006 06:47:50 -0700
Received: from [email protected]
by imo-m23.mx.aol.com (mailout_v38r7.5.) id i.45a.743c12 (29672);
Tue, 16 May 2006 09:47:26 -0400 (EDT)
From: [email protected]
Date: Tue, 16 May 2006 09:47:25 EDT
Subject: 2006 Governor's Cup 1st Call - Wae River YC
To: [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-----------------------------1147787245"
X-Mailer: 9.0 for Windows sub 5057
X-Spam-Flag: NO
Content-Length: 2280
First Call!
42nd Annual Virginia Governor's Cup Regatta
Powerbook G4- Titanium Mac OS X (10.4.6)

Similar Messages

E-mail attachments I send arrive as garbled unreadable e-mails

This seems to happen randomly with messages I send whether I use Entourage of Mail. My attachments sometimes go through and sometimes they don't. They become unattached and the recepient receives this message:
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--B32300431951484520
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
The e-mail body message I write appears here... followed by what you see below.
--B32300431951484520
Content-type: application/msword; name="Smart Borrower Spanish.doc";
x-mac-creator="4D535744";
x-mac-type="5738424E"
Content-disposition: attachment
Content-transfer-encoding: base64
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAiAAAAAAA
AAAAEAAAigAAAAEAAAD+////AAAAAIYAAACHAAAA///////
And the garble continues.
My mail server is bellsouth.net a POP server. Bellsouth says every thing from their end is fine. Also checked with Microsoft and they say it's a server issue. In the meantime I'm stuck in the middle.
I did find in your discussion groups someone having a similar problem with an IMAP mail server, but no solution was given.
My clients are getting frustrated too because I continue sending worthless files.
Please help!!! I invested too much $$$ on this computer and programs to be having problems like this.
Im desperate!!!
Tanya
ibook power pc g4 Mac OS X (10.4.6) Mail server: bellsouth (POP server)

Hi Tanya, it is rather strange that even a simple word docu attachment would create such a problem.
By "right", even if you just started using either MS Entourage or Apple Mail fresh, and did not go deep in to reconfigure anything... the attachment like this "should" get through to "most of the computers", Mac or PC wise.
Let me raise an example of my personal work experience regarding using Mail's "Send PC Windows Friendly Attachments" and when you may need to turn on or off this feature.
In my company's cable media line, I need to send Jpeg images as "Still On Air" slide to our On-air Presentation Suite (where all the channels, beaming etc are) to put up say, a "Breakdown Slide", all of them use PCs; If I need to send them this Jpeg file, extension aside, which we all agree is by now a standard protocol whether it's sending to a Mac and/or PC, if I turn on Mail's Windows Friendly feature, this Jpeg image file will be "embedded" into my email, and they will have no way to extracting it out as a Jpeg image file to put to use, I have to turn that feature off so the image file is like a regular attachment that goes through.
So as for your case, maybe part of the reason, you may want to check with your ISP, and also the companies you are sending email to, whether their company servers have any form of various of different filter system or standards; Let me take any example, we sometimes also send Targa image files, (.tga) which is for on-air Channel Bug (the channel logo you see on the corners of the TV screens), and this Targa file has a alpha or matte channel; But somehow our own company's servers "hates" targa files and will filter them off, treating them like junk!
So the solution is to compress the file, zip it and it will go through.
So maybe you want to "experiment" and zip the file and see whether it will go through nicely.
Mac OS X has its own Compression feature built-in, so you don't really need DropStuff or anykind, highlight the file and right-click, select "Create Archive of xxx" (being the name of the file, or folder) and then you go, a zip file will be created.
Cheers

Attachments garbled in Mail

I have a friend who recently purchased a 13" Mac Book. The Store/Geniuses got it all setup for her. She also has an existing iMac at home. The issue she has now is that on the Mac Book, when she gets emails that have attachments, they come across garbled. Opening the exact emails on her iMac, things work just fine. She's using Mail on the Mac Book and Thunderbird on the iMac...
Searched here as well as Googled, but only came up with the two main culprits for garbled mail -> corrupted font cache or the existense of Helvetica Fractions or Times New Roman Phonetic. Those problems are fixes for garbled emails (subject line, mail body, etc.), not attachment specific.
I'll probably take possession of the Mac Book soon to see/test for myself, but any help in advance would be much appreciated. Will try the Font Cache Fixers as well as install TBird to see if they help.
Message was edited by: Doanster1

Hello, and welcome to the Discussions.
The suggestion posted would not apply to 10.2.x, but only to 10.3 and later.
In 10.2 and earlier, this was an often seen issue, and we relied upon a program named GrimRipper, available from VersionTracker, to remove the Resource Fork that resulted from file saving in MS Word, but not the other applications in MS Office. While it would have been correctable by MS, I don't believe they ever made such a fix.
See:
http://www.versiontracker.com/dyn/moreinfo/macosx/16168
Be aware that any subsequent Save As, after ripping, will return the Resource fork.
Entourage was programmed to take care of this, as best I can remember, and the Windows Friendly option was developed by Apple, but not included until Panther.
Ask any questions needed.
Ernie

Help! All text is totally GARBLED & UNREADABLE on Safari 4.02.

OK, so I downloaded the new Safari yesterday and have had MAJOR problems with it ever since. On the majority of sites I go to, the text is completely GARBLED and nothing I do seems to work...I tried changing the text encoding, nothing happened. I can't even Google anything because all the results are unreadable. ALSO, some of my e-mails are coming up garbled as well. What can I do?? What happened here?
Thanks!!

What happened here
Either the download was corrupt, OR it revealed existing faults in your system, OR you forgot to restart after the install.
I would suggest you start with a bit of basic maintenance:
Repairing permissions is important, and should always be carried out both before and after any software installation or update.
Go to Disk Utility (this is in your Utilities Folder in your Application folder) and click on the icon of your hard disk (not the one with all the numbers).
In First Aid, click on Repair Permissions.
This only takes a minute or two in Tiger, but much longer in Leopard.
Background information here:
http://docs.info.apple.com/article.html?artnum=25751
and here:
http://docs.info.apple.com/article.html?artnum=302672
An article on troubleshooting Permissions can be found here:
http://support.apple.com/kb/HT2963
By the way, you can ignore any messages about SUID or ACL file permissions, as explained here:
http://support.apple.com/kb/TS1448?viewlocale=en_US
If you were having any serious problems with your Mac you might as well complete the exercise by repairing your hard disk as well. You cannot do this from the same start-up disk. Reboot from your install disk (holding down the C key). Once it opens, select your language, and then go to Disk Utility from the Utilities menu. Select your hard disk as before and click Repair.
Once that is complete reboot again from your usual start-up disk.
More useful reading here:
Resolve startup issues and perform disk maintenance with Disk Utility and fsck
http://support.apple.com/kb/TS1417?viewlocale=en_US
Then Download the Safari 4.0.2 update again and install it, reboot your Mac and repair permissions again.

When I apply a mail rule to move a message to a different mailbox, large attachments are unreadable

I have a rule in Mail: Move messages that were sent to a particular accout, to a particular mailbox. It moves the message like it's supposed to but if there are attachments over about 1 MB the attachment is no longer there, and instead there's a bunch of code in the body of the message. With smaller attachments, the message appears in the new mailbox with the file attached, just as expected. Anybody know what's up? Thanks, Bob

You can't simply feed it some arbitrary script to execute, you have to write a handler that Mail can dispatch events to. This generally looks something like
using terms from application "Mail"
on perform mail action with messages theMessages for rule theRule
tell application "Mail"
repeat with suspectMessage in theMessages
--do something
end repeat
end tell
end perform mail action with messages
end using terms from

Word document attachments garbled

When I try to send a Word document to users outside of my ISP they come through as "noname" This does not happen with TextEdit files or with pdf files. It also doe snot happen when sending attachments to other users in my ISP (Road Runner). The folks at Road Runner insist that I have a virus. I ran a virus scan with the most recent virus defs and nothing showed up. I repaired permissions and repaired the hard drive -- no problems found.I have tried using the extension, not using the extension, clicking to open, opening from within the application and it's always the same result. This is what appears at the top of the "noname" file (titled "test file" when sent):
--Apple-Mail-2-863040009
Content-Transfer-Encoding: base64
Content-Type: application/applefile;
name=test file
Content-Disposition: attachment;
filename="test file"
A string of letters, mostly A's
--Apple-Mail-2-863040009
Content-Transfer-Encoding: base64
Content-Id: <[email protected]>
Content-Type: application/octet-stream;
x-mac-type=5738424E;
x-unix-mode=0644;
x-mac-creator=4D535744;
name=test file
Content-Disposition: attachment;
filename="test file"
More computer gibberish.
I can receive with no problem. Any ideas will be greatly appreciated!

"It's a virus" can sometimes be loosely translated as "I don't know."
It could easily be that the Word documents are getting stripped by intervening SMTP servers or firewalls, or by anti-spyware or anti-virus tools. Word documents are common mechanisms for transmitting malware and thus a common target for filtering; the whole family is a particularly hazardous form of file as it can easily contain executable code.
What you're showing are the MIME section headers of Base64 MIME-encoded mail. With the intervening text that comprises that part of the MIME message.
The "gibberish" is the message text or the attachment, encoded using Base64. (Base64 is a way to get binary or arbitrary data converted into printable data for transmission, since most mail systems only deal properly with printable characters.)
When you are sending the message (with Mail.app, I assume?), did you select the "Windows Friendly" option? You can set this Windows Friendly option on a per-message basis, or you can always select it via the (IIRC) Edit menu; to default it. It's generally safe to default it.
I'd also suggest having the receiver extract the text of the mail message for a look. (If that wasn't the headers from the receiver that you were showing.)
The MIME headers look to be missing the filename information, which could be the sending mail client, some filter or firewall, or something in the receiving software. A more typical header is:
--Apple-Mail-2--31415926535
Content-Transfer-Encoding: base64
Content-Type: application/applefile;
name="whatever.doc"
Content-Disposition: attachment;
filename="whatever.doc"
Have you tried sending the mail messages with another mail client? With Thunderbird, for instance.
And as a test, when you receive the message with the noname file, extract it as you would normally, and name the created file noname.doc, and try opening it using catdoc, NeoOffice, OOo, or whatever you're using to read that file format. (There seem to be a few tools around that will open .doc files.)

IPhone 4S' Mail's unread e-mail attachments, but where?

Hi!
I am helping a client with his old iPhone 4S' Mail that shows three/3 unread e-mail attachments. So far, he was unable to find them and even tried to delete some unwanted e-mails and read all his e-mail attachments, but Mail still showed 3/three. We tried upgrading iOS v7.1.2 to v8.1.2, but that didn't fix it. We also tried marking all (about ten/10) e-mails with attachments as unread (were already read) and then read, but that did not help.
What could be the problem? From a quick Google search, it seems like it could be a server problem? My client uses both POP3 and IMAP with two different e-mail addresses and providers (USC's Office 365 [IMAP] and EarthLink's e-mail service [POP3 and SMTP].
Thank you in advance.

ManSinha wrote:
If those emails are opened on a computer - are there any unread emails with attachments?
If not then is deleting the mailboxes one at a time and resetting them up an option?
Thanks
I'll have to ask the client about your questions. I know he has tons of e-mails. He uses both webmails and his iPhone 4S' mail app. :/

MIME header missing "filename=" results in BAD messages

I've been trying to track down several issues involving what appear to
be MIME handling issues. We are running GroupWise v7.01 (we have not
installed the "interim release" yet), and all components on the server
are at that release level (MTA, POA, GWIA, WebAccess).
One of the issues I am currently working on involves problems receiving
attachments from an outside sender. Their attachments are readable if
sent to an outside test account (i.e. - we've tested it with Yahoo
web-based mail, and a RoadRunner POP3 account using Outlook as the client).
The problem is that these e-mails either get dumped by the GWIA to the
GWPROB directory, or the e-mails go through, but the attachments are
corrupted (they do show up as attachments to the e-mail, but are
unreadable).
I haven't looked at why some e-mails go through and some don't, but I
did find out why the attachments are unreadable on the delivered
e-mails, and why the rest are just undeliverable. For whatever reason,
the sender's mail server (or AV gateway or whatever else had a chance to
touch the e-mail) is either not inserting, or is stripping out the
"filename=" from the MIME header just before the encoded attachment.
Adding this back into the message (by editing the original e-mail
w/header, and dropping the modified message into the GWIA "RECEIVE"
directory) fixes the attachment AND makes the e-mail deliverable.
Below I have an example of a bad e-mail which was originally sent to our
GWPROB directory, but was successfully delivered with a readable
attachment through a separate POP3 account (RoadRunner). Following this
"bad" e-mail example is the "fixed" version of that same e-mail, which
was delivered successfully to our user, with the attachment also being
readable.
*************** This is the original "BAD" e-mail ***************
MAIL From:<[email protected]> SIZE=73686
RCPT To:<[email protected]>
Received: from test.rr.com ([65.xx.xx.xx])
by smtp.ourhost.com with ESMTP; Wed, 21 Feb 2007 15:28:27 -0500
Received: from local.com (rrcs-24-xx-xx-xx.central.biz.rr.com [24.xx.xx.xx])
by test.rr.com (8.13.6/8.13.6) with ESMTP id l1LKSFTm009106
for <[email protected]>; Wed, 21 Feb 2007 15:28:24 -0500 (EST)
Message-Id: <[email protected]>
From: [email protected]
To: [email protected]
Date: Wed, 21 Feb 2007 15:25:54 -0500
MIME-Version: 1.0
X-Mailer: Telexis Gateway
Content-Type: multipart/mixed;
boundary="Mark=Num1_Lev1_2007221202554265_Tlx"
X-Virus-Scanned: Symantec AntiVirus Scan Engine
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: text/plain
Content-Transfer-Encoding: Quoted-Printable
This is a test
-Test Sender
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: application/vnd.ms-excel;
name="1st Q 2007 Income to Budget.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
"1st Q 2007 Income to Budget.xls"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAZgAAAAAAAAAA
EAAA/v///wAAAAD+////AAAAAGUAAAD/////////////////////////////////////////////
--Mark=Num1_Lev1_2007221202554265_Tlx--
************** END OF BAD E-MAIL **************
*************** This is the "fixed" e-mail ***************
MAIL From:<[email protected]> SIZE=73686
RCPT To:<[email protected]>
Received: from test.rr.com ([65.xx.xx.xx])
by smtp.ourhost.com with ESMTP; Wed, 21 Feb 2007 15:28:27 -0500
Received: from local.com (rrcs-24-xx-xx-xx.central.biz.rr.com [24.xx.xx.xx])
by test.rr.com (8.13.6/8.13.6) with ESMTP id l1LKSFTm009106
for <[email protected]>; Wed, 21 Feb 2007 15:28:24 -0500 (EST)
Message-Id: <[email protected]>
From: [email protected]
To: [email protected]
Date: Wed, 21 Feb 2007 15:25:54 -0500
MIME-Version: 1.0
X-Mailer: Telexis Gateway
Content-Type: multipart/mixed;
boundary="Mark=Num1_Lev1_2007221202554265_Tlx"
X-Virus-Scanned: Symantec AntiVirus Scan Engine
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: text/plain
Content-Transfer-Encoding: Quoted-Printable
This is a test
-Test Sender
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: application/vnd.ms-excel;
name="1st Q 2007 Income to Budget.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="1st Q 2007 Income to Budget.xls"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAZgAAAAAAAAAA
EAAA/v///wAAAAD+////AAAAAGUAAAD/////////////////////////////////////////////
--Mark=Num1_Lev1_2007221202554265_Tlx--
************** END OF "FIXED" E-MAIL **************
The only change I made, which both allowed the above e-mail to be
delivered and made the attachment readable, was the addition of the
"filename=" just before the file name on the line after the
"Content-Disposition: attachment;".
I did the same test with an e-mail that had the same "filename="
missing, but somehow was successfully delivered to our user (again, the
attachment was unreadable). Adding the "filename=" into the resent
message did make the attachment readable.
I haven't looked to see if the sender's system is actually non-compliant
for excluding the "filename=" (I will be doing that later this evening),
or whether this is a GWIA problem for not being able to handle this. I
just wanted to throw this out there to see if anyone else has seen this.
Does the "interim release" update by chance fix this?
Thanks,
Greg Niese

Does this email come in directly to GWIA (or do you have a relay host in
between)? I must say I've never experienced this problem on any of the GW
systems I administer. Could you tell us what domain this is coming from?
Ted Kumsher
>>> On 2/23/2007 at 8:21 AM, in message
<[email protected]>, Greg
Niese<[email protected]> wrote:
> I agree that this shouldn't be accepted as a valid "filename parameter"
> line. There are two ways to "not accept" this invalid parameter: "stop
> processing" the e-mail because of the problem (discard the e-mail), or
> discard the bad parameter and continue processing the rest of the e-mail
> (this could only work when the parameter is optional, as in this case).
> The GWIA seems to take the route of "stop processing", and then moving
>
> the resultant "bad" e-mail to the GWPROB directory.
>
> I say "seems" because in many cases where this occurs the e-mail doesn't
> get sent to the GWPROB directory, but instead still gets through the
> GWIA to the user. The attachments are corrupted, but still show up
> correctly in the attachment window, so everything seems OK with the
> e-mail & attachment - until you try to open the attachment.
>
> If there is a semi-colon after the "Content-disposition" type, the GWIA
> should see a valid disposition parameter following. But if it sees an
> invalid parameter, as in this case, what is the GWIA doing? It must
> either be discarding the invalid parameter, or "uses" it by either
> incorrectly parsing it as part of the header, or lumping it in as part
> of the attachment. If it "uses" in any way the invalid line of data -
> that sounds like the definition of "accepting" it, isn't it?
>
> To test whether the GWIA is actually using, and therefore "accepting",
> this bad parameter, I simply removed the malformed parameter (having the
>
> line in or out shouldn't matter if the GWIA's not using it), and I tried
>
> this both with the semi-colon removed from the end of the
> "content-disposition" type, and with that semi-colon left in place. In
> both cases the GWIA properly processed the e-mail and the attachment was
> readable! What does that mean? If the GWIA was truely NOT
> using/accepting that invalid header parameter (i.e. - the GWIA discards
> it), then the e-mail and attachment should go through OK. Since this
> isn't what happens when the bad line is left in place (the attachments
> DO NOT come through OK, but the e-mail often does get to the user's
> mailbox), then the GWIA must be accepting that bad parameter as either a
>
> part of the header, or a part of the attachment.
>
> I suspect that in those cases that these e-mails are sent to the problem
> directory, instead of being delivered with a corrupt attachment, the
> GWIA isn't really recognizing that the optional disposition parameter is
>
> "bad". The reason for the e-mail going to the problem directory is
> probably due to an error while trying to decode the attachment if the
> bad parameter is treated as part of the attachment, or if part of the
> attachment is being lumped in with the malformed parameter as it is
> parsed.
>
> I agree that how the GWIA should go about "not accepting" bad header
> parameters may be debatable (assuming that the GWIA were actually
> halting processing of the e-mail when this type of problem is found, and
> then sending the e-mail to the problem directory every time). But in
> cases such as this, since the parameter itself is optional, it would
> seem that the better route would be for the GWIA to discard the
> parameter and continue processing, instead of "discarding" the whole
> e-mail (to the problem directory). "Discarding the bad parameter" seems
> to be what is being done by at least a few other competing SMTP agents,
> since the other mail systems I tested with did get the e-mail through
> without corrupting the attachment.
>
> I may suggest that the sender's company fix whatever is going on at
> their server, but it probably won't do any good (I've already been told
> that they don't experience this problem with anyone else). In the
> meantime, my user (yes...he is the CEO), will have to continue to have
> some important e-mails sent to one of his personal accounts, because
> those e-mail systems receive these e-mails fine, but our GroupWise
> system can't.
>
> :-(
>
> -Greg
>
>
>
> Michael Bell wrote:
>> No it shouldn't, IMO.
>>
>> It's a matter of interpretation, of course. But GWIA is 100% right in
> not
>> accepting this as vaid (that part is beyond any debate - it's in the
> RFC).
>>
>> The only part that can be debated is "should GWIA then pass the buck"?.
> In
>> olden days, many would have said yes.
>>
>> But In general, no. Moving away from Postel's law, which was formulated
> in a
>> pre-malware age, is pretty much needed. Tight specifications and
> pickiness
>> is good. Collateral damage is unfortunate, and of course one needs to be
>
>> flexible if this is a widespread issue (which frankly, it is not in this
>
>> case), but otherwise it is up to to sender to fix their issue.
>>
>> 90% of viruses and malware in the last 6 years (and I'm well aware of
> them,
>> working in the email security field) are from MALFORMED e-mail, that the
>> gateway and client misinterpreted. Many of these were MS issues, but
> that's
>> another point. Point is you have to be STRICT.
>>
>> In this case this violates the generic MIME RFCs which state that if you
> do
>> have parameters, they all gotta be separated with semicolons (PASS), and
>
>> have to be name=value pairs (FAIL).
>>
>>
>> "Greg Niese" <[email protected]> wrote in message
>> news:[email protected]...
>>> Well, according to RFC 2183, the "filename=" string has to be present if
>
>>> the Filename parameter is going to be used. So the sending host seems
> to
>>> be "broken" in that regard.
>>>
>>> My next question then is: Should the GWIA ignore the "stray" file name
> in
>>> these e-mail headers, instead of allowing it to be lumped in with the
>>> attachment (I'm assuming that's why the attachment is trashed)? It
>>> appears that other systems are able to do this.
>>>
>>> -Greg
>>>
>>> Greg Niese wrote:
>>>> I haven't looked to see if the sender's system is actually
non-compliant
>>>> for excluding the "filename=" (I will be doing that later this
evening),
>
>>>> or whether this is a GWIA problem for not being able to handle this. I
>>>> just wanted to throw this out there to see if anyone else has seen
this.
>>>>
>>>> Does the "interim release" update by chance fix this?
>>>>
>>>> Thanks,
>>>>
>>>> Greg Niese
>>>>
>>
>>

Decoding in Labview, ASCII, Unicode

hello guys! I am a Labview novice and trying to build a program which communicates with an angular orientation sensor, which sends data in 2 formats, ASCII and binary.
When handling the data sent from the orientation sensor coded in ASCII, some garbled codes are returned somehow. I don't really understand how Chinese characters can come out, when the data is encoded in ASCII. I am personally using a Chinese Windows 7 platform, but that shouldn't affect the program since my labview is in English.
Is there anyway to control how Labview decode the bytes of data sent from the sensor? I doubt that it might be using Unicode or something to decode the data bytes, resulting in the garbled codes.
Thanks in advance!
Matthew
Attachments:
garbled code.JPG ‏10 KB

How are you communicating with your device? If using RS-232, make sure your baud rate is correct. That is the common reason I have seen a mess of bytes like that. The other option is that the instrument is returning binary data. Try chaning the view of your string to Hex and see if the data makes any sense that way.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Mail attachments showing up as garbled inline text (code)

Running 10.5.6 with Mail 3.5
Receiving attachments to emails is inconsistent. Sometimes a Word document is received with an email just fine. Other times it will be attached by the sender (in the usual manner) but will show up in my email as inline text (just garbled text or code). If the email is sent to my gmail account, the Word doc is fine.
I am not sure what to look for since the symptoms seem to be inconsistent.

I have had the same problem for a long time. What burns me up is that I think I understand it, and there isn't a darn thing I can do about it --- short of using a different email client.
Examine one of these emails with the garbled text in place of attachment. If you're having the same problem I am, then when you use view -> message -> raw source, just before the attachment you will see something like this:
Content-Disposition: inline;
Multi-part MIME format messages can specify whether their sub-parts are meant to be viewed inline. If it is inline, often Mail will render images and PDF documents as you might expect, but many other file types are rendered as plain text. This even happens with files generated by applications Apple ought to be smarter about, such as iCal. I suppose that from Apple's point of view, the fault lies elsewhere. The sender's email client ought to be smart enough to let them send attachments as attachments. Unfortunately, some mail clients (Thunderbird in particular) seem to always mark outgoing attachments as inline, and Apple Mail does not have the flexibility to treat it in any other way.

Pdf files as email attachments come in unreadable Word

pdf files as email attachments come up in unreadable Word. What am I doing wrong?
These files are saved as .pdf

If they automatically open in Word, then you need to change the file association.
Easiest by uninstalling/reinstalling Adobe Reader.

HT1527 Successfully burned my playlist to CD. Tried to print cover for jewel case-cover photo printed OK but playlist is garbled and unreadable.

I successfully burned my playlist to CD. Tried to print jewel case cover-cover photo printed OK but playlist is garbled and unreadable (prints song tiles/artists on top of one another). Has worked OK in past-why not now? Tom

Apple, what about fixing the printing problem? Jewel-case printouts have highly compressed text on the back - for months and months. Come on Apple, be responsible people, fix your problems quickly. No wonder the share price is underperforming. Investors know that your business requires customers (quaint notion, isn't it?) and we customers are disillusioned and are leaving you in droves. Windows Surface and Windows Phone8, Android phones and Pads, there are now a usable alternatives to the Apple Ecosystem. I suspect this post will be short-lived, but at least I've let you know that I'm disillusioned. Are you listening, corporate Apple Inc.? Probably not.

I forward attachments that I receive on my iphone and it is all garbled. I can view the document on my workstation fine

I receive attachments on my iphone and it is all garbled. I can view the attachments from my workstation just fine

It was Adobe, we have had some issues before and out tech guy said to
delete the signature line when the attachment is forwarded (which my
employee fails to do, so I am looking for other options
>> Personal information removed to comply with the Verizon Wireless Terms of Service <<
Edited by: Verizon Moderator

Mail attachments as MIME-attachment unreadable!!!

I've been using Entourage for a long time and it works ok
I have a gmail account
Now I'm trying to synchronize my mail with an IMAP account in Apple Mail app.
The problem is that some of the attachments now appear as "MIME-attachment" and they are unreadable!!!!
I go to www.gmail.com, check the same message and there it is!: the attachment as it should be! and I can open it right away.
Happened with pdf, gif, jpg files
Please help

Hello,
I think I've found the problem... but not the solution
I did a simple test.
Took a PDF and sent it via Gmail Webmail to myself.
Testing both UTF-8 sending formatting ON and OFF (via Gmail settings) -- Has no affect.
The problem was pinned while renaming the attachment. If the attachment is in English or numbers, you will see it as normal.
If the attachment is NOT in English or numbers Gmail will transform it to UTF-8 and Apple Mail doesn't seem to know how to handle it.
Here are the results.
Test1: File name is 09879.pdf
------=Part_2220323867308.1197303123110
Content-Type: application/pdf; name=09879.pdf
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fa17cq7a0
Content-Disposition: attachment; filename=09879.pdf
------=Part_2220323867308.1197303123110--
Test2: I renamed the file to contain NON-English charecters, in my case Hebrew
------=Part_2221813473114.1197303418627
Content-Type: =?UTF-8?Q?application/pdf;_name=3D?=
=?UTF-8?Q?"=D7=93=D7=9F-=D7=A4=D7=AA=D7=A8=D7=95=D7=A0=D7=95=D7=AA?=
=?UTF-8?Q?_=D7=95=D7=A9=D7=90=D7=9C=D7=95=D7=AA.pdf"?=
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fa17iz8l0
Content-Disposition: =?UTF-8?Q?attachment;_filename=3D"?=
=?UTF-8?Q?=D7=93=D7=9F-=D7=A4=D7=AA=D7=A8=D7=95=D7=A0=D7=95=D7=AA_?=
=?UTF-8?Q?=D7=95=D7=A9=D7=90=D7=9C=D7=95=D7=AA.pdf"?=
------=Part_2221813473114.1197303418627--
As you can see, here relies the problem. If Only Mail.app add the file extension from the Content-Type and we're all set.
In the meanwhile, if you want to know the file type just go to 'View --> Message --> Raw Source'
and search for 'Content-Type' a few times or 'application'
Does anyone here have an idea of solving this issue ?
Idan.

I just downloaded Mountain Lion on my Macbook Pro. Firefox and Safari are showing up in HTML (I think) and many web pages are garbled and unreadable.

I just downloaded Mountain Lion on my Macbook Pro 10.8.2 Now Safari and Firefox are not functioning right - sites are garbled, show up as bulleted blue phrases, don't react. I am trying to search train tickets in Paris and can't do it. My e-mail (Shaw) defaults to HTML and I cannot access the Bay site through e-mail. Help.

Please read this whole message before doing anything. This procedure is a test, not a solution. Don’t be disappointed when you find that nothing has changed after you complete it. Step 1 The purpose of this step is to determine whether the problem is localized to your user account. Enable guest logins* and log in as Guest. For instructions, launch the System Preferences application, select Help from the menu bar, and enter “Set up guest users” (without the quotes) in the search box. Don't use the Safari-only “Guest User” login created by “Find My Mac.” While logged in as Guest, you won’t have access to any of your personal files or settings. Applications will behave as if you were running them for the first time. Don’t be alarmed by this; it’s normal. If you need any passwords or other personal data in order to complete the test, memorize, print, or write them down before you begin. Test while logged in as Guest. Same problem? After testing, log out of the guest account and, in your own account, disable it if you wish. Any files you created in the guest account will be deleted automatically when you log out of it. *Note: If you’ve activated “Find My Mac” or FileVault, then you can’t enable the Guest account. The “Guest User” login created by “Find My Mac” is not the same. Create a new account in which to test, and delete it, including its home folder, after testing. Step 2 The purpose of this step is to determine whether the problem is caused by third-party system modifications that load automatically at startup or login. Disconnect all wired peripherals except those needed for the test, and remove all aftermarket expansion cards. Boot in safe mode* and log in to the account with the problem. The instructions provided by Apple are as follows:
Shut down your computer, wait 30 seconds, and then hold down the shift key while pressing the power button.
When you see the gray Apple logo, release the shift key.
If you are prompted to log in, type your password, and then hold down the shift key again as you click Log in.
Safe mode is much slower to boot and run than normal, and some things won’t work at all, including wireless networking on certain Macs. The login screen appears even if you usually log in automatically. You must know your login password in order to log in. If you’ve forgotten the password, you will need to reset it before you begin. *Note: If FileVault is enabled, or if a firmware password is set, or if the boot volume is a software RAID, you can’t boot in safe mode. Test while in safe mode. Same problem? After testing, reboot as usual (i.e., not in safe mode) and verify that you still have the problem. Post the results of steps 1 and 2.

Attachments garbled, unreadable

Similar Messages

Maybe you are looking for