Fw: Downloading with MSIE and opening with OE .EML files doesn't work

  • Thread starter Thread starter Enzo Michelangeli
  • Start date Start date
E

Enzo Michelangeli

I'm reposting here (the original was at
microsoft.public.windows.inetexplorer.ie6_outlookexpress) because this looks
like a MSIE issue more that an OE one: the section 2. also applies to
settings where Outlook, not Outlook Express, is the default mail
application; and Mozilla Firefox encounters no problem with either of them).


I'm trying, without success, to download from a web server .EML files
containing plain RFC-822 messages and open them with Outlook Express without
having to save them first. I'm using the latest MSIE6 on WinXP SP2, latest
updates all installed. Here's what happens:

1. If the server sends the "Content-type: message/rfc822" header, MSIE
decides that the file is "MHTML" and opens the text in its window, ignoring
any attachment (even though the server sends a very clear
'Content-disposition: attachment; filename="q.eml"' header). This is not
what I need.

2. If the Content-type declared by the server is changed to
"application/octet-stream", MSIE presents a dialog box saying that the file
is an Outlook Express aplication, and asks me to choose among Open, Save or
Cancel. If I choose "Save", the operation works as expected; HOWEVER,
choosing "Open" only works if Outlook Express was NOT already running. If it
was, I get the error message (obviously misleading): "The file q.eml could
not be opened because it doesn't exist, or is being used by another
application (0x800CCF65, 2)".

Now, it is interesting to note that _exactly_ the same situation occurs if I
try to issue, at the command line, the command:

"C:\Program Files\Outlook Express\msimn.exe" /eml:q.eml

....which in a way makes sense, because this is the command associated by
Windows Explorer's "Tools -> Folder Options -> File Types" screen to the
Action "open" for .EML files.

On the other hand, the command:

start q.eml

....always works as it should (and as MSIE should, but does not), regardless
of whether OE was or not running.

My suspicion is that in order to open an EML file with Outlook Express when
the latter is already running one should use DDE, _not_ the /eml: switch
(and probably cmd.exe's "start" command does just that). And indeed, if I
change the settings in the "Tools -> Folder Options -> File Types" screen
and, for the Action "open", I add [open("%1")] in the "DDE message" field,
Outlook Express does open a window for q.eml; unfortunately, it ALSO shows
the error box "The file q.eml could not be opened because it doesn't exist,
or is being used by another application (0x800CCF65, 2)".

Any idea?

Thanks in advance,

Enzo

P.S. With Firefox, all works as expected.
 
Enzo Michelangeli said:
I'm reposting here (the original was at
microsoft.public.windows.inetexplorer.ie6_outlookexpress) because this looks
like a MSIE issue more that an OE one: the section 2. also applies to
settings where Outlook, not Outlook Express, is the default mail
application; and Mozilla Firefox encounters no problem with either of them).


I'm trying, without success, to download from a web server .EML files
containing plain RFC-822 messages and open them with Outlook Express without
having to save them first. I'm using the latest MSIE6 on WinXP SP2, latest
updates all installed. Here's what happens:

1. If the server sends the "Content-type: message/rfc822" header, MSIE
decides that the file is "MHTML" and opens the text in its window, ignoring
any attachment (even though the server sends a very clear
'Content-disposition: attachment; filename="q.eml"' header). This is not
what I need.

2. If the Content-type declared by the server is changed to
"application/octet-stream", MSIE presents a dialog box saying that the file
is an Outlook Express aplication, and asks me to choose among Open, Save or
Cancel. If I choose "Save", the operation works as expected; HOWEVER,
choosing "Open" only works if Outlook Express was NOT already running. If it
was, I get the error message (obviously misleading): "The file q.eml could
not be opened because it doesn't exist, or is being used by another
application (0x800CCF65, 2)".

Now, it is interesting to note that _exactly_ the same situation occurs if I
try to issue, at the command line, the command:

"C:\Program Files\Outlook Express\msimn.exe" /eml:q.eml

....which in a way makes sense, because this is the command associated by
Windows Explorer's "Tools -> Folder Options -> File Types" screen to the
Action "open" for .EML files.

On the other hand, the command:

start q.eml

....always works as it should (and as MSIE should, but does not), regardless
of whether OE was or not running.

My suspicion is that in order to open an EML file with Outlook Express when
the latter is already running one should use DDE, _not_ the /eml: switch
(and probably cmd.exe's "start" command does just that). And indeed, if I
change the settings in the "Tools -> Folder Options -> File Types" screen
and, for the Action "open", I add [open("%1")] in the "DDE message" field,
Outlook Express does open a window for q.eml; unfortunately, it ALSO shows
the error box "The file q.eml could not be opened because it doesn't exist,
or is being used by another application (0x800CCF65, 2)".

Any idea?

Thanks in advance,

Enzo

P.S. With Firefox, all works as expected.
Click to expand...
Hi Enzo,
First try toscan for malwares and does this attachment is from a well known
source?.
Here are some links to shed some light for you;
http://support.microsoft.com/kb/312355
http://www.microsoft.com/technet/pr...09e-7931-4a23-a890-5dd4a23312bd.mspx?mfr=true
HTH.
Please let us know.
Regards,
nass
 
[...]
Hi Enzo,
First try toscan for malwares
Click to expand...

I did, and it does the same also on two other PC's (which run Windows2000
rather than XP).
and does this attachment is from a well known
source?.
Click to expand...

Sure, but even without attachments (pure text message) it does exactly the
same. Actually you can easily reproduce the case:

1. Save to an .eml file a message from OE.
2. Place that file to a web server, but modify the mime.types (or IIE
equivalent) on that web server to associate the extension ".eml" to
"application/octet-stream" (to defeat the MHTML thing that I described as
point 1. in my original post).
3. Point your MSIE to the URL corresponding to that file.
Here are some links to shed some light for you;
http://support.microsoft.com/kb/312355
Click to expand...

This is said to apply only to OE 5.5: and indeed, with my OE 6 the switch
"/reg" doesn't seem to achieve anything (if I change the association to,
say, Outlook, after running '"C:\Program Files\Outlook Express\MSIMN.EXE"
/reg' the .eml files are still associated to Outlook). But yes, on my
machine OE currently _is_ the application associated to .eml files. (And if
I change that to Outlook, I get a similar error, slightly differently worded
as this time it comes from Outlook and not from OE).
http://www.microsoft.com/technet/pr...09e-7931-4a23-a890-5dd4a23312bd.mspx?mfr=true
Click to expand...

This appears to refer to MS Exchange, not OE or MSIE.

Cheers --

Enzo
 
Hi Enzo,

I have a suggestion. Create your own BHO and use the DoFileDownload api
(from shdocvw.dll) to automate the file download without the download prompt
and to open it with Outlook Express. You will have to use the <object> tag
within your html and set the .eml file url to pass it to your BHO as a
property.

Also check your client pc's file associations for eml file types. On the
Advanced button dialog there is an option to Confirm Open after Download.
Unchecking this should remove the download prompt and open it directly in
OE. I haven't tested any of these but I use similar techniques on my web
site with vcf files.(vcards)

Click on this link and depending on your file type association settings for
vcf it should open in your address book (WAB)

http://www.iecustomizer.com/iecustomizer.vcf

On http://www.iecustomizer.com/about.asp you will see an icon that users can
click to download and save my site vcard using streaming so that I can log
download counts and IP addresses of downloads to. I am using text mime type
in the streaming.

As a thought I am wondering if the email: protocol would work to open your
server eml file in the clients default email program. Again I haven't tested
it, but it may be something else you can try.

eg. <a href="email:www.myserver.com/mymailmessage.eml"><%=Email
Subject%></a>

or perhaps the protocol?

Also try searching for any freeware smp mail servers. They may contain some
working samples.

Regards.
Enzo Michelangeli said:
I'm reposting here (the original was at
microsoft.public.windows.inetexplorer.ie6_outlookexpress) because this
looks like a MSIE issue more that an OE one: the section 2. also applies
to settings where Outlook, not Outlook Express, is the default mail
application; and Mozilla Firefox encounters no problem with either of
them).


I'm trying, without success, to download from a web server .EML files
containing plain RFC-822 messages and open them with Outlook Express
without
having to save them first. I'm using the latest MSIE6 on WinXP SP2, latest
updates all installed. Here's what happens:

1. If the server sends the "Content-type: message/rfc822" header, MSIE
decides that the file is "MHTML" and opens the text in its window,
ignoring
any attachment (even though the server sends a very clear
'Content-disposition: attachment; filename="q.eml"' header). This is not
what I need.

2. If the Content-type declared by the server is changed to
"application/octet-stream", MSIE presents a dialog box saying that the
file
is an Outlook Express aplication, and asks me to choose among Open, Save
or
Cancel. If I choose "Save", the operation works as expected; HOWEVER,
choosing "Open" only works if Outlook Express was NOT already running. If
it
was, I get the error message (obviously misleading): "The file q.eml could
not be opened because it doesn't exist, or is being used by another
application (0x800CCF65, 2)".

Now, it is interesting to note that _exactly_ the same situation occurs if
I
try to issue, at the command line, the command:

"C:\Program Files\Outlook Express\msimn.exe" /eml:q.eml

...which in a way makes sense, because this is the command associated by
Windows Explorer's "Tools -> Folder Options -> File Types" screen to the
Action "open" for .EML files.

On the other hand, the command:

start q.eml

...always works as it should (and as MSIE should, but does not),
regardless
of whether OE was or not running.

My suspicion is that in order to open an EML file with Outlook Express
when
the latter is already running one should use DDE, _not_ the /eml: switch
(and probably cmd.exe's "start" command does just that). And indeed, if I
change the settings in the "Tools -> Folder Options -> File Types" screen
and, for the Action "open", I add [open("%1")] in the "DDE message" field,
Outlook Express does open a window for q.eml; unfortunately, it ALSO shows
the error box "The file q.eml could not be opened because it doesn't
exist,
or is being used by another application (0x800CCF65, 2)".

Any idea?

Thanks in advance,

Enzo

P.S. With Firefox, all works as expected.
Click to expand...
 
OK, it turned out that the problem was not specific to Outlook Express, and
the inability by OE to open .eml files whose names were passed with the
"/eml:" command line switch was a red herring: OE _can_ open them, but they
must be passed complete with their (absolute) path, because apparently OE
changes the current directory to %HOMEPATH% (\Documents and
Settings\%USERNAME%) _before_ parsing the arguments (booo!), so a file
passed with a relative path is not found within the directory that was the
current one when the command was issued.

But as I said, the problem lied elsewhere: namely, in the "Cache-control:
no-cache" HTTP header sent by my webserver. It appears that MSIE takes a
fundamentalist approach to compliance with it, and deletes the downloaded
file from the cache (%HOMEPATH%\Local Settings\Temporary Internet
Files\Content.IE5<random_subdir> ) immediately after completing the
download, without even giving the helper application associated with the
filename a fighting chance to grab it... Replacing the "no-cache" parameter
with something less harsh, such as "max-age=120", fixed the malfunction.

It still remains necessary to use a content-type "application/octet-stream"
in order to prevent MSIE from opening the document in its own window as
MHTML, but that's a minor annoyance.

Anyway, many thanks to all who kindly posted followups to this thread!

Enzo
 
Thanks for the followup and the info. I won't ask how long it took you to
figure all that out. <VBG>

steve
 
Back
Top