Board index » Internet Explorer » Fw: Downloading with MSIE and opening with OE .EML files doesn't work

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

Internet Explorer106
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).



"Enzo Michelangeli" <nospam@em.no-ip.com>wrote in message



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.


-
 

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





"Enzo Michelangeli" wrote:



Quote
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).



"Enzo Michelangeli" <nospam@em.no-ip.com>wrote in message

news:4523607c$1@127.0.0.1...



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.





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;

support.microsoft.com/kb/312355" >support.microsoft.com/kb/312355

www.microsoft.com/technet/prodtechnol/exchange/e2k7help/28d0d09e-7931-4a23-a890-5dd4a23312bd.mspx >www.microsoft.com/technet/prodtechnol/exchange/e2k7help/28d0d09e-7931-4a23-a890-5dd4a23312bd.mspx

HTH.

Please let us know.

Regards,

nass

------------

www.nasstec.co.uk

-

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

"nass" <nass@discussions.microsoft.com>wrote in message

[...]

Quote
Hi Enzo,

First try toscan for malwares



I did, and it does the same also on two other PC's (which run Windows2000

rather than XP).



Quote
and does this attachment is from a well known

source?.



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.



Quote
Here are some links to shed some light for you;

support.microsoft.com/kb/312355" >support.microsoft.com/kb/312355



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).



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



Cheers --



Enzo



-

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

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)



www.iecustomizer.com/iecustomizer.vcf" >www.iecustomizer.com/iecustomizer.vcf



On www.iecustomizer.com/about.asp" >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 news: protocol?



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

working samples.



Regards.

"Enzo Michelangeli" <nospam@em.no-ip.com>wrote in message

Quote
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).



"Enzo Michelangeli" <nospam@em.no-ip.com>wrote in message

news:4523607c$1@127.0.0.1...



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.







-

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

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





-

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

Thanks for the followup and the info. I won't ask how long it took you to

figure all that out. <VBG>



steve



"Enzo Michelangeli" <nospam@em.no-ip.com>wrote in message

Quote
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







-