Mozilla Thunderbird 0.2a (20030808) Mac OS X 10.2.6 Thunderbird doesn't open .eml files yet (files with message/rfc822 MIME-type). We can write them (File -> save As -> File), but not read them back as Seamonkey could. Firebird can't read those files either, since it has no mailer build in. I'm now filing a bug for Firebird too. Either Firebird should display them (which means that it should parse them), or they should be handled by Thunderbird. Thunderbird should register itself as the default handler for these files, so double-clicking on the desktop will work. That's also how Firebird could route message/rfc822 data to Thunderbird (I'm filing a bug about it right now). I'm not sure if we need a File -> Open Message File entry, maybe we can leave that out. But it's rather silly that we can save a file, but not open them.
Firebird bug is bug 217150
I believe the severity should be elevated as this is more than a reading our own saved mail files. The MS mail products often send *.eml files as attachments and they are unreadable in TB untill this is resolved. Support is essential for TB to be a valid alternative to MS O or OE by corporate users.
No. The point is that opening *.eml files works in Seamonkey (which is both a mailer and a browser), but not in Thunderbird (this bug) or Firebird (obviously, b/c it doesn't have a mail-parser). The code is included in Thunderbird, it's just not hooked up yet. There's no File -> Open menu item for example, and there's no handler for opening the file when you dobule-click in the Finder / Explorer (I would only do the second). It's just one of the many fine points of the Seamonkey to Thunderbird migration that isn't done yet. Note: comment 2 refers to bug 11076. Bug 26201 works for me, but that might be b/c I'm on Mac OS X.
i don't see a menu in file / open menu item in seamonkey for opening an eml file from the desktop. Where is the code that does that which you say is part of the tree already? Thanks.
Regular 'Open File', but the catch is that it's in the browser, not the mailer. Not that I expect that we'll ever have this menu in T-Bird (fairly useless), but T-Bird is capable of showing this data, and we'll need to have hooks in the OS (for double-clicking on the desktop), and especially when double-clicking *.eml attachments.
this looks trivial to fix. thanks for the clarification. Note to self, need to write to: HKLM\Software\Classes\.eml with some default key that refers to thunderbird. Not sure what the value should be yet. Still investigating.
Target Milestone: --- → Thunderbird0.5
regardin this comment: "Note to self, need to write to: HKLM\Software\Classes\.eml" this needs to be fixed in Linux as well =)
I wouldn't get to excited about registry keys at this point - the user can easily associate the file types manually. At this point, the ability to execute "thunderbird myfile.eml" on Windows and Linux to view a saved email would be much appreciated (especially if it gracefully handled the likely situation that TB is already running)!
Forgive my stupidity; is this bug intending to also enable reading of UNIX mbox-style "^From " delimited mail files, or just individual messages?
"Forgive my stupidity; is this bug intending to also enable reading of UNIX mbox-style "^From " delimited mail files, or just individual messages?" ...just individual messages, that is the core of my request, either by doing thunderbird file.eml ( this allows double-clicking on the file, right? ) or going to File / Open Message and selecting a file. I imagine the tricky bit would be verifying that the file is actually an RFC 822 email message...
moving these bugs to 0.6
Target Milestone: Thunderbird0.5 → Thunderbird0.6
(In reply to comment #7) > this looks trivial to fix. Scott, could you please see bug 203570 too? Bug 203570 is a message/rfc822 attachment display problem of Mail&News and Thunderbird has same problem. Since message/rfc822 attachment in a mail is completely same as ".eml" file, if your ".eml" file handler can handle message/rcc822 attachment in ".eml" file properly, same logic can be used in message/rfc822 attachment handler in mail display.
One thing seamonkey can't do is allow the user to get at the attachements stored in .eml files. It tells you they are there, but gives no link to open them. This means that you once again have to revert to outlook express to properly access your saved email. Is adding this functionality to Thunderbird considered part of this bug? I believe that a File -> Open menu item is probably a good thing, by the way. I'd never use it myself, but I think it would be confusing to some to have Save but not open. Almost all other apps have the open/save pairing after all. Double clicking on a file or right-clicking it could be considered pretty advanced usage for many users. Slightly off-topic, and I apologise: At work we choose seamonkey over Outlook/IE for its security benefits. It now looks as if a policy is about to be brought in forcing us to give users access to Outlook Express just so they can open saved emails. This is verging a bit on the ridiculous and really highlights how fundamental this functionality should be to Thunderbird (except for sending and receiving emails, address books...oh never mind). :-)
(In reply to comment #14) > One thing seamonkey can't do is allow the user to get at the attachements stored > in .eml files. It tells you they are there, but gives no link to open them. That's bug 174692.
The Bat! also writes .msg files (which I am told is the same format.) It is used by many people on Mozillazine. (2nd to Thunderbird, I believe.) www.ritlabs.com/thebat
*** Bug 235315 has been marked as a duplicate of this bug. ***
I've already gotten part of this done already, but I've got a few questions: Can we confirm.eml, and .msg are the same format? AFAIK the answer is yes. Seamonkey, simply hides most headers, and uses a grey bar for subject, To, and from headers... Thunderbird of course should do better. Ideally, we want to pipe the message through: window.openDialog( "chrome://messenger/content/messageWindow.xul", "_blank", "all,chrome,dialog=no,status,toolbar", messageUri, folderUri, gDBView ); That way, it opens up into a new window. This is similar to the functionality of Outlook from what I can tell. From what I see, mailwindowoverlay.js is really oriented towards handling messages that are in the mail database. Not something from a remote file (perhaps the reason they did the above preview thing in SeaMonkey) It it possible to open directly from a file (without large amounts of code)? I would think it is, though can't find it. Also not quite sure what this is: http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/messageWindow.js#274
Status: NEW → ASSIGNED
I'll hope this comment is less arrogant than my last.. my apologies. I've filed a bug to put a file-->open command in seamonkey's mail program. http://bugzilla.mozilla.org/show_bug.cgi?id=235315 I think that as you have concluded, the "pairing" is neccessary.
Per discussion with David. I'm pretty much at a standstill here. Pretty much, it looks like we are assuming we always need a Folder, and calling GetLoadedMsgFolder. So I can never get past the following: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface]" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "JS frame :: chrome://messenger/content/messageWindow.js :: GetLoadedMsgFolder :: line 550" data: no] When trying to use: MsgOpenNewWindowForMessage() to display the message. That's a bit beyond my capabilities. I don't understand much of messageWindow.js to be quite honest.
Well, since this bug is currently at a standstill, I've implemented a work-around script for displaying archived *.eml files through a web browser. I've made it available <a href="http://www.avtechpulse.com/opensource/email.html">http://www.avtechpulse.com/opensource/email.html</a>. Hopefully other people will find it helpful. It works pretty well for me.
A couple of points that I think add to the urgency of this bug. 1) The proliferation of viruses at the moment cause many people (myself included) to filter mail through a virus checker or additional spam filter which cause the original email to be "quarantined" i.e. included as an attachment to a clean message. 2) This is a dataloss bug (albeit not a major one) as users have the ability to save to a .eml file, but then cannot read it again! The data is there, but is rendered effectively useless. It is quite concievable that a user might save a bunch of important emails as .eml, delete them from their Thunderbird Mailbox thinking them safe, and then having no obvious way of openeing them again. 3) This surely can't be a very hard fix - attached emails (which are .eml format) *can* be opened from within Thunderbird!
(In reply to comment #18) > I've already gotten part of this done already, but I've got a few questions: > > Can we confirm.eml, and .msg are the same format? AFAIK the answer is yes. If you take a look at the link from comment #21 it appears that they are *not* the same format. The perl script convertor may give a clue as to what needs to be done to do the conversion in Thunderbird, though perhaps this should be a separate bug filed in Seamonkey.
This is getting a little off-topic, but in the interests of clarity: 1) TB saves in *.eml format, which is a standard multi-part mime format. TB can not yet re-import these, but it is a standard format and many tools are available to manipulate multi-part mime files (for instance, perl MIME::Explode, http://www.avtechpulse.com/opensource/email.html) 2) Outlook saves in *.msg format, which is a proprietary binary format that TB can never hope to read. However, you can manipulate *.msg files with your own code to some extent using OLE scripts. See the msgconvert.pl script for a sample msg-to-eml converter (http://www.xs4all.nl/~mvz/software/msgconv/faq.html). 3) "The Bat" also uses a *.msg file extension - but I believe that this is a multi-part mime format (same as *.eml), and not the Outlook binary format. Let's hope that TB can soon open *.eml (multi-part mime) files...
Why is this classified as an enhancement?! This is a very serious deficiency that is one of the 3 reasons left that i've noticed why most people would not want to switch to TB from OE. Its severity should be labeled "major". (The other two are http://bugzilla.mozilla.org/show_bug.cgi?id=216033 and several severe deficiencies in TB's Search Messages function)
(In reply to comment #25) > Why is this classified as an enhancement?! This is a very serious deficiency > that is one of the 3 reasons left that i've noticed why most people would not > want to switch to TB from OE. Its severity should be labeled "major". Read: http://bugzilla.mozilla.org/bug_status.html#severity for the description on the severity categories. This is unquestionably an enhancement. As soon as someone clears bug 236637 out of the way, this will be resolved. I just about have a patch, minus localization (no big deal), and that blocking bug.
Robert, I was thinking about this and I wonder if it might be easier to just go ahead and create a folder internally, but not have it show up in the UI - this might be tricky, I'm not sure. Can you attach your patch so far, and I can see if I can tweak it to create a folder to keep messageWinow.js happy.
Created attachment 145059 [details] [diff] [review] Patch v1 Work in progress David, Patch so far, note it may cause bustage, do *not* use while operating heavy machinery. It's rough, I'm a little busy for most of the evening, and a good part of tomorrow, and most of thursday... so if I'm slower than usual to respond, harass me via IM ;-). That always gets a response.
Created attachment 145221 [details] [diff] [review] proposed fix I took Robert's patch and fixed the part where the rubber hits the road (I had some trouble just applying the patch so I may have removed more than I should have, or you may have put in more than you intended...). This patch has some extra dump statements that I should remove, but it does work. The biggest trick was appending "?type=x-message-display" to the url - the messageWindow.js code already knows how to handle that, in order to display .eml attachments when they're double-clicked on. Because Robert's patch was passing the uri around as a string instead of a real uri, I had to handle that in messageWindow.js - if we had a real uri, the change in messageWindow.js wouldn't be needed...
Created attachment 145225 [details] [diff] [review] better fix this patch cleans up the dump statements, and creates a real uri - and it still works :-)
Comment on attachment 145225 [details] [diff] [review] better fix there is some bogus select all stuff in this patch that should be removed. That's leftover from another project Rober and I were working on :) Your missing a line return here: </menu> <menu id="fileAttachmentMenu" So this patch adds a new top level menu item under file for Open Message? I didn't see any DTD changes for openMessageFileCmd. I wonder if File / Open needs to have a fly out menu with two options one for opening a message and one from opening a message from a file....hmmm
Created attachment 145240 [details] [diff] [review] fix addressing scott's comments. I fixed the newline, removed the select all, and added the dtd to the diff.
I don't know about the file open flyout either - any comments, Robert? It does allow you to open the message in a new window, so it doesn't seem that bad to me.
(In reply to comment #33) > I don't know about the file open flyout either - any comments, Robert? It does > allow you to open the message in a new window, so it doesn't seem that bad to me. Actually, I wanted to bring this up. I thought the flyout is th best decision for now, but I want to propose a change: I think ultimately, "Open Message" should be renamed "Open Message in New Window" and be in the "Message" menu, since it relates to what to do with the current message. Then remap that current Open Message to the new functionality covered by this bug. The current functionality isn't right, since the file menu is really for interactions between the application and the OS (Open, Save, Print Quit). Scott, What do you think about this change? Should I go for it? I think 99.9% of users wouldn't even notice. Since most will either double click the message, or use a key combo. Not go to the file menu. It's out of place, so lets fix it.
Scott, FWIW (in light of previous, private mail suggestions I've made on menus) I would recommend putting any 'Open in new window' item in the Message menu, and putting the 'Open from file' item under the File menu. -Ran
I think we should do this (building off both of your suggestions) Under the Messages Menu, after "Edit Message as new" should be a menu item called: "Open Message" (I don't like Open Message In New Window, it is too long). Besides, you could be configured to open into an exisitng message window and not a new one. Keep the current accelerator and shortcut with this item for now. Under File, after the New menu item, add a menu item called "Open File" with a menu accelerator value of 'O'.
I'll try to make that change tonight.
Created attachment 145303 [details] [diff] [review] Patch v2 Patch reflecting new menu changes. This patch works for me. Hopefully I diff'd correctly.
Attachment #145240 - Attachment is obsolete: true
Attachment #145303 - Flags: superreview?(mscott)
Comment on attachment 145303 [details] [diff] [review] Patch v2 you missed the access key for the open file context menu item, but I can easily add that when I check this in (unless David beats me to it) Your change plus David's code looks good to me now. Thanks David and Robert.
Attachment #145303 - Flags: superreview?(mscott) → superreview+
mscott says this string change shouldn't impact seamonkey users so a=asa for checkin to 1.7.
Scott, Should we port this over to SeaMonkey after the tree emerges from the deep freeze? Or will this be Thunderbird only?
No longer depends on: 236637
Created attachment 145306 [details] [diff] [review] Patch v2 Alternate Ending They say all good movies are filmed with alternate endings. All good bugs have alternate endings as well. Just when you thought it was over :-D [Insert somewhat sinister theatrical, yet geeky laugh here] I present to you a slightly modified patch. This version should save the location thanks to some code I got from editor. Good for when opening more than one email. That's the only ting I changed. Other than that, it should be exactly the same.
Comment on attachment 145306 [details] [diff] [review] Patch v2 Alternate Ending mscott, It's an alternate ending, and your the director. What shall we show the viewers?
Created attachment 145320 [details] [diff] [review] even better patch I made several changes to the patch: 1) added the access key for File Open 2) We already had a string property for the Save Message As dialog for the file picker's "filter" criteria: EMLFiles=Mail Files (*.eml) We should be using that instead of adding a new string called Email Files like we were doing. 3) There was no title text getting applied to the file picker dialog. The original patch was using a hard coded string called "Open". I added a new string property to give the file picker dialog a titled called "Open Message". I decided to forgo the folder directory pref stuff for now. attaching this new patch in case someone does end up porting this back to seamonkey. They'll have the final stuff to compare to.
Comment on attachment 145320 [details] [diff] [review] even better patch carrying over my sr
Attachment #145320 - Flags: superreview+
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
actually there was one small problem with the patch. I just noticed the headers are displayed inline with the body. It looks like we are not getting a message header sink set on the url we end up running.
Also worth noting is the fact that the .eml message opened via this new command can't be copied to any of the local or IMAP mail folders using the appropriate command in the Message menu. I'm not sure exactly where the problem lies, but it needs to be pointed out... it's probably related to the same thing that's causing the headers to be displayed inline.
I beleve these limitations are due to the fact that there is no folder for the message (based on what I recall from a conversation with David). Perhaps he can shed more insight. AFAIK these are just limitations of the current implementation. I think perhaps bug 236637 is the next that needs to be resolved. So that we allow for better handling when no folder is specified.
(In reply to comment #45) > I decided to forgo the folder directory pref stuff for now. > Any particular reason? > attaching this new patch in case someone does end up porting this back to > seamonkey. They'll have the final stuff to compare to. > AFAIK, I don't think this is necessary. Since seamonkey can view eml files in the browser. Unless we can remove the folder dependancy, allowing for headers to appear correctly, and add saving to other folders. I'm not sure how to do it, but we need a suplemental patch to map *.eml files to Thunderbird when Tbird is installed and configured as the default mail app.
the problem is really that it's not a message per se - there's no folder, and no message in a mailbox, and all those commands expect a message in a folder, as opposed to a .eml file
I noticed this in the checkin: > a=asa for the one line property string addition in messenger.properties > Since we already modified one string in regard to this patch. Is there any chance on allowing a SeaMonkey port before 1.7 goes final? Even if we can't get bug 236637 for ideal functionality, it's a nice low risk addition. Or (worst case) just hold it for 1.8a. I do plan on bringing it over to SeaMonkey, since it's a useful patch. David, Perhaps we can do something like this: http://bugzilla.mozilla.org/show_bug.cgi?id=236637#c2 In the future to address this.
Created attachment 145713 [details] [diff] [review] Add msg extension An omission on my part. We ideally should include *.msg as well. (untested btw, but it's pretty basic, so I can't imagine anything nutty). If 1.7 is to deeply frozen for this, it's minor enough we can obviously wait for 1.8a with no harm done. User can just use "All Files" to view .msg files. Etremely minor, but we should add it, I know I've encountered the .msg extensions with a webmail service or two.
Attachment #145713 - Flags: superreview?(mscott) → superreview+
yes, sure, I'll check this in, and a seamonkey patch as well, once you have one...
(In reply to comment #56) > yes, sure, I'll check this in, and a seamonkey patch as well, once you have one... I'm hoping to have that seamonkey patch up for review later this afternoon (after some school work) or later this evening after class in bug 239555.
I think the .msg extension stuff breaks the file open dialog - when I tried it with the seamonkey patch, no .eml files were shown in the picker. I'll investigate a little.
Created attachment 146123 [details] [diff] [review] Add MSG extension (actually works) Problem was a "," instead of a ";"
Attachment #145713 - Attachment is obsolete: true
Attachment #146123 - Flags: review?(bienvenu)
The eml/msg format should also be the same as the mht (MHTLM) format (rfc 2557) that IE made famous by using it to store saved web pages in one file. I tested mht can be opened perfectly by seamonkey from a mail folder if I add an initial "From - DATE" to the start, and they could be allright also in browser but there's bug 174692 that makes the display of most eml files about unusable there. Can you test this does work, and then add the .mht extension to the file open dialog ? If it's validated the patch allows TB to open mht files, this will be a very positively received. Many people are waiting for a simple, cross-platform tool to open them.
Jean-Marc Desperrier: there's nothing stopping you from doing this (if it works), just change the filter in the open dialog.
I'm very surprised with the result in the latest nightly (20040416), it feels like there is only the GUI and not the back-end. Comment #48 says is a small problem of header not appearing in the windows. This seams to confirm what I get is truly the current result, but the problems go much further than that. - When opening a message with this, the opened windows has the "Open Saved Message" option in the file menu, but it does not work (without warning) - The icon representing the windows when switching task is the main icon and not a message windows icon - The top of the windows is not filled with the fields for the message, we only have the content of the message. - The content include the text value headers of the message. - When I open an HTML message, that's still all I get, the raw text content of the whole message (that is the header, the MIME separators in front of the text and in the text between the attachement, no QP or Base64 decoding). - When I open a message with accentuated characters in ISO-8859-1, they're all replace by the "black diamond with a ?" character (this means the content was interpreted as UTF-8). Selecting a charset in View/Character Encoding has no effect (I can take any charset, it changes nothing, selecting some asiatic or russian charset still gives exactly the same display). - When I try to open any text file with some text in it, it works. I get the whole content of the file displayed in the windows. No warning whatsoever. Right now I feel the code open a file, interprets it as UTF-8, and displays it as text in a windows. There is quite more needed to truly handle a message/rfc822 file (MIME parsing, html display, display of attachment inside the html if needed, etc ...). I hope I don't sound like despising the work that has been done. This is not the intent. But either something very bad happened in the release I test, or the bug has to be reopened. What I see doesn't work behind a functionnality that can easily be done with any text editor.
it was working better than this (though I think I only tried it in thunderbird...)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
the re-opened part doesn't need to be a .6 stopper
Target Milestone: Thunderbird0.6 → Thunderbird0.7
David, Perhaps we can look into your suggestion in comment 27 for the virtual folders? Perhaps we could have 1 virtual folder "temp" (invisible) in Local Folders that we can use for opening messages. Perhaps have it clear itself on app close.
closing again - there was a separate bug opened for the regression, which is fixed.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago → 14 years ago
Resolution: --- → FIXED
If this was fixed by the end of April 2004, why can't I double-click on a .eml file or at the command prompt run thunderbird somefile.eml to open a saved message? I'm using TB 1.0 on Windows XP Professional. By the way, when I run thunderbird somefile.eml from the command prompt, I don't get any Windows error messages. The command executes as far is Windows is concerned, but nothing happens. TB doesn't open or even just a message window (the way Outlook Express works when .eml extension is associated with Outlook Express and you double-click on a .eml file from Windows Explorer). Am I missing something here?
This bug is NOT fixed in Thunderbird 1.0. EML files cannot be opened from a Windows Explorer file list either by double clicking or by using "Open with ..Thunderbird". This is true in Windows 98, Windows 2000 Pro, and Windows XP Home. In Windows 98, the eml file can be opened from the Thunderbird 1.0 "Open saved message ..." menu but is displayed as plain text including all header information. Opening from within TB 1.0 displays the message properly in Win 2000 and XP.
The last post states, "Opening [*.eml files] from within TB 1.0 displays the message properly in Win 2000 and XP." This is not true when the message contains attachments. The trueness of this statement also depends on if you expect external messages to be displayed differently than internal messages. It doesn't make sense that opening EML files from the menu "File > Open Saved Message...", displays the message differently than any other message in Thunderbird. Headers and attachments are treated separately from the message body when messages are downloaded by and displayed by Thunderbird. When opening EML files, the message headers and body are wrapped in HTML and rendered/displayed in one GUI control. Normally the message headers, body and attachments are displayed in (at least) three GUI controls. It makes sense from a consistency and reusibility perspective to use the same methods and GUI objects to display external messages (EML files) as internal messages.
Ok, the last few comments are completely unnecessary (bugspam). If you _read the bug_, your questions/"thoughtful insights"/gripes whatever are discussed. Please refrain from commenting in this or other bugs until you read all associated comments. It wastes too much time reading unnecessary comments.
I(In reply to Robert Accettura [:raccettura] from comment #70) > Ok, the last few comments are completely unnecessary (bugspam). > > If you _read the bug_, your questions/"thoughtful insights"/gripes whatever > are > discussed. > > Please refrain from commenting in this or other bugs until you read all > associated comments. It wastes too much time reading unnecessary comments. Sir, I can forward to you an eml attachment which someone sent to me. Thunderbird can open it in Version 6, but it looks like an empty message. However in Outlook 2007, the message is a complete address list! An import also does not show anything either. So what about the status as verified fixed?
You need to log in before you can comment on or make changes to this bug.