If an email is attached to another message, and is opened (by double-clicking in the Attachment list), the new email opens into its own message window, with a header pane and a toolbar. (This is an improvement relative to 1.3.) The headers are correct (unlike the situation described in bug 200380). However, there are a few things wrong with this window: 1) It shows an attachment -- which is, in fact, the message itself. 2) View|Source is disabled. 3) View|Headers is not disabled, but does not function as expected: the displayed message continues to show whatever headers it was opened with. (A non-attachment email opened in a message window will expand/contract its header pane to follow selections from its own menu.) 4) Most of the toolbar icons are disabled. Perhaps this is by design, but I don't see why Forward, at least, if not Reply & Reply All, shouldn't be enabled. Of course, those functions should act on the viewed (attachment) message, not the container message back in the 3-pane.

Hardware/OS -> All. (Seeing this on Mac build 2003-04-19-03.)

Symptom (1) of this bug is a duplicate of bug 203570. The rest of this bug appears to recommend the opposite tack from bug 201881.

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

Yes, many people suggest the attached message shoudn't be aditable, forwardable, editable. Maybe it is really nonintuitive or doesn't make sense. Is it normal to send someone a reply to a message someone else sent you as an attachment? The final recipient may be a bit puzzled. Some people would like this feature just for their internal mail management needs. My suggestion is: if the proposal of disabling everything comes through, the eml import feature will come handy (bug 193281). If someone still wishes to edit an attached message, he can save it to disk, immediatelly import into his inbox and edit (reply) it. I think both parties would be satisfied.

I could live with that; but I do think View|Source and Forward are sensible functions to execute directly on the attachment. For instance, you receive a message with a forwarded suspect spam/virus email attached; in this case, you might want to examine the source yourself, or you might want to forward the suspected mail (only) to a designated spam/virus handler. View|Headers, too, altho overall I favor bug 154712 regarding that function.

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

What would someone want to reply to a message not sent to them originally for ? How about sales leads or support emails forwarded as attachments? I get this stuff regularly.. I really like thunderbird but it is a *pain* to reply to these types of emails in it ! It would be great to see the reply button work in forwarded texts.

Adding dependency on bug 218912 -- that bug notes that Edit As New doesn't work for the messagewindow containing the attachment.

I have seen several instances where it takes Digested mailings, and you have the main window contain all the text, as well as have several attachments, one for each email msg. When I click on the attached msg that I want to reply to, I can't forward it. To do so, I have to cut and paste the correct address, AND edit the full msg to get what I want to. Definately more work than is necessary. Fixing this bug would aleviate that. I attached a saved example of one of the msgs that is experiencing this issue, saved from within Thunderbird. Hopefully, its intact.

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

Also note that Message -> Copy and Move are enabled but nonfunctional. There are enough 'glitches' relating to this window that it might be appropriate to spin off individual problems into separate bugs. Adding some keywords to summary. Old summary: Opening attached email shows a message window with glitches

Adding some such pre-existing bugs to block-list. Also see bug 76253, whose comment 9 claims the attached patch will fix view source for attachments.

Adding dependency on bug 3901: "want ability to forward message/rfc822 attachments"

at least for mailman (list-software) it does make sense to be able to answer mime parts because mailman attaches confirmation messages to requests and the listadmin must be able to answer those mime-attachments. So I really see the need for at least forward and reply options for mime parts of multipart messages.

Please add "message/rfc822"(at least "rfc822") in summary for ease of search. (I have no previridges for it)

Also the "Go -> (Previous|Next) Message" (menu|toolbar|keyboard shortcut) items are disabled. Dunno how feasible this would be, but: in the case of listserv digests, having this open the (previous|next) *attached* message could make for a pretty convenient to "undigestify" on the fly...

(In reply to comment #17) > Also the "Go -> (Previous|Next) Message" (menu|toolbar|keyboard shortcut) items > are disabled. This should be, I belive. Since this is display of "attachment", "previous/next message" has no meaning, although data format of message/rfc822 is completely same as a mail in a mail folder except mail separator in unix mbox file is not contained. I think different window(design/menu-iem/logic/function) should be used for attached message/rfc822 from real mail display, because message/rfc822 attachment is not a real mail and has both "attached file" and "mail" characteristics. And if this type of change will be done, ".eml" file support will be automatically included in Mozilla Mailnews and Thunderbird.

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

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

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

2004040608-trunk/Win-2K(SP4) always displays message/rfc822 attachment in format of "Message body as HTML"(I can not say which of Original or Simple), and "Display Attachments Inline", and these View menus are killed - can be changed but display format will not be changed. Does this bug cover this problem too?

See bug 241213.

Looking over the *numerous* posts and user requests this topic has generated, it seems obvious to me that this 'bug' needs a solution which both sides. It is obvious that the ideas on the topic whether to have the reply/forward/view source/... functions for attached/imported emails activated or inactivated are diverted. For this reason, I think the best and only possible solution is to let the user decide and make the more secure setting the default. This would mean that the default setting should be that these options are deactivated for attached RFC822-cmpliant mime-parts but should be activatable by editing the user preferences config files. I think everybody would be happy with this solution (except the developers, maybe, as this sounds like a lot of work to me ;) ).

I just don't see the "security" aspect to this. A message/rfc822 attachment is a complete message, with headers. T'bird knows this, and displays it correctly. It violates the "principle of least astonishment" to treat this message any different from any other message in the inbox. It is a fully- formed message: I should be able to do to it anything that I could do to an inbox message: read, reply, forward, save-as, etc. If someone does not want to reply to attachment messages, then I strongly suggest they not click the "reply" button when viewing one. It makes zero sense to disable the option.

(In reply to comment #25) > I just don't see the "security" aspect to this. A message/rfc822 attachment > is a complete message, with headers. T'bird knows this, and displays it > correctly. It violates the "principle of least astonishment" to treat this > message any different from any other message in the inbox. It is a fully- > formed message: I should be able to do to it anything that I could do to an > inbox message: read, reply, forward, save-as, etc. I second that. It is a power user feature, but harmless for the "unknowing". For what it is worth, pine does exactly what this bugs requests for mozilla/thunderbird. An attached e-mail is an e-mail, and you can do with it what you can do with an e-mail, especially save to a folder and reply. It is one of the things which makes me go back to pine quite often (others being "bounce" and "delete attachment"), and which keeps power users (mutt...) from switching to moz.

(In reply to comment #25) > If someone does not want to reply to attachment messages, then I strongly > suggest they not click the "reply" button when viewing one. It makes zero > sense to disable the option. Yeah! Give us the freedom to reply to attached mails. PLEASE!

Can someone briefly explain *how* the disabling of "reply", "forward" buttons, etc, is implemented? I can look at the XUL of the message window with the DOM inspector and see that the toolbarbutton "button-reply" and see that the "disabled" property is "true" for rfc822 attachments, but where in the javascript (or perhaps in the C++) of the mailnews component is this done? I'd like to try to help fix or at least understand this bug (and other message/rfc822 attachment bugs).

(In reply to comment #28) > Can someone briefly explain *how* the disabling of "reply", "forward" buttons, > etc, is implemented? Patch for bug 143565 is probably root of disabling, because bug 143565 is set as depends on bug of bug 203570, which is opposite one to this bug. See Comment #2 From Mike Cowperthwaite.

Thank you, Wada, for your pointers. The disabling logic is really just one line, right here : http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/messageWindow.js#737 Of course, it won't work to simply disable this check. Rather it seems that we need to somehow allow attached messages to be registered with a key in the gDBView.

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

(In reply to comment #7) > What would someone want to reply to a message not sent to them originally for ? For instance, when replying to a message from a mailing list, which was bundled in a MIME digest (e.g. mailman): 1) The To: is the address of the list, i.e. not-me. 2) This message gets forwarded to me 3) I _want_ to reply to it, and there is nothing wrong about this being possible.

FWIW - Bug 201881 Comment 8 suggests Bug 201881 be marked WONTFIX due to the number of votes here for this bug, bug 204350.

Adding dependency on bug 310264, which wants to be able to print an attached message.

In the case you working in a teams,some time when you talking about something, but you find that some other persons not in the thread are the right persons to answer some questions, what will you do? I will forward some mail to him and would like to get him jump in the thread. Then we need at least let him reply/print the forwarded mails.

with this patch, thunderbird supports reply + forward as attachment and inline for message/rfc822 attachments opened in a stand-alone msg window. It also fixes some problems displaying inline attachments in those messages, and .eml files opened from the command line. It doesn't handle view source or a couple other things, like show all/normal headers, but it's a step in the right direction.

Comment on attachment 200351 [details] [diff] [review] support reply/forward (as attachment and inline) for message/rfc822 attachments + rv = NS_NewURI(getter_AddRefs(uri), messageURI.get()); + NS_ENSURE_SUCCESS(rv, rv); + if (aURL) + NS_IF_ADDREF(*aURL = uri); Is it ever possible that a user could pass in null for aURL? Is it an optional argument? If it is supposed to be non null, we could check the arg ptr at the beginning of this method and then just pass aURL directly into NS_NewURI.

it can and often is null - many callers don't care about the resulting uri. But I need to create one there and open the channel on it...

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

forgot this part of all this work - this uses a method on nsIMessenger to get the hdr, because that knows how to use the dummy header...

Is any part of the patches for this bug Thunderbird-only, or is it all Core? The TB bug for this issue is bug 224967. The fix (as seen in TB 1.6a1-1028) is working about as well as the equivalent fix for .EML files in a standalone message window: - Reply, Reply All and Forward are working; likewise: Edit as New. - Print Preview and Print are working, except they show message source rather than as-displayed, including showing binary attachments in all their BASE64 glory. (Compare to the same situation for .EML, which crashes on Print.) See bug 268746 comment 11 and 22. The symptoms from bug 314349 and bug 314351 apply to this bug's fix.

(In reply to comment #41) > Is any part of the patches for this bug Thunderbird-only, or is it all Core? > The TB bug for this issue is bug 224967. I was wondering the same thing when I saw it wasn't "Core", but "Mozilla Application Suite" under "Product".

Attachment 201005 [details] [diff] was checked in yesterday; it fixed bug 231282, at least for Thunderbird.

(In reply to comment #41) > Is any part of the patches for this bug Thunderbird-only, or is it all Core? Finally testing with a Seamonkey trunk build (1.5a-1211), all the items fixed here for TB are also fixed in Seamonkey. > - Print Preview and Print are working, except they show message source rather > than as-displayed, including showing binary attachments in all their BASE64 > glory. I still see this with TB 1.6a1-1201, but Seamonkey 1.5a-1211 handles this correctly. > The symptoms from bug 314349 and bug 314351 apply to this bug's fix. 314349 is TB-only. I did some work on another bug recently that made me think the problem in 314351 is just one symptom of a larger problem, unrelated to whether the message in question is an attachment or .EML file. (In reply to comment #43) > Attachment 201005 [details] [diff] [edit] was checked in yesterday; it fixed bug 231282, at > least for Thunderbird. This also is fixed for Seamonkey. I'm moving this bug to Core. Outstanding features still unimplemented are: View | Source View | Character Encoding View | Headers, Message Body As, Display Attachment Inline File | Save As Message | Copy Thanks again for all the effort, David!

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

Requesting a block on 2.0 as attachments should all be working properly in a product of this age.

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

Comment on attachment 200351 [details] [diff] [review] support reply/forward (as attachment and inline) for message/rfc822 attachments would be nice for 2.0

Comment on attachment 201005 [details] [diff] [review] front end part hopefully these patches reflect all the changes we (well you) made on the trunk for this stuff :)

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

In TB 3.0a1 20060311 ("trunk"), I was just able to forward a forwarded message :) The "fix" seems to be attached to some other bug, but I thought I'd note it here because the bug I filed for that issue, specifically, was marked as a duplicate of this bug.

When I attempt to use the reply or forward functions on an open attachment (usually an attached message that's part of a digest), it doesn't work, as others have reported. I haven't noticed anybody mention the error message associated with this problem that shows up in the Javascript console. It is: Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIMessenger.msgHdrFromURI]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: chrome://messenger/content/mailCommands.js :: ComposeMessage :: line 207" data: no] Source File: chrome://messenger/content/mailCommands.js Line: 207

David, there are still some major issues left. I've currently checked replying to an attached message with version 2 alpha 1 (20060511) and noticed following issues: * The originally subject is not filled in correctly. I only have "Re: " * The "To" field is empty - no recipient is filled in (perhaps the same when using Reply-All to answer a group of recipients) * Default identity is used instead of selecting the my other identity where the original message was sent to * Due to the missing sender information a wrong introduction is added to the message body ("meinte am 20:59:"). There the senders name is missing and the date is also totally wrong. It seems that most of the fields aren't initialized correctly. To comment 52: You have to use a nightly build to check this function. By using the 1.5 release I also get this javascript exception.

(In reply to comment #53) > * The originally subject is not filled in correctly. I only have "Re: " > * The "To" field is empty - no recipient is filled in (perhaps the same when > using Reply-All to answer a group of recipients) Do you see these symptoms for *all* messages, or are they specific to certain messages with (e.g.) MIME-encoded headers? See bug 314351. > * Default identity is used instead of selecting the my other identity where > the original message was sent to Please open a separate bug for this item. > * Due to the missing sender information a wrong introduction is added to the > message body ("meinte am 20:59:"). There the senders name is missing and the > date is also totally wrong. This might also warrant a separate bug, and a sample message would be useful. > To comment 52: You have to use a nightly build to check this function. By > using the 1.5 release I also get this javascript exception. Right: that was bug 231282, fixed only on the trunk. In fact, you can't reply to an attached message unless you're using the trunk.

I go to forward a message, and the body is now blank. There isn't even an attachment.

(In reply to comment #41) > - Print Preview and Print are working, except they show message source rather > than as-displayed, including showing binary attachments in all their BASE64 > glory. I've opened bug 338586 about this problem, which is Core.

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

I think I am still seeing something related to this. I have attached messages coming in as a .msg file. when I try to open it, I get a blank message window. With 1.5 I can't save the message either, but with 2.0 latest nightly, it creates a blank file (one step more than 1.5 does). The crazy thing is that I export a message to a .eml file then rename it to .msg and send it to myself as an attachment. . .same blank window happens. It should just open the file like a normal email (yes, it is rfc822) or at least prompt to save if it doesn't know what to do with it. . .

(In reply to comment #58) >I have attached messages coming in as a .msg file. File of '.msg' extention related issue (not supported yet then funny behavior) is Bug 350819 as you already know, isn't it? (you posted Bug 350819 Comment #6 at 2006-09-09 21:26 PDT)

You are correct, I posted that one as well. It seems to be related in some ways to both bugs it seems, but probably more directly to the other. These .msg files I am talking about are really rfc822 messages so they should show inline too. Anyway, was trying to find the correct related bugs

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

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

When viewing a message that has message/rfc822 attachments in 3-pane window, the message/rfc822 attachments are usually displayed inline. It would be very useful feature if each inline displayed attachment had links with basic functionality added to it (replay/replay all/forward/print/save as). For example, as the last line in the headers display: ===== From: To: Subject: Date: reply | reply all | forward | print | save as Here comes the attached message body ===== When reading mail list digest, I don't see a need to force user to open message/rfc822 attachment to be able to reply to it. In case of large digests, hunting to find right attachment to open (in order to be able to reply to it) can be hard.

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

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

This is still not entirely resolved in 2.0. I am now able to reply, forward and edit as new, but copying or moving the message to a mail folder does not work, although the menu is available (Message -> Move/Copy).

Would be nice to at least be able to copy (move should be possilbe too). . .I know I used to use this with OE years ago. . .

When double-clicking on an .eml attachment, the forwarded message comes up in a separate message window. Account settings are compose and send as HTML, message body displayed as original HTML. Forwarding the attached message from that window causes the following encoding errors: (1) If the message itself has an attachment, it shows up in the attachment pane of that window. When forwarding this message directly from an IMAP folder, and the message's attachment was not previously downloaded, the message's attachment is not included. The MIME headers in the forwarded message are correct, but the corresponding MIME part contains only the string "This body part will be downloaded on demand" regardless of the encoding. This is the case for both forwarding inline or as attachment from an IMAP folder. (2) If the forwarded message is multipart/related, contains text/html with embedded images, and is forwarded inline, the compose window indicates a broken image. When sent, the image is not displayed by the receiving e-mail client. Examining the message source shows (a) a link only if the message was forwarded from an IMAP folder; or, (b) if forwarded from a local folder, the complete forwarded message/rfc822 attachment as a second part (not displayed since the top-level MIME Content-Type is multipart/related, no attachment is indicated). The format in case (b) is similar as if the .eml attached message was forwarded as attachment (in which case the top-level type would be multipart/mixed and therefore displayed correctly). Also, the "cid:" identifiers are not matching between the main message part and the embedded image in the message/rfc822 attachment. Wrong image link for case (2a): <img moz-do-not-send="true" src="imap://..." alt=""> Wrong message structure in case (2b): > multipart/related; >> text/html; >>> [added text] >>> [headers of forwarded message] >>> [text of forwarded message] >>> [image src="cid:part1.x"] >> message/rfc822; >>> multipart/related; >>>> text/html; >>>>> [text of forwarded message] >>>>> [image src="cid:part1.y"] >>>> image/{png,gif,jpeg}; >>>>> [image in base64] Content-ID <part1.y> See http://forums.mozillazine.org/viewtopic.php?t=589399 for the corresponding discussion in the MZ forum. Verified in current Thunderbird 2.0.0.6 and SeaMonkey 1.1.4 releases (WinXP/Linux).

Part (1) of comment #73 is similar to bug 392545, where the issue was seen in direct attachments, thus it may not be caused by an attached message. Part (2) of comment #73 is covered by bug 334166.

CC added.

Wouldn't block for this; blocking‑thunderbird3-

That 'View message source' feature really needs to be done! For example abuse departments are using thunderbird, and they are constantly receiving rfc822 attached spam mails, from which they need to see full headers.

Tsk, I don't see how bug 144276, bug 324774, and bug 369302 relate to the issue here. They are on general problems with forwarding message and breaking their encoding, not necessarily just from an attached-message window. Did you mean to establish a dependency with bug 307023 for those?

View source is now enabled and works fine in thunderbird. (Don't know what changed.) Disabled in seamonkey though.

(In reply to comment #83) > View source is now enabled and works fine in thunderbird. (Don't know what > changed.) Disabled in seamonkey though. Nice, this will help with eml's posted in bugzilla. A little scary though that this functionality has suddenly appeared. I seem to remember that this would be tough to implement.

View Source does work nicely -- for an opened .EML file (bug 241213). For an *attached* email, which is this bug, the View Source does open a source window, but it displays an HTML-source representation of the message (body only).

This automagically started working a while back. I can see the source for the attached part. (I'll test with a bigger selection of eml's Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4pre) Gecko/20100408 Lanikai/3.1b2pre ID:20100408151251 BTW, that's with "view attachment inline" and also just opening the attachment itself with "!viewing...inline"

Assigned to: David :Bienvenu - does that still apply?

Actually, i think we're done here. View source was the last piece, and that works fine now, even for attached .eml files like in comment 85.

Is there a separate Seamonkey version of this bug? In Seamonkey 2.21 on Win7 none of the reply, forward or show source commands seem to work for a message/rfc822 attachment to a Mailman mailing list digest which has been opened by double clicking on it. Right clicking on the attachment in the parent message and choosing 'View Source' does work.