Reproduction: - Open a URL to a single message in the browser, e.g. by loading an .eml file on the local harddisk. The test message should contain an attachment. Actual result: You see the msg in the browser content window, with headers in a grey table and attachments in a table at the bottom. Attachments are only listes, with their filenames, though - the attachment content is not accessible. Expected result: Attachment content accessible. Suggestion: Make the attachment / filename a link to the attachment in the mail store (I think IMAP allows to link directly to an attachment inside a msg, and the other protocols probably allow that, too. Credits go to Alfa <alfa21@softhome.net> for the suggestion. Implementation warning: The links should *not* be there - in the printout - when the message is sent out in this form, e.g. forwarded inline Not only are the URLs usually useless outside that profile, they may also contain information that the owner wants to keep secret, e.g. internal hostnames and usernames are considered sensitive information by some admins.

> Credits go to Alfa <alfa21@softhome.net> for the suggestion. See bug 11076 comment 74. Note that this bug is a workaround for bug 11076 - once the latter is fixed, we don't need this bug anymore.

(In reply to comment #0) > Actual result: > You see the msg in the browser content window, with headers in a grey table > and attachments in a table at the bottom. Attachments are only listes, with > their filenames, though - the attachment content is not accessible. Note that: Bug 174692 exists about the failure to display an image inline in the browser's display of an RFC822 message (and provides a workaround, from within the browser). Opening a .eml file via TB's or Mail/News's File|Open Save Message generates a similar display, only within a window frame that looks like a standalone message window. (Bug 241212) > I think IMAP allows to link directly to an attachment inside a msg, and the > other protocols probably allow that, too. Bug 11076 is, in part, about the failure for imap: URLs to resolve. Bug 2652 is about the failure for mailbox: URLs to resolve.

(In reply to comment #0) > Suggestion: > Make the attachment / filename a link to the attachment in the mail store > > Credits go to Alfa <alfa21@softhome.net> for the suggestion. hello again, tnx u for credits! :-) today I found a new work around to open attached files, it's easy: try to add to the end of the .eml path in the location bar ?part=1.2 to open the first file attached. example: file://<full_path_to_the_file>storedmessage.eml?part=1.2 if your .eml has more than one attachment, try =1.3 for the second file, =1.4 to open the 3rd, and so on... NOTE: do not open 1.1!!! I think it should be implemented like an anchor href=file.eml?part=1.$N around the filename listed in the known table. what about that? regards, Alfa.

(In reply to comment #3) > I think it should be implemented like an anchor href=file.eml?part=1.$N around > the filename listed in the known table. ADDENDUM: instead of this (actual behaviour): <table border="1"> <tbody> <tr> <td> <div class="headerdisplayname" style="display: inline;" align="right">file1</div> </td> <td> <table border="0"> </table> </td> </tr> </tbody> </table> try with this handmade Alfa21(TM) GPL :-D piece of code: <table border="1"> <tbody> <tr> <td> <div class="headerdisplayname" style="display: inline;" align="right"><a href="?part=1.2">file1</a></div> </td> </tr> </tbody> </table> NOTE: I've removed the second "td" with an empty table inside. You can test it pasting it into the text body of any .eml with a file attached, using a text editor. NOTE: check and eventually change the .eml Content-Type: text/plain in text/html to try it. bye, Alfa.

(In reply to comment #4) please add the code I wrote in the previous comment as patch.

*** Bug 280975 has been marked as a duplicate of this bug. ***

The code where this bug would be fixed can be found under http://lxr.mozilla.org/mozilla/source/mailnews/mime/emitters/src/nsMimeHtmlEmitter.cpp#441

That code there states: // Attachment handling routines // Ok, we are changing the way we handle these now...It used to be that we output // HTML to make a clickable link, etc... but now, this should just be informational // and only show up during printing // XXX should they also show up during quoting?" So might it be that this is intentional that there is no link?

(In reply to comment #8) > So might it be that this is intentional that there is no link? I do not understand why! if you make a link and you print it, the location path (AKA "href=") is not showed on the paper! on the paper you see only underlined filename.ext text in a table. anyway, the href is RELATIVE, not absolute! you can write href="?part=1.2" and it's not the end of the world if someone else will see it! this kind of links are NOT: <quote> internal hostnames and usernames are considered sensitive information by some admins </quote> so I do not understand why might it be that this is intentional that there is no link? regards, Alfa.

I don't know either. My quote above was not to say that this bug should not be implemented. E.g. we can special-case print mode etc. (I think).

not blocking 1.7.6

See also Bug 284381.

look at this "meta bug" related to rfc882 .eml bug https://bugzilla.mozilla.org/show_bug.cgi?id=269826

Alfa, this should be a duplicate of 284381(and there is a rough patch there). So would you like to close this bug and move your discussion there?

(In reply to comment #14) > Alfa, this should be a duplicate of 284381(and there is a rough patch there). So > would you like to close this bug and move your discussion there? I do not know why, but I've not the option to set this bug as a 284381 duplicate. anyway, nice patch-job Nian! ...waters are moving! ;-) this is a very old issue, look at dates in the metabug-linked bugs! I'm crossing my fingers!

If anyone doesn't agree the duplicate or have other opinion, pls. reopen it. *** This bug has been marked as a duplicate of 284381 ***