On Mon, 18 Jun 2007 06:34:10 -0400, "R. McCarty"
Cleaning out your inboxe(s) ? - What mail client ( or Web mail ) do you
use to process mail ? From your description it's not clear how OE is
interfering with your preferred mail client.
OE is a built-in component of XP. A removal option is shown in the
Add/Remove applet under "Windows Components". However all it
does is remove the Shortcuts to OE ( Msimn.Exe ) and doesn't remove
the executable or unregister it's components.
That's the problem. The residual risik is that .EML files remain
associated with OE's code, so that an .EML emaul attackment (or
hostile file encountered any other way; CDR, USB, IM drops etc.) will
be processed by this unwanted engine, obliging you to keep it patched
When OE processes an .EML file, it exposes itself as an exploitable
risk surface. Several inline content files will be groped and
"opened", and one cannot be sure that type discipline will restrict
these to "safe" types (MS has screwed up on this before) or that the
handlers for "safe types" will themselves be safe - after all, this is
content they should not be processing in the first place.
What app's inboxes are you referring to?
Windows section, as discussed.
When MS patches the OS or Office, it will tend to re-assert files and
(less often) settings that you may have killed in the interests of
risk management. If you stay with IE 6, this is more likely to be an
issue; at least IE 7 (like Firefox) doesn't come chained to an
?unwanted email app. But OE 6 remains and will likely be patched as
the exposivle risk surface that it is.
Whenever Outlook is re-asserted by MS Office install (or patch), or OE
is re-asserted by an IE 6 bundle etc., you may experience "UI
pressure" to use it again - e.g. non-shortcut icons on desktop and
QuickLaunch (Outlook), shortcuts in same places (OE).
UI pressure extends to read-only attributes to scare you out of
deleting them, and if clicked, will immediately wizard you into having
your mail imported (which hides any malware attachments out of reach
of av), along with settings, address book, and status as default email
The UI pressure can be insidious SE, e.g. Outlook's dialogs will talk
of "upgrading" your email client, with the fatuous ASSumption that
you're sure to consider this particular Outlook version to be the
pinnacle of email development, even if installing a 5-year-old version
of MS Office that has been shot to pieces by exploits by then.
But with only two exceptions that I know of, these attemptrs to hijack
your email service will NOT clear out your existing app's mailboxes.
The two excaptions I know of, are:
- OE over IE3's Internet Mail and News
- OE 5+ over OE4
In both cases, the mail store is irreversibly converted to the newer
format, and there is NO way back. BTW, OE's executible name dates
from the first of these cases, hence "MS I M N .EXE"
The above is particularly deadly for Win95 users, who cannot stay on
the patched edge of the new risks and exploitability that start with
IE 4 and its corresponding HTML-aware email app, OE 4. Old Win95
systems are better off with the far leaner Internet Mail and News, but
once a post-IE3 bundle has been swallowed, there's no way back.
To break the file association risk, set .EML to point to nothing, or
an "alert"executable that can't process it (e.g. Calc.exe). You can
play snakes-and-ladders and kill the actions of whatever aggregate
file type .EML points to, and/or kill the linkage from .EML to that
aggregate type (maybe redirect to an aggregate such as "Unwanted.File"
with Calc.exe or similar as the default action called "open").
Then save these changes as .REG files, so you can re-assert these
steps after "just" re-installing Windows or whatever.
The above is described at the Regedit level; normal caveats apply (and
they are toothy ones, not just a MacDonalds "hot coffee is hot"
disclaimer). Note that XP allows per-user overlay of HKLM...Classes,
i.e. what you see as HKCR is HKLM+HKCU. So repeat the cleanup in HKCU
and export that as .REG, to be applied to any new (and thus
re-duhfaulted) user accounts you may create.
AFAIK MS doesn't apply these file associations specifically at the
user account level, but malware might, so that's a "completeness"
thing. The tone of the original post suggests this may be an
appropriate level of advice.
You can also rename away the MSIMN.EXE executable, and/or create a
read-only dir in that location with the same name as an attemptr to
block re-creation. XP also may have facilities to intercept attempts
to run particular programs and code files, and you could explore that
too, as a way of guarding against vendor re-assertion of the thing.
