Closed Bug 217149 Opened 21 years ago Closed 20 years ago

Thunderbird can't open .eml files or handle message/rfc822 MIME-type

Categories

(Thunderbird :: Mail Window Front End, enhancement)

Product:
Thunderbird
Component:
Mail Window Front End
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Thunderbird0.7

People

(Reporter: jo.hermans, Assigned: raccettura)

References

Details

Attachments

(2 files, 7 obsolete files)

even better patch
6.32 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
Add MSG extension (actually works)
1.66 KB, patch
Bienvenu
: review+
Details | Diff | Splinter Review 
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
QA Contact: asa
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.
This seems related to Bug 26201 and Bug 11076. Another dupe?

Prog.
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. ***
Assignee: mscott → robert
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.
Depends on: 236637
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.
Attached patch Patch v1 Work in progress (obsolete) — — Splinter Review 
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.
Attached patch proposed fix (obsolete) — — Splinter Review 
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...
Attached patch better fix (obsolete) — — Splinter Review 
this patch cleans up the dump statements, and creates a real uri - and it still
works :-)
Attachment #145059 - Attachment is obsolete: true
Attachment #145221 - Attachment is obsolete: true
Attachment #145225 - Flags: superreview?(mscott)
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
Attached patch fix addressing scott's comments. (obsolete) — — Splinter Review 
I fixed the newline, removed the select all, and added the dtd to the diff.
Attachment #145225 - Attachment is obsolete: true
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.
Attachment #145240 - Flags: superreview?(mscott)
Attachment #145225 - Flags: superreview?(mscott)
(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.
Attached patch Patch v2 (obsolete) — — Splinter Review 
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+
Awesome Coolness.
Attachment #145240 - Flags: superreview?(mscott)
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
Attached patch Patch v2 Alternate Ending (obsolete) — — Splinter Review 
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?
Attachment #145306 - Flags: superreview?(mscott)
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.
Attachment #145303 - Attachment is obsolete: true
Attachment #145306 - Attachment is obsolete: true
Attachment #145306 - Flags: superreview?(mscott)
Comment on attachment 145320 [details] [diff] [review]
even better patch

carrying over my sr
Attachment #145320 - Flags: superreview+
checked in
Status: ASSIGNED → RESOLVED
Closed: 20 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.
Status: RESOLVED → VERIFIED
Attached patch Add msg extension (obsolete) — — Splinter Review 
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)
Attachment #145713 - Flags: review+
Attachment #145713 - Flags: superreview?(mscott) → superreview+
Can we checkin for "Add msg extension" (attachment 145713 [details] [diff] [review])?
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.
Problem was a "," instead of a ";"
Attachment #145713 - Attachment is obsolete: true
Attachment #146123 - Flags: review?(bienvenu)
Attachment #146123 - Flags: review?(bienvenu) → review+
Attachment #145713 - Flags: superreview+
Attachment #145713 - Flags: review+
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
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
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.

Attachment

General

Creator:
Created:
Updated:
Size: