Rightmouse context menu fails to send to mail recipient

[gmarissen]

If I try to send files using the rightmouse button context Send To/Mail Pecipient nothing happens anymore. Previous version worked fine.

[karlchen]

Hello, gmarissen.

Oops. Confirmed. Sorry, this flaw must have slipped all beta testers' attention.

It only seems to affect Sendto => e-mail recipient. Other Sendto functions still work as expected here.

Total Commander 7.56
Windows 7 Enterprise 32-bit

Kind regards,
Karl

[ghisler(Author)]

Works fine here with Outlook Express (tested on Windows XP 64, there is no default mail on my Windows 7 computer).

What mail client do you use? What error do you get?

[gmarissen]

Works fine here with Outlook Express (tested on Windows XP 64, there is no default mail on my Windows 7 computer).

What mail client do you use? What error do you get?

I'm still using Outlook 2003 on Windows XP 32.

[ghisler(Author)]

Just tried it on Windows XP 32 with Outlook Express, no problem either. Unfortunately I don't have access to Outlook 2003.

Can you check what is defined in
HKEY_CLASSES_ROOT\CLSID\{9E56BE60-C50F-11CF-9A2C-00A0C90A90CE}\InProcServer32
?

On my system, it's set to C:\WINDOWS\system32\sendmail.dll. Maybe the Outlook 2003 dll is not found because its set without full path...

[ODiUM]

I'm having the same bug. Running Total Commander 7.56 on a Windows XP SP3 (32bit) machine with Outlook 2003 installed as mail client.

@Ghisler: The setting in the registry that you mentioned is the same as yours:

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{9E56BE60-C50F-11CF-9A2C-00A0C90A90CE}\InProcServer32]
@="C:\\WINDOWS\\system32\\sendmail.dll"
"ThreadingModel"="Apartment"

There is no error by the way. Instead of opening a mail with the selected file attached, nothing happens.

[karlchen]

Hello, Christian.

Windows 7 Enterprise, 32-bit
Outlook 2003
Registry Settings:

[HKEY_CLASSES_ROOT\CLSID\{9E56BE60-C50F-11CF-9A2C-00A0C90A90CE}\InProcServer32]
(Default) REG_EXPAND_SZ "%SystemRoot%\System32\sendmail.dll"
"ThreadingModel"="Apartment"

The file exists.

By the way. There is no error message Sendto => email recipient silently does nothing.

It works from inside Explorer and it works from inside T.C. 7.55a.

Sorry, I did not detect this problem before November 30th.

Kind regards,
Karl

[gmarissen]

Hello, Christian.

Windows 7 Enterprise, 32-bit
Outlook 2003
Registry Settings:

[HKEY_CLASSES_ROOT\CLSID\{9E56BE60-C50F-11CF-9A2C-00A0C90A90CE}\InProcServer32]
(Default) REG_EXPAND_SZ "%SystemRoot%\System32\sendmail.dll"
"ThreadingModel"="Apartment"

The file exists.

By the way. There is no error message Sendto => email recipient silently does nothing.

It works from inside Explorer and it works from inside T.C. 7.55a.

Sorry, I did not detect this problem before November 30th.

Kind regards,
Karl

Indeed, there is no error message, just silence. Reg-settings btw are the same.
Thanks for the quick reply, I hope this will be resolved in a comming new release

[karlchen]

In fact, as previous replies suggest, the problem is more sophisticated than "Sendto => e-mail recipient" does not work any longer:

On my Vista Home Premium, 32-bit, default mail programme Windows Mail (never used actually), Sendto => E-Mail Recipient works as expected when invoked from the context menu in T.C. 7.56.
On Windows 7 Enterprise, 32-bit, default mail programme Outlook 2003, Sendto => E-Mail Recipient silently fails.
And the entries for the CLSID HKCR\CLSID\{9E56BE60-C50F-11CF-9A2C-00A0C90A90CE} look exactly the same on both machines.

Curious to find out what will happen on my Windows 7 Home Premium, 64-bit ...

Karl

[ghisler(Author)]

It looks like the dll for Outlook 2003 (or a dll used by it) cannot be found. Since the right click menu function itself was not changed, it may be caused by the call to SetDllDirectory, which should prevent the loading of dlls from the current directory.

Since I don't have access to Outlook 2003, I have to ask you to test this for me: Please get the following test tool:

https://plugins.ghisler.com/addons/testrightclick.zip

Run it, then test whether "Send to " - "Mail recipient" works with the "SetDllDirectory ENABLED" option checked, and if NOT, whether it works with the option unchecked. If that doesn't work either, try whether it works after closing and restarting the test program (without checking the option, then SetDllDirectory will never be called).

Thanks for your help!

[karlchen]

Good evening, Christian.

Results for rclick.exe with [x] and without [_] SetDllDirectory ENABLED:

Windows Vista Home Premium:
Sendto => E-Mail Recipient works irrespective of the setting SetDllDirectory ENABLED.
rclick.exe was shutdown and restarted for each test run.

Sendto => E-Mail Recipient works fine if invoked from the context menu in T.C. 7.56, cf. post above.

Windows 7 Enterprise:
Sendto => E-Mail Recipient silently fails if the option [x] SetDllDirectory ENABLED has been ticked.
Sendto => E-Mail Recipient succeeds if the option [_] SetDllDirectory ENABLED has been unticked = de-activated.

rclick.exe was shutdown and restarted for each test run.

Sendto => E-Mail Recipient silently fails if invoked from the context menu in T.C. 7.56, cf. post above.

Kind regards,
Karl

[ghisler(Author)]

Thanks for your quick test! So it really seems that SetDllDirectory is the problem.

According to its documentation on MSDN:
http://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx

the dlls are searched in the following locations:

Code: Select all

   1. The directory from which the application loaded.
   2. The directory specified by the lpPathName parameter.
   3. The system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is System32.
   4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
   5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
   6. The directories that are listed in the PATH environment variable.

Therefore it seems that the Outlook 2003 SendTo dll uses the following method to load dlls: It probably sets the current directory to the location of the dll, and then loads the dll without specifying a complete path.

Total Commander 7.56 is trying to avoid such insecure loading by calling SetDllDirectory(""), which causes Outlook 2003 SendTo to fail.

I can stop calling SetDllDirectory(""), but then other shell extensions which load dlls this way (and don't set the current dir first) could be attacked by dll planting (putting a virus dll in the current directory)...

[karlchen]

Hello, Christian.

There are further hints that indeed Outlook 2003 is to blame. Very likely you are right that it does not conform to the new standards setup by Microsoft.

There are a few otherwise identical Windows installations which only differ in their default mail programme:
On those Windows machines where (the ancient) Outlook Express is still the default mail client, invoking Sendto => E-Mail Recipient from inside T.C. works fine.
On those Windows machines, however, where Outlook 2003 is the default mail client, invoking Sendto => E-Mail Recipient from inside T.C. fails silently.

This is a plight:
Restoring the T.C. 7.55a behaviour will work fine for all, including those programmes that still use unsafe DLL loading, but at the cost of security.
Preserving the current T.C. 7.56 behaviour is in accordance with safe DLL loading, but at the cost that a small number of outdated e-mail clients fail to load.

Personally, I plead for sticking to the current behaviour. The days of Outlook 2003 are running out anyway.

Kind regards,
Karl

[ghisler(Author)]

Unfortunately most people would see this as a bug of TC 7.56, not as a bug of Outlook 2003. Therefore I need to find a solution, e.g. setting the DLL directory option to what it was in TC 7.55a only while the context menu is shown and a command from it is executed. This way DLL loads by TC plugins will be handled safely, but the conext menu safety depends on the called programs.

[petermad]

Just for the record, even though you seem to have found the reason for this behaviour - I use SeaMoney as my default mail client, and it opens correctly from the rightclick menu both under Windows XP 32bit, and Windows 7 64bit - so it is obviously an OE bug.