Send to in IE 10

How do I enable File | Send Link by email in IE 10?
I'm running Windows 7 64 bit.

 

What e-mail client did you configure as the default one? Did you
install a different e-mail client, uninstall it, and forget to ensure
that your old still existing e-mail client was thereafter configured
as the default one? Can't send if which e-mail client to use happens
to be unspecified.

 

eM Client. Set as eMail default in Control Panel | Programs | Defauilt Programs.

 

Right-click on the desktop. Create a new shortcut. In the command
for the shortcut, enter just "mailto:" (sans quotes). Double-click on
the mailto shortcut. Does your e-mail client start up?

eM client. And what is that? There is an e-mail client named "eM
Client"? What is your e-mail client? You are posting in a newsgroup
that discusses Internet Explorer. That is NOT an e-mail client.

 

eM Client. When launching a program Windows, on this machine, is case blind.
So, in IE10, File, Send, Page by email... is not Internet Explorer?

 

I wonder if the functionality may depend on your
email program. I'm on XP with Outlook Express as
the default email client, but the mailto protocol is
not even registered. (HKEY_CLASSES_ROOT\mailto\)
If I try to use that menu in IE it tries to call mapi32.dll,
which is not even on my machine. The result is that
the operation fails with no error or notice.

On the other hand, why do you need that function?
If someone sent me an email with nothing but a link
I'd delete it because it means one of two things:

1) They have malware on their PC that is sending
out malicious links.

2) They sent a valid link, but couldn't be bothered to
tell me why, so it's very unlikely that it's worth my time
to check it out.

Anyone with experience in security issues knows never
to send a link without including enough personal information
to show that it's valid. In other words, you should copy
the link from the address bar, paste it into an email, and
write *something*, like, "Ed, Here's the link for the store
I told you about." That way Ed knows that you really
meant to send the link, that it's not malware, and he
knows whether he's interested in following the link.

 

Then your registry is missing a valuable entry. MAILTO is a protocol.

The OP has yet to identify their e-mail client although they were
asked to identify it.

That MAPI32.dll is being called is your e-mail client (OE) calling
functions within it. Windows comes included with support for the
simple MAPI protocol. OE uses that. If you install Outlook then its
more robust mapi32.dll gets installed on your host.

Twould be even worse if the OP chose to send the page by e-mail. Then
the recipient gets the entire web page instead of the choice of
visiting there via a link. Sending a link by e-mail does not preclude
the sender from adding more text into the body of their e-mail. Yeah,
I would be suspicious of someone sending me just a URL but if not if
that someone told me why they thought I would want to go there. There
is no difference between sending a link by e-mail whether it was
initiated by an event started within IE, a malware bot on an infected
host, or a user composing a new e-mail. It would be rude to send just
a link in an e-mail with no description.

The OP isn't getting far enough using IE's send-to menu to have the
e-mail client load a new-mail compose window (which would have the
link and whereupon the OP could then add some info to the recipient as
to why he is sending the link to the recipient).

The OP is trying to send the link. The OP doesn't state that will be
the sole content of their e-mail. Personally I've never bothered
using Send Link By E-mail from any web browser. There is very little
advantage versus just copying the URL in the web browser's address bar
and pasting that into the new-mail compose window.

The younger the generation and with getting engrained with texting,
getting short messages has become a lot more common. Hell, you get
text senders that omit just 1 letter from a word in their message as
if adding that 1 letter would be such a terrible onus. After texting
become popular and wide spread, you even seen the boobs using textese
in their posts in Usenet. They've become trained to send garbled
messages that the recipient has to waste even more time trying to
decipher. They don't care about difficulties encountered by the
recipient to read their message. It's the "me" generation and they
don't care about nuisancing others. Even with newer text plans that
don't punish the sender with sending longer messages, these short-
sighted senders continue to send out cryptic and garbled messages.

Hell, just look at some of the posts here in Usenet. There are plenty
of times someone is too lazy to bother providing context for a URL.
The URL is all they put in their message. The site was important to
them so, gee, obviously it must be important to everyone else to see
this poster's "what I found today" diary entry. I've seen posters
that do nothing but post URLs only because, gee, we all must want to
see the RSS feeds to which this poster subscribes, uh huh.

Anyone with experience in security knows that going by the content
(body) of an e-mail provides iffy rating regarding whether an e-mail
is ham or spam. Bayesian anti-spam filtering, for example, is a
statistical guessing game based on the body of a message. Best is to
rely on the headers to determine the source of a message. It takes a
bit of time to understand how mail servers manage their headers.

 

All I wanted to achieve was send a link, along with what it was for and action
required - invoice for software to Treasurer for payment - achieved by copy/paste
url into an email. Doing it directly from IE10 seemed obvious, had it worked;
copy, launch email client (eM Client) and paste link seemed rather long-winded,
but did work.

 

| > not even registered. (HKEY_CLASSES_ROOT\mailto\)
|
| Then your registry is missing a valuable entry. MAILTO is a protocol.
|

Yes, I understand that. But it's not there. I don't know
why. That made me wonder how common such a thing
might be. I have no use for it, anyway, so I never noticed
until now.


| > If I try to use that menu in IE it tries to call mapi32.dll,
| > which is not even on my machine. The result is that
| > the operation fails with no error or notice.
|
| The OP has yet to identify their e-mail client although they were
| asked to identify it.
|

I looked up eM Client and found it actually is a real
program. I know what you mean, though. Val kept posting
as though that question had been answered.

| That MAPI32.dll is being called is your e-mail client (OE) calling
| functions within it. Windows comes included with support for the
| simple MAPI protocol. OE uses that. If you install Outlook then its
| more robust mapi32.dll gets installed on your host.
|

Interesting. I've never needed or wanted MAPI functionality
before, so I haven't paid much attention to it. I found the
following:

http://msdn.microsoft.com/en-us/library/windows/desktop/ee909492(v=vs.85).aspx

According to that I should have a value under
HKEY_LOCAL_MACHINE\Software\Clients\Mail\Outlook Express
named DLLPath that points to msoe.dll. The key is there, but
not the value.

Mapi32 is actually being called by IE. I did a search and
found that mapi32.dll has been renamed to mapi32x.dll.
According to this link....

http://msdn.microsoft.com/en-us/library/windows/desktop/ee909493(v=vs.85).aspx

..... that's a normal situation, designed to avoid compatibility
issues, but according to that link I should also have a file
mapi32.dll. I don't.

All of this is fine with me. I don't have need of mailto:
protocol and I don't want any old software to be able
to send email by simple automation methods. I don't
want any software sendig any email unless it's sent by
me through OE. But the fact that MAPI is broken in at
least 2 ways on my box makes me wonder about how
dependable it is. Maybe it never gets fully set up on a
PC that's never connected to a Windows network? I
don't know.

| The younger the generation and with getting engrained with texting,
| getting short messages has become a lot more common.
.....| Hell, just look at some of the posts here in Usenet. There are plenty
| of times someone is too lazy to bother providing context for a URL.
| The URL is all they put in their message.

Yes. It's a maddening lack of courtesy. And as you
say, an indication of childish awareness not recognizing
that other people do not share one's own thoughts.
I just ignore those posts. I can't bring myself to
indulge such behavior.

 

I figured "eM client" was an abbreviation for e-mail client. Never
heard of that program but then there are dozens of e-mail clients that
have come and gone and still exist that have a very tiny userbase that
I wouldn't know about.

The OP says "eM Client" is configured as the default e-mail client in
Windows. That's needed but I suspect simple MAPI might be an issue.
Simple MAPI was needed for Outlook Express but Microsoft dropped
support for OE back in 2002 with just some security updates thereafter
(although one update in Windows XP SP-2 did add registry hacks for
where to place the signature and default insert point). OE was no
longer bundled with Internet Explorer as of version 7, and later, and
that was the only way to get it. Even Thunderbird could use simple
MAPI.

Looks like Microsoft dropped simple MAPI in Windows 7. Some e-mail
programs still rely on simple MAPI to function (integrate with other
components calling those MAPI functions). I've seen reports that MYOB
won't function correctly under Windows 7 because Windows 7 doesn't
include simple MAPI.

http://en.wikipedia.org/wiki/Messaging_Application_Programming_Interface

E-mail programs that worked okay on Windows XP and Vista that use
simple MAPI to function would stop functioning on Windows 7. Simple
MAPI doesn't come included in Windows 7.

Outlook installs its own DLL and uses extended MAPI. Some folks whose
e-mail programs stopped working on Windows 7 say the following helped:

http://support.microsoft.com/kb/980681

The manifest for each notes mapi32.dll is included and that's probably
what the OP's e-mail program (eM Client) requires. To get the hotfix
requires giving Microsoft an e-mail to which they will e-mail you a
link to download the file. I have seen some complaints that the
password given in the e-mail doesn't work.

Another possibility is using security tokens that mismatch on
processes. For example, you can use the policy editor to define a SRP
(software restriction policy) to set Block, Allow, or Basic (limited)
for privileges on a program started from a particular executable (you
use a Path rule). When the program gets called (by loading the
specified pathed executable), it will be blocked from loaded (Block),
allowed to load (Allow), or run under basic privileges (under a LUA -
limited user access - token). Some users find that running the web
browser under one set of privileges causes problems when trying to
access their e-mail client that runs under a different set of
privileveges. I have, in the past, used the Basic mode to force a LUA
token on the web browser but not on the e-mail client and haven't had
problems but then I don't recall ever bothering to use the File ->
Send -> Link menu in the web browser since that takes as much work as
just highlighting the URL in the address bar, copy it, click on a link
in my taskbar for my e-mail client, click New to compose a message,
and paste into the e-mail. Sounds like more work but consists of
Ctrl+A, click taskbar button, click New, Ctrl+V (versus click File,
click Send, click Link). The difference is one mouse click but then I
don't have to be concerned with what e-mail client is the default one.

When I ran the web browser under a LUA token (less privileges), there
were artifacts in its operation. It's been too long to remember for
sure but I think one feature broken with the web browser under LUA
privileges was that I couldn't print from the web browser. I think
some add-ons wouldn't work, too. Some features required the web
browser to either have admin privileges or be at the same privileges
as the Windows account under which I logged in.

"During installation, the original Mapi32.dll is renamed to
Eumapi32.dll if the DLL was provided by Eudora, Nsmapi32.dll if the
DLL was provided by Netscape, or otherwise Mapi32x.dll. The stub
library, which is contained in the file Mapi32stub.dll, is then copied
to Mapi32.dll."

So there should, according to this article, still be a mapi32.dll file
on your host. It would be the new version. Perhaps the install was
bad and the step to copy in the new mapi32.dll failed. Could be
malware that deleted the file or renamed it.

From that article, "Many applications support the addition of their
product name to Send on the File menu through the installation of a
custom version of Mapi32.dll in the system directory." So without the
(simple or extended) MAPI support available, those apps can't do their
Send operation. It also appears some programs might step on the
mapi32.dll to insert their own which could break other MAPI-supporting
applications.

So a program calling any of the MAPI functions (simple or extended)
would fail. That's why users of MYOB complained that it stopped
working when them moved to Windows 7. The above hotfix might return
MAPI support since it looks like it dumps a mapi32.dll onto the host.

 

Also, I see no mention at the eM Client web site as to what are the
system requirements for their program, like which operating systems
under which it can run. There is very little info at their site.

http://www.emclient.com/

They don't even provide a FAQ of common questions and answers. They
don't even give info about their Czech Republic company's history.
Although they registered their domain name back in 2006, it looks like
this eM Client product appeared in March 2010 but didn't take off
until a year ago

http://www.techsupportalert.com/best-free-email-client.htm and
Wikipedia mention that the free version permits a maximum of only 2
accounts be defined within it. That would be an immediate cause for
deletion (or never installing) the product for me.

Since the "send" operation from many apps is going to rely on [simple]
MAPI to work, and since this app doesn't appear to work with MAPI,
there are probably lots of expected behavior that won't work with this
e-mail client. Only the program's authors would know if the program
itself requires MAPI or why it cannot be called from other apps.

The OP could go into their forums to ask why this program cannot be
called via MAPI from other programs. Note that this company does not
provide their own forum. They use Getsatisfaction to handle the load.
It's a means of sharing resources for similar functionality (although
I find the interface to be clumsy). Any account you create for their
forum will actually be an account under Getsatifaction. I did a
search there on "Windows 7". While there are some articles there,
they don't specifically address this issue but then maybe no one has
tried calling eM Client from the web browser's File menu or those that
have never asked about it in those forums. I also searched on
"internet explorer" but still nothing on this issue (but does appear
eM Client will sometimes open the wrong web browser when clicking a
link inside an e-mail shown by eM Client).

 

I chose eM Client as it seemed to offer most of the facilities of Outlook
(2003) and easy migration of conatcts, emails, diary/to-dos... from previous
XP machine to Windows 7.
The email protocols (if that's the correct terminology) are: SMPT and POP3,
both 'using SSL/TSL if available'.
The limit of two addresses is not a problem for spouse and self.

 

You'll have to find out if eM Client supports [simple] MAPI from its
author. It might not which means it can never be called from other
programs that use MAPI to access an e-mail client.

If it does support MAPI then you might try the mentioned hotfix to see
if it places a mapi32.dll on your host that is properly registered
into the registry so apps can use MAPI to call your eM Client program.

 

(Partial) success. I turned the slider (Start/msconfig.exe/Tools/UAC/Launch)
down to "Never Notify", restarted, re-installed eM Client as default email,
in Start/Default Programs/Set Program... Custom to Use my current e-mail
program (not to eM Client), exited IE10 now has all Sent to items available.
Reset UAC and rebooted, all still fine on 64bit desktop. Tried same on laptop
(32bit Win 7 Home Premium), no go, only Shortcut to Desktop available.

 

Update: On 32bit laptop, IE10, enable Command bar, right-click on it, Customize,
Add or Remove Commands, Add Send page by e-mail, Send link by e-mail, Removed
unwanted commands - sweetness and light.