Last Comment Bug 244222 - add MAPI ResolveName
: add MAPI ResolveName
Status: RESOLVED FIXED
:
Product: MailNews Core
Classification: Components
Component: Simple MAPI (show other bugs)
: Trunk
: x86 Windows XP
: -- normal with 36 votes (vote)
: Thunderbird 13.0
Assigned To: :aceman
:
Mentors:
http://getsatisfaction.com/mozilla_me...
: 259549 (view as bug list)
Depends on:
Blocks: 259585 215978
  Show dependency treegraph
 
Reported: 2004-05-20 15:43 PDT by David :Bienvenu
Modified: 2012-04-25 02:31 PDT (History)
32 users (show)
mkmelin+mozilla: wanted‑thunderbird3+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
13+
fixed


Attachments
Implements very basic functionality for MAPIResolveName (1.56 KB, patch)
2008-03-13 08:13 PDT, Frans-Jan v. Steenbeek
no flags Details | Diff | Review
Fixed typo in patch, now directing to the correct file (I hope) (1.56 KB, patch)
2008-03-13 08:18 PDT, Frans-Jan v. Steenbeek
mozilla: review-
mozilla: superreview-
Details | Diff | Review
patch, add check out of memory and other cleanup (5.91 KB, patch)
2012-01-09 12:56 PST, :aceman
no flags Details | Diff | Review
patch, fix proper release of memory in case of failure (6.49 KB, patch)
2012-01-09 13:35 PST, :aceman
mozilla: review-
Details | Diff | Review
patch that builds for me (5.05 KB, patch)
2012-02-15 17:00 PST, David :Bienvenu
no flags Details | Diff | Review
patch v3 (6.18 KB, patch)
2012-02-16 11:19 PST, :aceman
mozilla: review+
standard8: approval‑comm‑esr10+
Details | Diff | Review

Description David :Bienvenu 2004-05-20 15:43:06 PDT
We need to add the MAPI ResolveName interface.
Comment 1 Rob Janssen 2004-06-23 00:19:12 PDT
Is there any Mozilla document that lists the MAPI interface functions and says
which ones are implemented by Mozilla and should work, and which ones are not
implemented?
(maybe both on a programmer and on a user level)
Comment 2 Boris Zbarsky [:bz] 2005-01-27 08:44:26 PST
*** Bug 259549 has been marked as a duplicate of this bug. ***
Comment 3 WADA 2005-01-30 22:51:40 PST
*** Bug 53186 has been marked as a duplicate of this bug. ***
Comment 4 John McCormick 2006-09-12 16:04:15 PDT
Microsoft's info on this function is at:
http://windowssdk.msdn.microsoft.com/en-us/library/ms529143.aspx

Seems like an acceptable implementation of this function, if no one has time to get into showing address books and stuff like that, would be to simply "resolve" a standard e-mail address to itself without otherwise checking it.
Comment 5 John McCormick 2006-09-12 16:11:04 PDT
Working from bug 259585 comment 4, it seems like something like this should work:

ULONG FAR PASCAL MAPIResolveName(...)
{
    //return MAPI_E_FAILURE;
    char* lpszRecipName = new char[strlen(lpszName + 1)];
    char* lpszRecipAddress = new char[strlen(lpszName + 6)];
    strcpy(lpszRecipName, lpszName);
    strcpy(lpszRecipAddress, "SMTP:");
    strcpy(lpszRecipAddress + 5, lpszName);

    (*lppRecip) = (lpMapiRecipDesc FAR)malloc(sizeof(MapiRecipDesc));
    (*lppRecip)->ulRecipClass = 1;
    (*lppRecip)->lpszName = lpszRecipName;
    (*lppRecip)->lpszAddress = lpszRecipAddress;
    (*lppRecip)->ulEIDSize = 0;
    (*lppRecip)->lpEntryID = 0;

    return SUCCESS_SUCCESS;
}

Of course, I don't really do c-style windows programming or mozilla programming, and am not sure who should really own the strings. In theory that'd be one way to do it, though, I think.

On another note, when sending MAPI requests to Thunderbird in the past, I've found that it seems to like having the lpszName part of a MapiRecipDesc be the e-mail address to send to and the lpszAddress part set to NULL, so if that's the preferred format, maybe that should be done instead of filling them both. All this SMTP: and FAX: stuff is specific to outlook anyway, right? But, I think Thunderbird ignores it, so it shouldn't hurt to fill it in so long as the name part is an actual e-mail address.
Comment 6 Frans-Jan v. Steenbeek 2008-03-13 08:13:49 PDT
Created attachment 309118 [details] [diff] [review]
Implements very basic functionality for MAPIResolveName

Building upon the suggestion by John McCormick (2006-09-12 16:11:04 PDT) I've build Thunderbird with

ULONG FAR PASCAL MAPIResolveName(...)
{
    char* lpszRecipName = new char[(strlen((const char*)lpszName) + 1)];
    char* lpszRecipAddress = new char[(strlen((const char*)lpszName) + 6)];
    strcpy(lpszRecipName, (const char*)lpszName);
    strcpy(lpszRecipAddress, (const char*)lpszName);
    (*lppRecip) = (lpMapiRecipDesc FAR)malloc(sizeof(MapiRecipDesc));
    (*lppRecip)->ulRecipClass = 1;
    (*lppRecip)->lpszName = lpszRecipName;
    (*lppRecip)->lpszAddress = lpszRecipAddress;
    (*lppRecip)->ulEIDSize = 0;
    (*lppRecip)->lpEntryID = 0;
    return SUCCESS_SUCCESS;
}

Besides, MAPIAddress and MAPIDetails were set to always return MAPI_E_NOT_SUPPORTED (not sure if this is the way to go, but it worked and it seems more 'just' than always returning MAPI_E_FAILURE).

This was done to get two programs we use to work. The first (Avaya IP Office VoiceMail Lite) uses MAPIResolveAddress to send mail to a regular email address. This program now works. The second (AccountView) seems to use MAPIAddress to include a list of recipients. Obviously, that program does not work yet, but that is outside the scope of this bug (a new one should be opened for MAPIAddress, but I need to look into it a bit more).

Some caveats:
* lpszName is frequently typecasted to const char*. I do not think this is the way to go, but I have no experience with C++ to do it otherwise. Removing the typecasting causes the build to fail.
* The SMTP: bit was removed, since it seems that both Thunderbird and Outlook Express ignore these. Outlook Express does not add it, so it might be specific to Extended MAPI or even to Outlook alone. It looked ugly, it didn't hurt to remove it, so there it is. Again, not sure if this is the way to go.
* lpszName and lpszAddress are both filled, and identical (now I look at it, lpszAddress and lpszRecipAddress are both 5 chars larger since I forgot to correct that while removing SMTP:).
* The function only works when a regular email address is given. There are no checks or anything on that, so behavior might be strange when another string is passed. There should be something hooked into the addressbook, but there isn't.

Apart from all that, the function now works and enables a few 3rd party apps to work with Thunderbird.

DISCLAIMER!
I am not a C++ guru. I'm not even a C++ coder. In fact, this is the first serious bit of programming I've done that does not involve PHP or JavaScript. All I did was adding John McCormick's suggestion and rewriting it.
Comment 7 Frans-Jan v. Steenbeek 2008-03-13 08:18:13 PDT
Created attachment 309120 [details] [diff] [review]
Fixed typo in patch, now directing to the correct file (I hope)
Comment 8 Ronald Killmer 2008-04-26 11:06:28 PDT
Nominating Wanted for Tb 3.0
Comment 9 Magnus Melin 2008-10-23 11:29:39 PDT
Comment on attachment 309120 [details] [diff] [review]
Fixed typo in patch, now directing to the correct file (I hope)

Patch still applies.

Frans, you need to ask review to get the patch to go anywhere - see http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree. 

(I've done it for you this time.)
Comment 10 Magnus Melin 2008-10-23 11:31:39 PDT
Marking wanted‑thunderbird3+ since we have a small patch.
Comment 11 Frans-Jan v. Steenbeek 2008-10-23 22:43:31 PDT
@ #9

Even if I knew I wouldn't have done it. I don't know C++, but I do know the code I added is not really up to standards, to say the least. What I wanted to show is that, building on John McCormick's suggestion, a workable MAPIResolveName can be implemented quickly.

I would highly advise to have a proper C++ coder look at MapiDLL.cpp, build on the patch I added and make it into something more sane, more stable and equally workable. It'd be great if said coder can also implement MAPIAddress and hook both functions into the address book.
Comment 12 David :Bienvenu 2008-10-24 08:26:08 PDT
Comment on attachment 309120 [details] [diff] [review]
Fixed typo in patch, now directing to the correct file (I hope)

MAPIREsolveName should actually resolve the name, in particular give the user a chance to resolve dupes, and hook up to the address book(s) - see http://msdn.microsoft.com/en-us/library/ms529143(EXCHG.10).aspx. This code should also check for allocation failure. We could build on this patch, but I don't have time to do this myself. We could check if MAPI_DIALOG is not set, and do simple AB resolution in that case, since doing the resolution dialog is the more difficult part.
Comment 13 Frans-Jan v. Steenbeek 2008-10-24 08:47:42 PDT
That is correct, but please keep in mind that a lot of applications just fire a request at it and expect it to be send (used as an alternative for a built-in SMTP server). Whatever it does, it should at the very least accept plain email addresses and send the mail without further notice (if so configured).

Just unlocking that feature will enable a lot of applications to work with Thunderbird where they can't as it is now. I do not believe this should be an either/or implementation.
Comment 14 David :Bienvenu 2008-10-24 13:40:06 PDT
I'm ok with an incremental approach...didn't mean to imply otherwise.
Comment 15 Virgo Pärna 2010-01-21 05:38:40 PST
Resolving this would probably also resolve bug 215978
Comment 16 Ludovic Hirlimann [:Usul] 2010-01-21 06:22:34 PST
(In reply to comment #15)
> Resolving this would probably also resolve bug 215978

A patch would be very welcome.
Comment 17 gonzzza 2010-04-08 00:47:42 PDT
The fix was offered TWO years ago, and still Thunderbird 3 does not support MAPI ResolveName. Is it realy hard to implement such a simple fix? The bug has a NEW status, which means it wasn't even reviewed yet. Well great. How do we raise the priority of this one?
Comment 18 David :Bienvenu 2010-04-08 08:14:19 PDT
(In reply to comment #17)
> The fix was offered TWO years ago, and still Thunderbird 3 does not support
> MAPI ResolveName. Is it realy hard to implement such a simple fix? The bug has
> a NEW status, which means it wasn't even reviewed yet.

the patch was reviewed and minused, but a new patch was not submitted. Status NEW just means someone didn't change the status to assigned. It says nothing about whether a patch was reviewed or not.
Comment 19 bugzilla.org 2010-04-21 02:43:47 PDT
Hey All

This issue is causing me major pain as we use Thunderbird in our office and because of this bug i am not very popular with the rest of our staff as they each have to use an old copy of outlook to send emails with attachments straight from an accounting program written in Foxpro.

As such i am willing to pay someone to get this fixed and in the next stable release. If anyone knows who i should contact about this please contact me or reply to this post.

If not i guess i will have to start learning C++
Comment 20 Theo 2010-04-21 07:10:52 PDT
The same for me!

We're using Thunderbird 3 in an office with >100 stations and the ERP system sends email trough SimpleMAPI. Recipient's address is added to the mail text instead of the correct To: field in TB.

It would be great if anyone could comment on the priority of full MAPI support for Thunderbird as it's one of the big aspects for companies using TB.
Comment 21 mb 2010-04-21 22:52:42 PDT
Me too.  This is an issue in an office, as so many third party applications use mapi calls.
Comment 22 Magnus Melin 2010-04-23 11:47:50 PDT
phil, interested in finishing this patch?
Comment 23 Patrick Kurz 2010-08-13 02:43:11 PDT
Hi, I tryed to implement code above - in TB 3+ but did not work - can anybody help? Multiple errors (SDK Windows 7). We need this funktion for ERP Software, etc.

or can someone send me a compiled mozMapi32.dll with MapiResolveName? For testing our ERP? 

Thanks Patrick
Comment 24 Worcester12345 2010-08-27 11:14:30 PDT
We need MAPI support for some telephony applications, such as sharing address book. Any chance of this happening soon?
Comment 25 Patrick Kurz 2010-08-28 14:01:00 PDT
(In reply to comment #24)
> We need MAPI support for some telephony applications, such as sharing address
> book. Any chance of this happening soon?

Hi, 
I´ve fixed the mozmapi32.dll by myself - it works for xp, 2003 and 7 (only 32bit) there is a bug with 64bit 7 we can´t handle. I can send you a copy of my dll if you like?

Patrick
Comment 26 Worcester12345 2010-08-30 21:38:20 PDT
(In reply to comment #25)
> (In reply to comment #24)
> > We need MAPI support for some telephony applications, such as sharing address
> > book. Any chance of this happening soon?
> 
> Hi, 
> I´ve fixed the mozmapi32.dll by myself - it works for xp, 2003 and 7 (only
> 32bit) there is a bug with 64bit 7 we can´t handle. I can send you a copy of my
> dll if you like?
> 
> Patrick

I'd rather see the focus on getting it into the core product for full support. This is not an individual install, but a company-wide thing. Thanks.
Comment 27 Worcester12345 2010-08-30 21:45:21 PDT
How can this be + on "wanted‑thunderbird3" when "thunderbird3" is already out and the successor is in place? Is there a ? or + for "wanted‑thunderbird3.2"?
Comment 28 Werner F. Bruhin 2010-08-31 00:06:02 PDT
Would really like to see this too.

Patrick did you/can you provide what you did to Mozilla?

If you woulnd't mind would appreciate if you could send it the dll to me, would like to test it.

Werner
Comment 29 Werner F. Bruhin 2010-08-31 00:07:50 PDT
Would really like to see this too.

Patrick did you/can you provide what you did to Mozilla?

If you woulnd't mind would appreciate if you could send it the dll to me, would like to test it.

Werner
Comment 30 David :Bienvenu 2010-08-31 07:30:43 PDT
I'm ok with accepting a patch based on the existing patch that checks for out of memory, which should be very easy.
Comment 31 Tony Sosa 2011-05-13 12:57:24 PDT
Would like to see this resolved for Win7 64-bit.
Comment 32 :aceman 2011-12-20 02:49:09 PST
I can look at fixing it up per comment 30.
But can this be compiled on linux? Or is it skipped in the build there?
Comment 33 :aceman 2012-01-09 12:56:12 PST
Created attachment 587088 [details] [diff] [review]
patch, add check out of memory and other cleanup
Comment 34 :aceman 2012-01-09 12:57:59 PST
I did not compile it, I suppose it is only for Windows. Somebody please test the patch.
Comment 35 Jim Porter (:squib) 2012-01-09 13:18:20 PST
Comment on attachment 587088 [details] [diff] [review]
patch, add check out of memory and other cleanup

Review of attachment 587088 [details] [diff] [review]:
-----------------------------------------------------------------

Just a quick pass from me since I noticed a potential leak. See below.

::: mailnews/mapi/mapiDll/MapiDll.cpp
@@ +402,5 @@
>  {
> +  char* lpszRecipName = new char[(strlen((const char*)lpszName) + 1)];
> +  char* lpszRecipAddress = new char[(strlen((const char*)lpszName) + 6)];
> +  if (lpszRecipName == NULL || lpszRecipAddress == NULL)
> +    return MAPI_E_INSUFFICIENT_MEMORY;

You probably want to delete lpszRecipName and lpszRecipAddress here just in case one of them fails but not the other. Don't forget to use delete[], not delete. (Also, barf, Hungarian names.)
Comment 36 :aceman 2012-01-09 13:24:58 PST
Good catch, will fix the leak.

What did you mean with the variable names? They seem to use the style of the surrounding code.
Comment 37 :aceman 2012-01-09 13:27:48 PST
Do I also need to check *lppRecip ?
Comment 38 :aceman 2012-01-09 13:35:18 PST
Created attachment 587107 [details] [diff] [review]
patch, fix proper release of memory in case of failure
Comment 39 David :Bienvenu 2012-02-15 16:52:36 PST
Comment on attachment 587107 [details] [diff] [review]
patch, fix proper release of memory in case of failure

thx very much for the patch

this doesn't compile for me because it can't find msgMapiMain.h - not sure why.

+#include "msgMapiMain.h"

+  if (lpszRecipAddress == NULL) {

should be !lpszRecipAddress

similarly for the other null checks...mozilla style guide says to use !ptr, not ptr == null

-  	return(S_OK);
+    return(S_OK);

should be return S_OK;  no parens
Comment 40 David :Bienvenu 2012-02-15 16:59:22 PST
I don't think that include is needed in MapiDLL.cpp - I'll attach the patch that builds for me.
Comment 41 David :Bienvenu 2012-02-15 17:00:37 PST
Created attachment 597618 [details] [diff] [review]
patch that builds for me
Comment 42 :aceman 2012-02-15 23:50:57 PST
Thanks, I'll fix the other nits.
Comment 43 :aceman 2012-02-16 11:19:50 PST
Created attachment 597912 [details] [diff] [review]
patch v3
Comment 44 Mark Banner (:standard8) 2012-02-21 06:52:20 PST
Checked in: http://hg.mozilla.org/comm-central/rev/0f7e5afbe650
Comment 45 Ludovic Hirlimann [:Usul] 2012-02-29 07:22:24 PST
Requesting ESR support for that feature as it let's Thunderbird interact with a bunch of other Enterprised software (such as crystal report).
Comment 46 :aceman 2012-02-29 07:30:33 PST
For those deciding it it is worth it:
There is a confirmation this helps with Crystal reports in bug 215978.
We wait for confirmation with MS Word in bug 259585.
Comment 47 Emilio Lumia 2012-03-02 02:54:17 PST
Hello,
this works for me with a third part software (see Bug 251228 - Fail to send a message from a third party software with MAPI) on a windows 2003.

Please just a question : how to don't send the message on the fly, so user can edit it.

Thx very much.
Comment 48 :aceman 2012-03-02 03:00:40 PST
Has your software started working after we solved this bug?
Comment 49 David :Bienvenu 2012-03-05 15:52:46 PST
I think this would be a good thing to land on the ESR branch.
Comment 50 Mark Banner (:standard8) 2012-03-06 00:49:42 PST
(In reply to David :Bienvenu from comment #49)
> I think this would be a good thing to land on the ESR branch.

Agreed, though I'd like to bake this for a while in case there are any side effects. At the moment, not going to take it until 13, when this fix is scheduled to be released, although we could potentially move it forward to 12, but we'll think about that early next cycle.
Comment 51 Mark Banner (:standard8) 2012-04-25 02:30:52 PDT
Comment on attachment 597912 [details] [diff] [review]
patch v3

[Triage Comment]
a=Standard8 for ESR.
Comment 52 Mark Banner (:standard8) 2012-04-25 02:31:26 PDT
Landed on esr: https://hg.mozilla.org/releases/comm-esr10/rev/36ce100dacb4

Note You need to log in before you can comment on or make changes to this bug.