Attachment not recoverable if not recognized, or case of mistaken identity.

Attachment not recoverable if not recognized, or case of mistaken identity.

I have 2 issues. (9.01)

1) I just received by email a file called "image.pdf", which is just a pdf named image. However, opera is trying to show an image, it seems, as it shows a box with the word "image" in it, like the ones you get online when images are missing. It didn't load Acrobat like it would with normal .pdf.

There is no save buttons, since it is (trying to) displaying an image instead. Because there is no save button, I can't even retrieve it and rename it something else, which is, from my standpoint, an big omission in UI design.

If I RMB on the "image" box, it doesn't allow any saving. I can read image properties, which shows the correct Kb size and dimension (0 x 0, obviously, since it's not an image). In addition, if I "show all headers", it shows pages and pages of garbled letters, which means that the attachments is present, but not recoverable.


We need a Save Attachment button _regardless_ of whether Opera is showing it or not, AND regardless of whether Opera recognizes it (see point #2)



* Question: Any clue on how to retrieve an attachment that has no "save" button, no valid RMB ?



2) 2nd issue is similar to this topic, but not quite: http://my.opera.com/community/forums/topic.dml?id=145684

When I get a certain type of image attachment (.tiff from a Macintosh, I believe, but don't quote me on that) , it is sometimes not recognized as such. The attachment button and the size shows there is something, but there's nothing to be saved at all. Alternatively, if you "show all headers", you will see pages and pages of garbled letters, so it's there, it's just not recoverable.

Again, Opera needs a "save attachment" regardless of whether it recognize the attachment or not. Opera obviously knows there is an attachment, based on the header.

Thanks,

C.

I confirm: I received the same .pdf attachment today, renamed something else, and there was no problems.

Is this to be considered a bug? Should I list it?

C.

You'd need to look at the raw message (right-click and select View all headers and message) to see the actual content type that was listed for the attachment.

Here's the similar info for a real image that I received some time ago:

------_=_NextPart_001_01C4EC58.580FAB76
Content-Type: image/jpeg;
	name="opera3.JPG"
Content-Transfer-Encoding: base64
Content-Description: opera3.JPG
Content-Disposition: attachment;
	filename="opera3.JPG"

You see that this image as listed as content type image/jpeg, which it actually is. We'd need to see if yours was listed as application/pdf or application/octet-stream or what to decide whether this was an Opera error.

Thanks for responding. Here's the relevant info (I edited the personal info):

(note that there's a line below about a browser not understanding the MIME format. I can't figure out if it's mine or his, but I guess his. He's on a Macintosh, fyi.)

---

Return-Path: <email@address.com>
Received: from XXX.cox.net ([0.0.0.0])
by XXX.cox.net
(InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP
id <XXX.centrmmtai10.cox.net@centrmimpi01.cox.net>
for <email@address.com>; Thu, 24 Aug 2006 20:23:37 -0400
Received: from XXX.com ([0.0.0.0])
by XXX.cox.net with IMP
id E0JT1V01i3Pxtq90000000
Thu, 24 Aug 2006 20:18:31 -0400
Received: from XXX.com ([0.0.0.0]) by XXX.com with Microsoft SMTPSVC(5.0.2195.6713);
Thu, 24 Aug 2006 17:23:33 -0700
Received: E2KSEA2 0.0.0.0 from 0.0.0.0 0.0.0.0 via HTTP with MS-WebStorage 6.0.6249
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Thu, 24 Aug 2006 17:23:32 -0700
Subject: XXX
From: email@address.com
To: email@address.com
Message-ID: <email@address.com>
Thread-Topic: XXX
Thread-Index: AcbH3LIE8KT2SjPPEduJ7QANkzE2sg==
Mime-version: 1.0
Content-type: multipart/related;
boundary="B_3239285012_5184459"
Return-Path: email@address.com
X-OriginalArrivalTime: 25 Aug 2006 00:23:33.0452 (UTC) FILETIME=[B2E1E8C0:01C6C7DC]

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

--B_3239285012_5184459
Content-type: multipart/alternative;
boundary="B_3239285012_5190125"


--B_3239285012_5190125
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


EMAIL TEXT WAS HERE


--B_3239285012_5190125--

--B_3239285012_5184459
Content-Type: application/pdf; name="image.pdf"
Content-ID: <3239285012_5199949>
Content-Transfer-Encoding: base64

JVBERi0xLjQNJeLjz9MNCjQyIDAgb2JqIDw8L0xpbmVhcml6ZWQgMS9MIDIyOTk1MS9PIDQ0
L0UgMjA1NjI5L04gMS9UIDIyOTA2OS9IIFsgMTM3NiAyNzhdPj4NZW5kb2JqDSAgICAgICAg
ICAgICAgIA14cmVmDTQyIDU0DTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMTgxOSAwMDAw
MCBuDQowMDAwMDAxOTc4IDAwMDAwIG4NCjAwMDAwMDI1MzEgMDAwMDAgbg0KMDAwMDAwMjky
MyAwMDAwMCBuDQowMDAwMDAzMDkyIDAwMDAwIG4NCjAwMDAwMDQ2NjggMDAwMDAgbg0KMDAw
MDAwNDgwNSAwMDAwMCBuDQowMDAwMDA1MjcyIDAwMDAwIG4NCjAwMDAwMDU0NTEgMDAwMDAg
bg0KMDAwMDAwNTU4MyAwMDAwMCBuDQowMDAwMDA2MTE3IDAwMDAwIG4NCjAwMDAwMDY1MDkg

etc...

Here's the screengrab:

As you can see, the attachment is recognized by size and icon. MIME is also present (so I assume the message in the header doesn't correspond to my problem) and Opera is trying to display the image.pdf file as an image.

http://my.opera.com/tegehel/homes/files/1imagepdf.jpg

or (same, in case)

screengrab

I did some tests with the pdf I was able to save (the 2nd one I got), and renamed it "image.pdf" and sent it to myself. This time it worked properly.

I can conclude 2 things:

1) the first attachment was corrupt

or

2) the first attachment was not properly identified the first time, and the name of the attachment was shown in a box. (or is it really trying to show me an image? that's the confusing part.)


Since it shows the word "image" (which is the name of the .pdf attachment), I _assumed_ that it wanted to show me an IMAGE as opposed to just the NAME of the attachment (also image.) Now, I'm not sure.

Anyway, regardless, I think that in a case like this, Opera should show a SAVE ATTACHMENT button so we can save it, maybe rename it and try to open it with the proper tool.

Just for your information, the 2nd attachment, the one that worked, had this header:

--B_3239342472_8635071
Content-type: application/pdf; name="cyrilimage.pdf";
x-mac-creator="4341524F";
x-mac-type="50444620"
Content-disposition: attachment;
filename="cyrilimage.pdf"
Content-transfer-encoding: base64

I see the first one was missing the content-disposition header. The two legitimate dispositions are "inline" (if it's included in an HTML message, generally) and "attachment", Opera will tell you there is an inline file present in the list but won't list it where it normally displays attachments.

Even though the message wasn't HTML, seems like Opera decided the file should be handled as inline.

I think I'd report this as a bug to the Bug Tracker. They'd want a copy of the message for examination, I'm not completely certain but if you redirect (key D) the message to the email address they'll give you when you file the bug report, it might arrive reasonably intact. Include a link to this thread in your report though, in case there are problems. When you're done, also post just the bug number (not the full email address, we don't want people spamming the bug tracker) so that the Opera people here can check on it.

bug# 226450

Thanks for your help.

C.

I want to add that I had the same problem again with people sending me images (jpeg) that aren't properly recognized.

All the problems I had occured when the sender is on a MACINTOSH. I have a PC.

Might be a coincidence, but I start to believe that due to the repetitiveness of the problems, it is not.

C.

May be not so much the platform as the client. That is to say, I'm certain that if they were using Opera for Mac, everything would work fine. I'd also bet that Thunderbird will work fine.

That first message you quote identifies the sender's program here ...

Originally posted by tegehel:

User-Agent: Microsoft-Entourage/11.2.1.051004

Yes, you're probably right.

Just for information, this is another, different example of attachement (from a different sender) that doesn't work properly. The weird thing is that it recognizes it as a .jpg in the header, obviously, but doesn't show any image, nor any save button.

You will notice that this one doesn't show any User-Agent. But from the info, it's also a MAC.

---

Return-Path: <email@address.com>
Received: from XXX.cox.net ([0.0.0.0)
by fed1rmmtai16.cox.net
(InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP
id <20060830161149.LKUK5085.fed1rmmtai16.cox.net@fed1rmimpi01.cox.net>
for <email@address.com>; Wed, 30 Aug 2006 12:11:49 -0400
Received: from XXX.atl.sa.earthlink.net ([0.0.0.0])
by XXX.cox.net with IMP
id GG3K1V01f1KR6yR0000000
Wed, 30 Aug 2006 12:03:23 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=dk20050327; d=earthlink.net;
b=kvUUbertfHpZJxOd716QvaJjJNF2z9USIV2E56pZeb4jmIz0eO8QJNRZJ75XZj0L;
h=Received:Mime-Version:To:Message-Id:Content-Type:References:From:Subject:Date:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [0.0.0.0] (helo=[0.0.0.0])
by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34)
id 1GISbF-0005RJ-EQ
for email@address.com; Wed, 30 Aug 2006 12:11:44 -0400
Mime-Version: 1.0 (Apple Message framework v728)
To: XXX <email@address.com>
Message-Id: <EC382DAF-920C-442C-956F-81CE3A2C3585@earthlink.net>
Content-Type: multipart/alternative; boundary=Apple-Mail-6-405521650
References: <C11A2DF2.1FC94%email@address.com>
From: XXX <email@address.com>
Subject: XXX.
Date: Wed, 30 Aug 2006 12:04:24 -0400
X-Mailer: Apple Mail (2.728)
X-ELNK-Trace: 13db277d4c121795d780f4a490ca69563f9fea00a6dd62bc38c62fbb4b04e6540f712437bb719c88350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 4.154.254.236


--Apple-Mail-4-405170879
Content-Id: <37593874-F530-446B-AB9E-CF5BB4D9BE51@local>
Content-Type: multipart/appledouble;
boundary=Apple-Mail-5-405170880
Content-Disposition: inline


--Apple-Mail-5-405170880
Content-Transfer-Encoding: base64
Content-Type: application/applefile;
name="VSpec03.jpg"
Content-Disposition: inline;
filename="VSpec03.jpg"

/9j/4AAQSkZJRgABAgEAZABkAAD/7RWmUGhvdG9zaG9wIDMuMAA4QklNA+kKUHJpbnQgSW5mbwAA
AAB4ACgAAABIAEgAAAAAAucCUv/3//cDDwJbIAIFKAP8AAAAAAFoAWgAAAAADoMLmgF0ADILmkio
AEsAAQEBAAAAAScPAAEAAQAAAAAAAAAAAAAAAAAAAAAPAAAAAAEAZAEAAAAAAAAAAgEgsAUEIgAA....etc.....

I also have had problems with attachments, especially when the sender used Apple Mail (I assume this is a Mac email program, since I use only Linux or Windows). As you can see in the previous postings, the attachments are embedded really strangely with one "container" inside another and then the several parts in this second container.

I don't know if this is a bug in M2, and I agree that Opera needs an attachment button even if it is included inline. But with Opera 9.0+ this is quite easily fixed for an individual mail, because every mail is stored in its own .mbs file.

To make a "corrupt" attachment downloadable, follow this steps:

* Write down the date of the mail and the size.
* Close Opera, then go to your opera profile\mail\store\account\year\month\day folder and look for a .mbs file that is about the correct size. (If you have several accounts, you can see which account is which in the accounts.ini file in the profile\mail folder.)
* Open the .mbs file with a text editor. You can scroll down a bit and see if this is the correct mail.
* Change the headers a bit. I'm going to use tegehel's last example to show what to change:

Change the first Content-Type in the header:
Content-Type: multipart/alternative; boundary=Apple-Mail-6-405521650
to:
Content-Type: multipart/mixed; boundary=Apple-Mail-6-405521650

You can see that every part (as in: text, html, attachments) is separated by the given boundary, here: --Apple-Mail-6-405521650

Find the part in the mail where the attachments begin. You will see a second "container" with another boundary defined, in this case:
Content-Type: multipart/appledouble; boundary=Apple-Mail-5-405170880

In my own mail instead of "appledouble" there was "mixed". But it doesn't matter, because we changed the first content type already to mixed, so we don't need this container. So you can delete this whole section:

--Apple-Mail-4-405170879
Content-Id: <37593874-F530-446B-AB9E-CF5BB4D9BE51@local>
Content-Type: multipart/appledouble;
boundary=Apple-Mail-5-405170880
Content-Disposition: inline

In subsequent boundaries, change the second, now invalid boundary (--Apple-Mail-5-405170880) into the first one (--Apple-Mail-6-405521650) in every attachment.
I just saw that in this example there are even boundaries that are not defined anywhere (--Apple-Mail-4-405170879), so this mail is completely f'ed up, but this should normally not be the case.

You should also change the
Content-Disposition: inline
to:
Content-Disposition: attachment

Go through the whole mail and replace all --Apple-Mail-5-... with the --Apple-Mail-6-... boundary.

* After this, save the file and open Opera, and now you should have an attachment button in your mail.
* As the boundary name can be anything, it can of course vary in your mails, but you should be able to find the correct lines quite easily.

For clarification I'm going to post parts of tegehel's last mail below, with the necessary changes in bold and deleted parts like this. In my corrupt mails there were sometimes several more boundaries with HTML and other useless stuff, which you can keep or delete, it shouldn't matter. Maybe you have to change the Content-Type of the attachments if it doesn't work. Instead of "application/applefile" for example "application/jpeg", but I'm not sure if this is needed.

---

[...]
Mime-Version: 1.0 (Apple Message framework v728)
To: XXX <email@address.com>
Message-Id: <EC382DAF-920C-442C-956F-81CE3A2C3585@earthlink.net>
Content-Type: multipart/mixed; boundary=Apple-Mail-6-405521650
References: <C11A2DF2.1FC94%email@address.com>
From: XXX <email@address.com>
Subject: XXX.
Date: Wed, 30 Aug 2006 12:04:24 -0400
X-Mailer: Apple Mail (2.728)
X-ELNK-Trace: 13db277d4c121795d780f4a490ca69563f9fea00a6dd62bc38c62fbb4b04e6540f712437bb719c88350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 4.154.254.236

--Apple-Mail-4-405170879
Content-Id: <37593874-F530-446B-AB9E-CF5BB4D9BE51@local>
Content-Type: multipart/appledouble;
boundary=Apple-Mail-5-405170880
Content-Disposition: inline


--Apple-Mail-6-405521650
Content-Transfer-Encoding: base64
Content-Type: application/applefile;
name="VSpec03.jpg"
Content-Disposition: attachment;
filename="VSpec03.jpg"

/9j/4AAQSkZJRgABAgEAZABkAAD/7RWmUGhvdG9zaG9wIDMuMAA4QklNA+kKUHJpbnQgSW5mbwAA
AAB4ACgAAABIAEgAAAAAAucCUv/3//cDDwJbIAIFKAP8AAAAAAFoAWgAAAAADoMLmgF0ADILmkio
AEsAAQEBAAAAAScPAAEAAQAAAAAAAAAAAAAAAAAAAAAPAAAAAAEAZAEAAAAAAAAAAgEgsAUEIgAA....etc.....

This is a great trick, thanks a lot.

I confirm once again, the problem continues with attachments sent from a Macintosh. I keep getting stuff sent to me by Mac users and some have that problem. The thing is, not all Mac attachments are problematic, so I assume it depends on the email program used on their ends? hard to pinpoint.

C.

Another MAC problem - similar but slightly different. Although there's no headers about it, the sender told me it's from a MAC.

In this case, note that the attachment is recognize as a .jpg, but not shown properly again.

In my email, under Attachments, you see the name of the attachment with the wrong suffix, like this:

Attachments: test.tmp (it should be test.jpg)

If you click on that, the menu with open..., save to folder or save as...appear, but they don't do anything, i.e, they don't open, and worse, they DON'T SAVE anything at all.

I can't figure out how to "fix" this one, due to the very limited amount of info.

-------

Return-Path: <email@address.com>
Received: from centrmimpi02.cox.net ([68.111.106.85])
by centrmmtai03.cox.net
(InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP
id <XXX.cox.net@centrmimpi02.cox.net>
for <email@address.com>; Thu, 14 Sep 2006 12:12:44 -0400
Received: from XXX.com ([12.42.246.27])
by centrmimpi02.cox.net with IMP
id NG6L1V03x0cBqQC0000000
Thu, 14 Sep 2006 12:06:26 -0400
Received: from unknown (XXX.hbpub.com) ([10.8.0.110])
by XXX.hbpub.com with ESMTP; 14 Sep 2006 12:12:12 -0400
Received: from [0.0.0.0] (0.0.0.0 [0.0.0.0]) by XXX.hbpub.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
id 38RK7SX4; Thu, 14 Sep 2006 12:16:57 -0400
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Thu, 14 Sep 2006 11:54:18 -0400
Subject: Re: XXX
From: XXX <email@address.com>
To: XXX <email@address.com>
Message-ID: <C12EF36B.222AE%email@address.com>
In-Reply-To: <op.tfvjqzgxhlzuuk@cyril>
Mime-version: 1.0
Content-type: multipart/mixed; boundary="B_3241079660_31480741"

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

--B_3241079660_31480741
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

Hmmm...let me know if this comes through.



--B_3241079660_31480741
Content-type: application/octet-stream; name="test.jpg"
Content-disposition: attachment
Content-transfer-encoding: base64

/9j/4AAQSkZJRgABAgEAyADIAAD/4RQWRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEa
AAUAAAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAU
AAAAjodpAAQAAAABAAAApAAAANAAHoSAAAAnEAAehIAAACcQQWRvYmUgUGhvdG9zaG9wIENT
MiBXaW5kb3dzADIwMDY6MDk6MTAgMTM6MTU6MDkAAAAAA6ABAAMAAAABAAEAAKACAAQAAAAB....

This doesn't seem to be the same problem as the other ones. But you could try to fix it by changing this line:
Content-type: application/octet-stream; name="test.jpg"
into:
Content-type: image/jpeg; name="test.jpg"

in your .mbs file.

Bingo! it worked.

I think I start to understand the logic behind the fixes...I think.

Thanks, GKiller.

I too, regularly get Word, PDF and JPG files sent as attachments from a Mac using client. I assume the header is non standard in some way (see example below). Anyway, the outcome is that the message displays no indication that there is an attachment. The only clue is to look at the file size in the message list, or look at the raw view.

Quite by chance, I found a simple solution to making the attached files accessable. I redirect the message to myself. When I receive the redirected message, I delete the original. Works every time, and is easier than editing the .mbs file

Note: Use redirect, and NOT forward.

Return-Path: [client addr]
Delivered-To: [my addr]
Received: ([server application]); 10 Aug 2006 03:50:52 -0000
Received: from [client IP addr]
  by [my mail server] with SMTP; 10 Aug 2006 03:50:52 -0000
Mime-Version: 1.0 (Apple Message framework v752.2)
To: [my addr]
Message-Id: [message ID]
Content-Type: multipart/alternative; boundary=Apple-Mail-34-782241838
References: [Prev. message ID]
From: [client addr]
Subject: Fwd: sample pdf
Date: Thu, 10 Aug 2006 16:11:40 +1200
X-Mailer: Apple Mail (2.752.2)


--Apple-Mail-34-782241838
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=UTF-8;
delsp=yes;
format=flowed

Quikman,
Wait for the info from Barbs and it will all make sense. 
[rest of message]

quikman, thanks for the tip. In my case, unfortunately, it doesn't seem to work. It does change the headers indeed, but not correctly and the attachment is still screwed up. The difference is that with some emails (I tried a couple of different ones), the attachment button does show up after a redirect, but it is still does not re-create a valid attachment solution.

I will continue to try that trick though, maybe it will work in certain cases.